(RADIATOR) Expirations more granular than one day

[Hugh Irvine]

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