(RADIATOR) Adding reply- and check attributes after Access-Accept
Rickard Gunnarsson
rickard.gunnarsson at wlanalliance.com
Thu Aug 8 03:39:18 CDT 2002
Thanks for your reply Hugh,
however, isn't it so that AuthSQLQuery (=AuthSQLStatement??) is executed
before AuthSelect? If I use AuthSQLStatement to update my ACTIVE field, I do
not know at this point if the user authentication will be successfull,
right? I could check all the check-attributes in the AuthSQLStatement before
updating my ACTIVE field, but then the same process would occurr twice since
the AuthSelect statement will be executed immediately after.
Or did I get it all wrong?
Regards,
Rickard
>
> Hello Richard -
>
> I think you will need to add an ACTIVE field to your database.
>
> The ACTIVE field can be set to 24 hours in the future the first time the
> account is used with an AuthSQLQuery, and the Session-Timeout reply
> attribute can be set to the number of seconds remaining until that time
> every time the user logs in. Your AuthSelect query can check to make
> sure that the current time has not passed the ACTIVE time.
>
> regards
>
> Hugh
>
>
> On Wednesday, August 7, 2002, at 09:26 PM, Rickard Gunnarsson wrote:
>
> > Hi,
> >
> > this is my problem: I've got a number of pre-generated user accounts in
> > an
> > SQL-database. Whenever a user uses his account for the first time, the
> > account should be valid for 24 hours. To not complicate things, we can
> > assume there are no check- or reply attributes by default.
> >
> > My idea was to check whether a first successful authentication has
> > occurred
> > and if so add a reply attribute like Session-Timeout=86400 (24hrs) to
> > the
> > reply packet.
> > I would also need to update my database to add the check attributes
> > Time=[now-(now+24hrs)] and Expiration=[now+24hrs] and a reply attribute
> > like Session-Timeout="until Time". This would give the correct
> > behaviour for
> > future authentications the following 24 hours.
> >
> > I intended to solve this by using the PostAuthHook, checking if the
> > Session-Timout attribute was present in the reply packet to decide if
> > the
> > account is used for the first time, and if so adding the
> > Session-Timeout to
> > the reply packet and updating my database.
> >
> > I guess this would work, but it doesn't look as an optimal solution to
> > me
> > from a performance point of view.
> > Anyone got an idea of a better way of solving my problem? Possibly
> > using an
> > SQL trigger or function called by AuthSQLStatement or something else?
> >
> > Regards,
> >
> > Rickard
> >
> >
> >
> > ===
> > 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.
More information about the radiator
mailing list