(RADIATOR) Sending Username and password to SQL

2000-05-09 Thread talist
I would like to change my AuthSelect in a way that it would send the username and password to the SQL server Can I use something like: AuthSelect exec MyStoredProc '%n' '%{User-Password}' === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscrib

Re: (RADIATOR) Sending Username and password to SQL

2000-05-09 Thread Hugh Irvine
Hello - On Tue, 09 May 2000, [EMAIL PROTECTED] wrote: > I would like to change my AuthSelect in a way that it would send the > username and password to the SQL server > Can I use something like: > AuthSelect exec MyStoredProc '%n' '%{User-Password}' > Yes, you should be able to do this. The Au

RE: (RADIATOR) Some problems with mixed access servers

2000-05-09 Thread Lutfi YUNUSOGLU
Title: RE: (RADIATOR) Some problems with mixed access servers Well you can certainly use different types of NAS with Radiator, all you have to do is specify the corresponding NasType as you already know. To manage simultaneous use, all copies of Radiator must use the same SessionDatabase SQ

(RADIATOR) Installation errors

2000-05-09 Thread cistron
Hello everybody, I am getting the following errors in make test not ok 5a, 5d, 5f. Kindly help Thanks and Regards === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the messa

Re: (RADIATOR) Sending Username and password to SQL

2000-05-09 Thread talist
The %{User-Password} is giving an encrypted version of the actual password typed by the user. Is there another variable containing the actual password typed by the RAS user ? If not, how can I decrypt the User-Password variable. > > Hello - > > On Tue, 09 May 2000, [EMAIL PROTECTED] wrote: > >

RE: (RADIATOR) Some problems with mixed access servers

2000-05-09 Thread Hugh Irvine
Hello Lutfi - On Wed, 10 May 2000, Lutfi YUNUSOGLU wrote: > Well you can certainly use different types of NAS with Radiator, all you have to do is specify the corresponding NasType as you already know. To manage simultaneous use, all copies of Radiator must use the same SessionDatabase SQL, so

Re: (RADIATOR) Sending Username and password to SQL

2000-05-09 Thread Hugh Irvine
Hello - On Wed, 10 May 2000, [EMAIL PROTECTED] wrote: > The %{User-Password} is giving an encrypted version of the actual password > typed by the user. > Is there another variable containing the actual password typed by the RAS > user ? > If not, how can I decrypt the User-Password variable. >

Re: (RADIATOR) Installation errors

2000-05-09 Thread Hugh Irvine
Hello - On Wed, 10 May 2000, cistron wrote: > Hello everybody, > > I am getting the following errors in make test > not ok 5a, 5d, 5f. Kindly help > You can see what tests are being run by looking at the file "test.pl" in the main distribution directory. Section 5 of the tests is attempting t

(RADIATOR) Expire Date

2000-05-09 Thread Michael Saunders
I dont want radiator to check the expire date customers have in the subaccounts table and their master accounts table.     I am using emerald.cfg does anyone know how to do this     Michael Saunders

(RADIATOR) Logging accounting records locally unmodified, then proxying without the realm

2000-05-09 Thread Andrew Pollock
Hi guys, Is it possible to log accounting records locally in an unmodified form, then strip off the realm before proxying the accounting records to another server? I want the realm in the local detail file but I don't want the realm in the accounting record I forward to the other server. Andrew

Re: (RADIATOR) Logging accounting records locally unmodified, then proxying without the realm

2000-05-09 Thread Hugh Irvine
Hello Andrew - On Wed, 10 May 2000, Andrew Pollock wrote: > Hi guys, > > Is it possible to log accounting records locally in an unmodified form, then > strip off the realm before proxying the accounting records to another > server? I want the realm in the local detail file but I don't want the

RE: (RADIATOR) Logging accounting records locally unmodified, then proxying without the realm

2000-05-09 Thread Andrew Pollock
> -Original Message- > From: Hugh Irvine [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 10 May 2000 12:24 PM > To: Andrew Pollock; [EMAIL PROTECTED] > Subject: Re: (RADIATOR) Logging accounting records locally unmodified, > then proxying without the realm > > > > Hello Andrew - > > On Wed,

Re: (RADIATOR) Expire Date

2000-05-09 Thread Hugh Irvine
Hello Michael - On Wed, 10 May 2000, Michael Saunders wrote: > > I dont want radiator to check the expire date customers have in the subaccounts >table and their master accounts table. > > > I am using emerald.cfg does anyone know how to do this > You would need to specify your own AuthSe

RE: (RADIATOR) Logging accounting records locally unmodified, then proxying without the realm

2000-05-09 Thread Hugh Irvine
Hello Andrew - On Wed, 10 May 2000, Andrew Pollock wrote: > > -Original Message- > > From: Hugh Irvine [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, 10 May 2000 12:24 PM > > To: Andrew Pollock; [EMAIL PROTECTED] > > Subject: Re: (RADIATOR) Logging accounting records locally unmodified,

Re: (RADIATOR) Sending Username and password to SQL

2000-05-09 Thread talist
I wish I could use the DecryptPassword clause found in AuthExternal. I tried to implement it in the AuthSQL.pm but my perl knowledge is too rusty :( I am sure this is just a few lines of code but I am afraid of making the server crash. Anyone wants to give it a try? > > The %{User-Password} i

Re: (RADIATOR) Sending Username and password to SQL

2000-05-09 Thread talist
I made a small modification to util.pm so I can have the decrypted password in Radiator. In this example '%P' would be the decrypted password and can be used the same way as '%n' (the Username) I think this is very useful for everyone. In my case, this allows me to send the username and the passw

RE: (RADIATOR) Logging accounting records locally unmodified, then proxying without the realm

2000-05-09 Thread Andrew Pollock
> Then the simplest thing is to chain together two AuthBy's, the > first to log the > original username in standard format (an AuthBy FILE with a > DEFAULT would do), > and the second to do the rewrite and other processing. > > # configure two AuthBy's with an AuthByPolicy > > > AuthByPoli