(RADIATOR) Expirations more granular than one day

[Allen Marsalis]

So something like this?  Look ok?

Allen
am at shreve.net


##############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
 >> am at shreve.net
 >>
 >>
 >> 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
 >> >> am at shreve.net
 >> >>
 >> >>
 >> >> 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
 >> >> >> am at shreve.net
 >> >> >>

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.