On Wed, 5 Apr 2000, Ron Parker wrote:
> Here's a partial rewrite of sitegroups. Let me know if it makes
> any sense. I haven't attempted to use SiteGroups yet so I'm doing this in
> the blind.
> <!--Beginning of edits-->
>
> SITEGROUPS
>
> SiteGroups seperates the address spaces of a global pool of users who
> share one database. Consequently when users logs into specific
> SiteGroups, it appears as though they're accessing seperate databases.
> In addition to manageing access priveleges, this fascilitates the use of
> one administration interface which also reduces the number of persistent
> database connections.
Maybe the 'address space' bit is a little too technical. I think the
easiest view on siteoups is that of multiple 'virtual' Midgard databases
within one physical MySQL database so you can strctly separate multiple
sites (which includes their users and groups).
> If Henry owns vmuc.com and vmucentertainment.com; obviously Henry must
> have administrative privelages for those Hosts, while it's equally
> imperative that he's denied read and write privelages to anything that
> he doesn't own while useing the Midgard administration tools.
> CONFIGURATION
> To enable SiteGroups you must specify "--with-sitegroups" during the
> configuration process of libmidgard. The configure programs for
> mod_midgard and midgard-php probe libmidgard to see if sitegroups are
> enabled and respond accordingly.
But all must be reconfigured and recompiled when changing from SG to
non-SG or visa versa.
> While SiteGroups is designed to be as transparent as possible, the
> transition to makeing your administration tool SiteGroups aware requires
> the manual instantiation of sitegroups. You do this by issueing:
> INSERT INTO sitegroup (name) VALUES ('sitegroupname');[0]
David has written admin-site code for Sgs and I'll try t get it included
in the 1.4beta. Currently, commands like this one above must be executed
in the mysql command line tool.
> In order to make the Midgard administration site available to users it's
> ownership must be assigned to SiteGroup 0 (SG0). When libmidgard is
> configured with "--with-sitegroups" it's default state of ownership is
> SG0.
It's rather that if you add the DB patch, which adds columns and one
table, all existing records that are in the database will have their SG
field set to '0', so anything that exists in your DB when you apply the
patch is in SG0. In the default install, VMUC will be in SG0.
> Users that require write access to the entire Midgard database must
> be members of SG0.
Users that wannt full access must be in the root group, which yyou will
want to keep in SG0 (both the member and person records).
> In order to enable Henry's write permissions within vmuc.com we create
> the sitegroup "vmuc.com," add henry as a user and finally modify the
> vmuc.com sitegroup to include him within its membership.
> USEAGE
> When logging into the Midgard administration interface site, the user is
> prompted to specifiy a username@sitegroup. Only root users, members of
> SG0, can remain in SG0 while logged in. The "sitegroup" field for a
> host record is used to determine which records are accessible dureing
> the session. Either a specific host or 0 must be specified. Consequently
non-root users must allways specify a sitegroup when logging into SG0.
> when Henry specifies [EMAIL PROTECTED], midgard-root.php3 queries the
> sitegroup field in the Midgard database and determines which records
> Henry will see in the administration interface.
It's actually the core SQL functions that limit the returned data by
matching on the sitegroup field of the records.
Many thanks,
Emile
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
