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. > >> >> > >> >> > >> >-- > >> >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 [EMAIL PROTECTED] > >> >To unsubscribe, email '[EMAIL PROTECTED]' with > >> >'unsubscribe radiator' in the body of the message. > >> > > >> > > >> === > >> 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. > >> > >> > >-- > >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 [EMAIL PROTECTED] > >To unsubscribe, email '[EMAIL PROTECTED]' with > >'unsubscribe radiator' in the body of the message. > > > > > === > 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. > > -- 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
