[isf-wifidog] Download and time based limits

[Benoit Gregoire]

On Wednesday 12 July 2006 07:22, Rajkumar S. wrote:
> Hi,
>
> I have a requirement to terminate customer's connection based on
> either download limit or usage time. As far as I understand this is
> not possible with wifidog. So I am trying to add support for these,
> and if possible support for prepaid tokens and pins also.
>
> I am going through the code trying to read and understand. My idea is
> to hook the limit checking into auth/index.php after the call to
> $authenticator->acctStart
>
> I will add another method to authenticator to check if the user has
> exceeded the defined limits.

You shouldn't mess with auth/index.php, you should call your check inside 
acctStart()

> I am just checking if there are any existing plans/designs to get this
> done. As far as possible I want to make sure that what I do is
> compatable with the overall design of wifidog so that it can be
> intagrated into the code base.

There is, i did much of the design work for bidding on a contract (discussions 
have since stopped, unfortunately) and never really worte it down.  This is a 
very simplified summary:

I believe the way to eventually support support all the models listed on  
http://dev.wifidog.org/wiki/WirelessCommunityModels with a maximum of code 
re-use and not stepping on each other's toes is this:

The tokens as currently understood in the database would now be known as 
session tokens.

A new table of "tokens" would be created:  Access tokens.  A valid access 
token would be required for a user to create a session token.

Some fields of access tokens include
Status
	-Unused, valid, expired
Expiration conditions:
	-Expiry date
	-Duration limit
	-Data transfer limit

The authenticators can have creation conditions for access tokens
	-Monthly quota
	-Daily quota
	-Credit card
	-Daily code
	-Etc.

If for example, you have a monthly quota of 20 GB, and used up 18, you'd 
create an access token with only 2GB, expiring at the end of the month.

This would also also replace the current way the validation grace period is 
implemented (it would become just a detail of one specific authenticator) 

This architecture allows all indirect requirements that some models have for 
having reports of token usage, unused sold tokens, etc.

Although it's probably unclear why from this very short summary, it also:
-Allows several query optimisation to avoid summing potentially thousands of 
connections every time there is a counter update
-Avoids and much database back and forth for counter updates (Expiration 
condition checking can be done 100% in the database).
-Keeps most of the code common to all authenticators.

> I also want the meaning of Network, node, portal and content in the
> context of wifidog. I have some vague idea and understanding but
> getting a canonical def can help a lot in clarifying the concept.

Reading through the developper docs should give you some help.  But indeed we 
should have a WiFiDogConcepts wiki page.  Feel free to start one with the 
terms you'd like defined.

> Right now when I try to browse from a machine I get the wifidog login
> page but after logging I am not redirected to the url that I was
> trying to browse, but to the logged in page. what I want is to get a
> popup with the logout button and the browser should proceed to the url
> I had originally typed.

That would be a very easy configuration option to add, except for the popup.  
But why would you want a popup with a logout button?