Re: A registration with a common userbase?
| From: | Tomas V.V.Cox | Date: | Tue, 02 Jul 2002 11:01:37 +0000 |
| Subject: | Re: A registration with a common userbase? | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-7429@lists.php.net to get a copy of this message | ||
Kristian Koehntopp wrote:
>
> Is anyone interested into establishing a user login class and
> infrastructure, a kind of passport system?
Many people on this list is interested on such system. See the archive,
this topic come here every month :-)
> The respective class would use an external or distributed
> database to validate the user against that database. It would
> also enable registration to that database, perhaps also adding
> additional data about that user to the central store.
>
> The class would also have an optional, local storage component
> with additional user data such as preferences, customizations
> and similar, which need or should not be shared to a central
> store.
>
> The class would allow a user to roam freely between sites that
> are using this class to authenticate users.
>
I guess that a Passport/SSO (Single Sign On) also known as SPF (Single
Point of Failure) is too ambituous. My idea is more of having a PEAR
User class that applications can adopt easily for improving the
integration of them. This is (following your interesting post),
providing a common Identification (container with login/pass pairs) and
Authentication (validation against the data in the container and some
persistant mechanish like sessions or custom cookies) system.
Optionally we could offer other things like Authorisation (ACL stuff) or
a common container for storing user info/configs. While we are on this
topic, I've implemented a class for doing all this at the same time: acl
managment and user data and configuration storage. Let me explain the
idea. The schema is:
CREATE TABLE acl_groups (
groupid INT NOT NULL,
name VARCHAR(80) NOT NULL,
visitleft INT NOT NULL,
visitright INT NOT NULL,
PRIMARY KEY (name)
);
CREATE TABLE acl_perms (
groupid INT NOT NULL,
userid VARCHAR(25),
subject VARCHAR(80),
value TEXT
);
INSERT INTO acl_groups VALUES (1, 'all', 1, 2);
That allows having a generic storage (currenlty only databases with
UNION support) for key/value properties for a user/group and the ability
to group them in a tree like structure (for being able to for example
inherit perms/config across groups). For clearing a little how to
interpret that schema:
A group permission:
groupid is present
userid is missing
subject is present
A user who belongs a group:
groupid is present
userid is present
subject is missing
A user permission:
groupid is present
userid is present
subject is present
(missing means NULL value)
Summary of the most interesting public methods:
function ACL(&$dbh)
function addGroup($name, $parent_group = 1)
function addUserToGroup($userid, $group)
function setUserPerm($userid, $subject, $value, $group = 1)
function setGroupPerm($group, $subject, $value)
function &getUserPerms($userid, $cache = false)
function getUserPerm($userid, $subject)
function deleteUser($userid, $group = null)
A quick simple usage example:
<?php
$acl = new ACL($db);
$acl->addGroup('info');
$acl->addGroup('config');
$acl->addGroup('perms');
$user = 'foo'; //id or login name
$acl->setUserPerm($user, 'name', 'Foo Bar', 'info');
$acl->setUserPerm($user, 'email', 'foo@bar.com', 'info');
$acl->setUserPerm($user, 'bgcolor', '#FFFFFF', 'config');
$acl->setUserPerm($user, 'fgcolor', '#AAAAAA', 'config');
$acl->setUserPerm($user, 'is_admin', 0, 'perms');
$acl->setUserPerm($user, 'modify_data', 1, 'perms');
?>
With that you are setting three main groups each storing different kind
of data: general information about the users, env config settings and
access rights for differents parts of the app (note that the evaluation
of the rights is not integrated into the class).
Tomas V.V.Cox