[Phpwebsite-developers] phpWS/2: Part 1 (users and groups)

[Todd O. <to...@da...>]

*Users table will be minimalistic
Instead of adding everything in the world to the users table, only
_essential_ information will be provided like unique user_id, username,
first name, last name, email address, preferred language, timezone, etc.
Non-core information like department, personality profile, etc. can be
implemented in modules (and additional db table with user_id as the foreign
key [this id is used alot]).  A state field will have something like 1 for
active, 2 for disabled, 3 for suspended, etc.  A creation date will also be
added; last accessed will not be here since this is more of a read-mostly
table.  An authentication type field will be present with the following
philosophy: 1-database authentication, 2-affiliated site authentication (see
my previous xml-rpc post), 3-LDAP authentication, etc.  An auth field will
contain XML with is specific to the authentication type field selected as
follows:

Assume database authentication:
<password type="md5">3hjk7894kjkoldf9lkju8</password>

Assume affiliated site authentication:
<authURL>www.example.com/authenticate.php</authURL>
<methodCall>
      <methodName>authenticate.remote</methodName>
      <params>

<domain><value><string>phpwebsite.appstate.edu</string></value></domain>
        <username><value><string>user1</string></value></username>
      </params>
</methodCall>

Assume LDAP authentication:
<ldap_server>ldap.example.com</ldap_server>
<ldap_user>, etc.....

This core structure provides for writing only database authentication now
and adding many other types in the future, even using a SHA hash ;-)  **The
XML field provides this extensibility without lots of rarely used database
fields that must be added every time a new core authentication type is
added.**  You'll see my draw to XML database files throughout the project
for this very reason!

* User_space and Group_space will be flat.
After considering many alternatives for user and group space, I decided that
flat was best.  Of course a flat namespace for users and groups is the most
simple approach, I feared it would hinder administration for large
organizations like colleges or school systems, which may have 25,000 members
that must be _managed_.  This is unlike slashdot style sites where anyone
can join and userspace is _really_ flat.

A flat namespace also gives the most flexibility for use, although the
administration might be more involved.  Let's say App State has 10,000
students and faculty on their site and has 15 departments with different
administrators.  If the name and group space was in a tree hierarchy, how
would a Physics Dept student get to edit an English Dept document?  The
point is that you can administer a flat namespace as a tree, but not vice
versa.  Anyway, custom modules can be created for specialized administration
where needed.

A flat groupspace enables any user to be a member of any group.  This is
great until you only want a subset of the Physics Dept (group) to be
moderators on Physics Dept announcements.  I decided that instead of FORCING
a group tree hierarchy, I would let the individual site administrator make
sure that only Physics group member were in the Physics-moderators group.

This is my philosophy for the phpWebsite core: **Make it as Flexible as
Possible.**  I will add a parent field to the group db schema to provide for
those who want to write a custom module that will enforce the hierarchy
through administration, but not in the core!

Groups table:
group_id  INTEGER primary key
name  VARCHAR(32)
parent_id INTEGER [foreign key to group_id]
[root has same group and parent id]

group_membership table (matrix):
group_id INTEGER [foreign key]
user_id INTEGER [foreign key]
index on group_id
index on user_id
index on group_id, user_id
[speeds up membership searches significantly]

--Todd