[Wifidog] Version 1.0

[Pascal Leclerc]

Philippe April wrote:

>Okay I believe me and Pascal (correct me if I'm wrong) have talked with
>Daniel before and got different answers regarding that, we thought we were
>aiming more for a centralized architecture. That way we don't need to
>build a web interface for configuring complex Wifidog's config rules,
>while still taking into account the rules from the central server, etc.
>
>Pascal, Daniel? Est-ce moi ou est-ce qu'on a eu 2 différentes idées sur la
>facon dont ce doit etre fait?
>  
>
Je pense qu'on a deux idées différentes. J'ai vraiment aimer celle qu'on 
a discutée hier (Daniel, Phil et moi) et que Philippe à expliquer dans 
ses derniers messages (ça simplifie de beaucoup wifidog). J'aimerais 
bien connaitre la manière de penser de Benoit, comme ça on pourra plus 
facilement comparer les deux et/ou faire une synthèse des meilleurs points.

>I understand the extreme example, and it kind of makes sense.
>
>I believe we all have different views of how things should get done. Now
>we just need to know, who gets to decide? do we just present the different
>ways and vote? It seems clear in everybody's head, but we haven't agreed
>on a design altogether.
>
>  
>
>I would really suggest to take off all userclasses code for 1.0, even just
>to have something clean since we won't be using it now. That's just my
>personal opinion.
>
>  
>
Je crois qu'une des idées importantes de la soirée d'hier était de faire 
fontionner wifidog pour avoir une version 1.0 fontionnelle et stable. La 
suite à propos d'un choix d'architecture XYZ sera pour un peu plus tard.

L'idéal serait de refaire un brainstorming de toutes les idées et 
décider vers ou orienter l'architecture de wifidog pour la suite. Les 
possibilités sont nombreuses avec différents avantages et inconvénients.

>So for 1.0,
>
>Can we all agree that we remove the unneeded code from the source tree,
>have users authenticated (yes or no returned from auth server), and be
>granted internet access, with a general timeout from the config file, so
>if there's no traffic for like 5 minutes, they get denied access?
>
>Later on, we will return a status code regarding authentication and more
>complicated rules.
>
><sigh>I don't know what to say now, I feel like I'm in a bad position
>right now.</sigh>
>
>It seems like I get ideas and design concerns from everywhere. What Daniel
>was saying sounded sooooo right when he said it. Then you (Benoit) send an
>email, and what you say kind of makes sense too.
>
>Now I'd love to ship out version 1.0 very soon with limited
>functionalities, while still aim in the right direction for the future,
>it'd be great if we could all agree on something so we can code and start
>the testing phase soon.
>
>Philippe
>
>  
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>    
>>
>>>I think the entire code for userclasses is not needed anymore and I will
>>>remove it from CVS, but keep a diff of it in case I was wrong and we
>>>need
>>>it, but as talked with Daniel Drouet and Benoit, I believe the goal is
>>>to
>>>have hotspot owners customize what they want on the AUTH server and not
>>>on
>>>the router, so no custom configuration on the router.
>>>      
>>>
>>That is NOT what I said!  We will definitely need userclasses later on,
>>and I
>>really, really don't feel like having to build a centralised architecture
>>where everyone has to go to the central server to admin their own router,
>>ala
>>LocusWorld or MandrakeClub.
>>
>>    
>>
Je suis d'accord qu'une architecture centralisée n'est pas idéale. De la 
manière que je vois ça, c'est de permettre le plus de flexibilité 
possible (ça reste à déterminer bien ententdu) pour le proprio de l'AP. 
La convivialité aussi est importante, autant pour l'admin (proprio 
intéressé) que pour les développeurs (config web dans wifidog pas trop 
idéal). Il faut aussi penser à la robustesse et à la sécurité, je ne 
crois pas qu'un DOS sur l'auth serveur rendant tous les AP innopérants 
ferait bonne presse.

Pour la flexibilité, voici un exemple de pseudo log :

Wifidog initialising ...
Fetching userclass from auth server : Fail operation timeout
Loading local userclass fetch : File unavalable
Loading default userclass
Waiting for user ...
...

>>What I did say is that for version 1.0 we can cheat a little:  after the
>>account is locked out, instead of returning the result: YES,
>>NEW_ACCOUNT_LOCKED and having the gateway decide what to do with it, we
>>can
>>just return NO, NEW_ACCOUNT_LOCKED.
>>
>>A note about YES/NO:  In my opinion, yes means that authentication was
>>successfull, not necessary that the user must be granted internet access.
>>The user classes should have a well documented meaning, and the gateway
>>should take final decisions based on them.
>>
>>Here is an extreme example:  Say we lock out an account for abuse, and
>>that
>>person also owns a HotSpot (ok, I admit, it's unlikely).  He logs in at
>>home,
>>is listed as the owner in the config file.  Now obviously the server
>>should
>>answer:  YES, KNOWN_NETWORK_ABUSER, or something like that, not NO,
>>KNOWN_NETWORK_ABUSER.  Otherwise, the hotspot has no way to know if he
>>simply
>>entered a wrong password, and should be denied access.
>>- --
>>Benoit Grégoire, http://step.polymtl.ca/~bock/
>>    
>>


_______________________________________________
Wifidog mailing list
Wifidog at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com