[isf-wifidog] FirewallRuleSets & User Classes

[Mina Naguib]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Scott Tully wrote:
|>       The main blank in this is how the hell are the rule classes
|>handled? The Auth server needs to know them but in a system like
|>Ile Sans Fil, every hot spot is "independent" and therefore would
|>have different user classes for a given user depending on the hot
|>spot...
|
|
| I was thinking of creating a new table in the db called classes with a
| shared primary key... something like this
|
| CREATE TABLE `classes` (
|  `user_id` varchar(128) NOT NULL default '',
|  `node_id` varchar(32) NOT NULL default '',
|  `class` int(3) NOT NULL default '3',
|  PRIMARY KEY  (`user_id`,`node_id`)
| ) TYPE=InnoDB;
|
| During authentication instead of selecting the class from the user
| table, select the user_id AND node_id from this table for the hotspot
| where the login is from... then the user is put in the class assigned
| for that hotspot. One login with a different class defined for each
| hotspot....

Sounds cool. For simplicity, it should fall back on the user class in
the users table if no per-node class matches in the above table.

Also I recommend a slightly more verbose table name :)

|
| What do ya think?
|
| Scott

If we go that route I think we might need to think at a slightly higher
architectural level.

For example, why not store the entire class definition on the auth
server and have wifidog dynamically download it and set it up upon startup ?

The classes can be unique per node or inheritable on a per-group level.
etc.. They can also be web-configurable by the admins/hotspot owner.

Lots of ideas. We (I?) need focus. Maybe I'm just rambling after a long
day of sugar rushes and caffeine.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCJmcUeS99pGMif6wRAk6iAJ4+0v0WndGJHnA1URPLdpwUWYMVRwCfRRcb
4Y8n749HEJs3cH3AhMLyV1o=
=AA5H
-----END PGP SIGNATURE-----