(RADIATOR) Expirations more granular than one day

Hugh Irvine hugh at open.com.au
Fri Aug 9 21:56:02 CDT 2002


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.
> >>
> >>
> >--
> >Radiator: the most portable, flexible and configurable RADIUS server
> >anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> >-
> >Nets: internetwork inventory and management - graphical, extensible,
> >flexible with hardware, software, platform and database independence.
> >
> >===
> >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.
> >
> >
> ===
> 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.
>
>
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
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.


More information about the radiator mailing list