So something like this? Look ok? Allen [EMAIL PROTECTED]
##############snaphsot of radius.cfg###################### <AuthBy SQL> DBSource dbi:mysql:mainaccounts DBUsername root DBAuth new-password NoDefault AuthSelect select password, time_to_sec(expiry_date)-time_to_sec(current_time) \ as session from authtable where (username='%n' \ and status = 1 \ and (expiry_date is null or expiry_date > now()) ) AuthColumnDef 0,Password,check AuthColumnDef 1,Session-Timeout,reply </AuthBy SQL> ########################################################## At 02:31 PM 8/10/2002 +1000, Hugh Irvine wrote: > >Hello Allen - > >You are correct - epoch time is what is used in the Radiator Timestamp >attribute and most databases can use it too (assuming you are meaning >UNIX epoch - number of seconds since Jan 1, 1970). The advantage of >doing this is that a simple subtraction will give you the number of >seconds for the Session-Timeout. > >regards > >Hugh > > >On Saturday, August 10, 2002, at 02:03 PM, Allen Marsalis wrote: > >> Thanks much Hugh! I'll give that a whirl.. I doubt my RADIUS >> client (NoCatAuth) will accept the reply attribute. FWIW, >> it re-authenticates every 8 minutes so once the user >> tries to re-authenticate after expiration, no m�s packets.. :) >> >> Last may I ask what unit or format EXPIRY is? I'm thinking >> that Epoch time or some date/timestamp format would be nice.. >> What timelocal format does AuthSelect use or expect in EXPIRY? >> >> Allen >> [EMAIL PROTECTED] >> >> >> At 12:56 PM 8/10/2002 +1000, Hugh Irvine wrote: >> > >> >Hello Allen - >> > >> >It sounds like you need an EXPIRY field in your database, and an >> >AuthSelect query that checks to make sure that the current time is less >> >than the EXPIRY. For completeness you should probably also return a >> >Session-Timeout that is set to the difference between the current time >> >and the EXPIRY. >> > >> >regards >> > >> >Hugh >> > >> > >> >On Saturday, August 10, 2002, at 12:30 PM, Allen Marsalis wrote: >> > >> >> Maybe I'm thinking too hard and should just describe what I want >> >> to do which is pretty simple. I would like to authenticate users >> >> for a time period which will deny authentication after the expiration >> >> period elapses.. The period will be 1 hours from current time, >> >> 24 hours from current time, or one month (approx 744 hours) from >> >> current time. That's it. Can someone point me in the right >> >> direction regarding exactly what attribute would be best for this? >> >> I do not wish to disconnect the user but rather just not allow >> >> a re-authentication after 1 hour, 1 day, or one month.. >> >> >> >> Allen >> >> [EMAIL PROTECTED] >> >> >> >> >> >> At 05:40 PM 8/9/2002 +1000, Hugh Irvine wrote: >> >> > >> >> >Hello Allen - >> >> > >> >> >You should probably use Session-Timeout attributes to limit the >> >> >connections. >> >> > >> >> >regards >> >> > >> >> >Hugh >> >> > >> >> > >> >> >On Friday, August 9, 2002, at 08:59 AM, Allen Marsalis wrote: >> >> > >> >> >> Hi, >> >> >> >> >> >> I'm wanting to create accounts for wireless hotspots that >> >> >> might expire after 30 min. or some interval that is measured >> >> >> in minutes or hours rather than days.. >> >> >> >> >> >> I looked at some RADIUS dictionaries and "expiration" is >> >> >> of type "date".. What is the best way to implement a >> >> >> policy such as this with Radiator? Does "date" include >> >> >> epoch time? i.e. expiration=920000000 Will this work? >> >> >> Is it the best approach? >> >> >> >> >> >> Thanks, >> >> >> >> >> >> Allen >> >> >> [EMAIL PROTECTED] >> >> >> === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
