Hello Wyness -
You can also use the "Session-Timeout = until Time" reply item in conjunction
with the Time check item.
Section 13.2.7 in the manual.
regards
Hugh
On Wednesday 07 February 2001 11:55, Wyness Casama wrote:
> ---------------------------
>
> >From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, February 06, 2001 2:28 PM
> >To: Wyness Casama; [EMAIL PROTECTED]
> >Subject: Re: (RADIATOR) Setting time blocks and account expirations
> >Hello Wyness -
> >
> >You should use the "Expiration ...." check item.
> >Have a look at section 13.1.4 in the Radiator 2.17.1 reference manual.
> >regards
> >Hugh
>
> ---------------------------
>
>
> Thanks for your suggestion Hugh.
>
> I had originally looked at that option but I wanted the epiration to happen
> at an exact time. For instance, if a user bought a day's worth of internet
> at 1:00p, I want that account to expire next day at 1:00p. The Expiration
> field seems to expect the data to come in a 'FEB 06 2001' format. I guess
> it might be possible to pass another timestamp into the DB...
>
>
> --------------------------
>
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> >Behalf Of Chris Given
> >Sent: Tuesday, February 06, 2001 1:37 PM
> >To: 'Wyness Casama'; [EMAIL PROTECTED]
> >Subject: RE: (RADIATOR) Setting time blocks and account expirations
> >
> >Yes, if your using SQL set the SessionTimeout to the amount of time they
> >bought, and restrict the login limit to one. After that is done you can
> > use a stored procedure to hook to decrement the SessionTimeout each time
> > the user disconnects and you get the Account-Session-Stop packet.
> >This would be easy to accomplish using MS SQL Server or Sybase ASE
>
> --------------------------
>
> Hmmmmm.... This sounds feasable as well... What I can do is send the
> SessionTimeout to the NAS like you have already suggested then I'll couple
> that with the Expiration field suggestion that Hugh mentioned along with an
> ExpirationTime. Here's what I'm trying to do with all of those fields: The
> SessionTimeout field will hold the time bought (this will prevent the user
> from staying logged on past the cut-off time as it's decremented from the
> time bought. the timestamps in the start/stop accounting entries will be
> used to determine remaining time,) then the Expiration date and
> ExpirationTime will be used to keep the user from logging on after a
> certain time. So, the whole process will be determined by a hook... So,
> let's try some pseudo-code:
>
> -------------------------------------------------------------------
>
> # Hello, Access-Request packet!
> make username's sessionTimeout to be the difference left between ((current
> date/time) and (expiration date/time));
> if (username = valid) and (password = valid) {
> if (username's SessionTimeout > 0) and ((currentTime < expirationTime) and
> (currentDate <> Expiration) and (user is not on more than one instance){
> allow login;
> send remaining sessionTimeout to NAS;
> }
> else {
> later, gator! you've been denied!;
> }
>
> -------------------------------------------------------------------
>
>
> Anyhow, it has been some time since I've even tried any programming. I
> think this little exercise is a throwback that I learned from my
> TurboPascal days back in high school.
>
> Any thoughts about the problem at hand? (I already know my code stinks.
> lol)
>
> -- Wyness G. Casama
>
>
> ======================= (here's my original post)
> ===============================
>
> On Wednesday 07 February 2001 07:12, Wyness Casama wrote:
> > Hi all,
> >
> > I've been working on a particular project for a couple of days now, but I
> > haven't found the missing key that lets everything fit together...
> >
> > I am trying to accomplish a setup where users will buy a block of time
>
> (for
>
> > instance 2 days (48 hours))... What I want to happen is that the user
>
> will
>
> > be able to authenticate as many times as they want to the NAS/RADIUS
>
> system
>
> > within that 48 hour period, but as soon as the specified 48 hours is
> > over, the server will disconnect the user AND stop the user from
> > authenticating again with the expired account.
> >
> > Any ideas?
> >
> > -- Wyness Casama
>
> ===
> Archive at http://www.starport.net/~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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
