[Wifidog] Version 1.0
papril777 at yahoo.com
Thu Apr 22 10:10:23 EDT 2004
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?
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
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
<sigh>I don't know what to say now, I feel like I'm in a bad position
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.
> -----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
>> it, but as talked with Daniel Drouet and Benoit, I believe the goal is
>> have hotspot owners customize what they want on the AUTH server and not
>> 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,
> LocusWorld or MandrakeClub.
> 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
> 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
> person also owns a HotSpot (ok, I admit, it's unlikely). He logs in at
> is listed as the owner in the config file. Now obviously the server
> answer: YES, KNOWN_NETWORK_ABUSER, or something like that, not NO,
> KNOWN_NETWORK_ABUSER. Otherwise, the hotspot has no way to know if he
> entered a wrong password, and should be denied access.
> - --
> Benoit Grégoire, http://step.polymtl.ca/~bock/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> -----END PGP SIGNATURE-----
> Wifidog mailing list
> Wifidog at isf.waglo.com
Wifidog mailing list
Wifidog at isf.waglo.com
More information about the Wifidog