mRFC 0027: Midgard sitegroup authentication and objectcreation.
- Background
- Sitegroup ID
- Sitegroup creation
- Creation of sitegrouped objects from sitegroup 0.
- Application sitegroup
- Sitegroups and authentication.
Background
Sitegroups are logical containers implemented in Midgard to use one database but to separate out different clients by adding an extra sitegroup attribute to all records in the database.
There is also a sitegroup 0 (SG0) that is special in that all items from that sitegroup are read-only from other sitegroups (SGn) and may act as parents to an object (for example a style) in a sitegroup.
There are some usecases that need to be understood with regard to sitegroups. They are described in this document.
The basic information about sitegroups can be found in documentation: http://www.midgard-project.org/midcom-permalink-f624e440f76a466d5870374bca8e1449
Sitegroup ID
Up to and including 1.7 the sitegroup id has been an integer. In the future the attribute may be an integer (id) or string ( guid or uuid ) which identifies sitegroup by its record in database. The type of identifier depends on implementation.
Sitegroup creation
Sitegroup can be created only by authenticated person which is member of the Administration group in Sitegroup 0 ( SG0 ). These are the only users who can delete or update sitegroups as well.
When a sitegroup is created, it needs to be created with an adminigroup and a administrator.
The following code is a sample of how sitegroup creation should work for midgard 1.8:
// create the sitegroup
$sitegroup = new midgard_sitegroup();
$sitegroup->name = "Sitegroup";
$sitegroup->create();
// create the admin and the admingroup
$group = new midgard_group();
$group->name = "admingroup";
$group->sitegroup = $sitegroup->id;
$group->create();
// create the admin
$person = new midgard_person();
$person->username = "admin";
$person->sitegroup= $sitegroup->id;
$person->create();
mgd_update_password($person->id, $person->username, "pwd");
$member = new midgard_member();
$member->uid = $person->id;
$member->gid = $group->id;
$member->sitegroup = $sitegroup->id;
$member->create();
$sitegroup->admingroup = $group->id;
$sitegroup->update();
[NOT TESTED!]
How should this look for 1.7?
Creation of sitegrouped objects from sitegroup 0.
There are some usecases where the SG0 admins want to create objects into a sitegroup.
Creation in 1.7.
To creat an object in midgard 1.x , x<=7, you need to run the following code: $obj = mgd_get_object(); $obj->name = "some name"; // set some other attributes $id = $obj->create(); $obj = mgd_get_object($id); $obj->setsitegroup($sgid);
This will change the objects sitegroup, but not attachments or parameters creatd before changing the objects sitegroup, they will remain in SG0. Also, if you add attachments and parameters to the object later as SG0 these parameters will also stay SG0.
Suggested change to 1.7:
Setsitegroup() should change the sitegroup of the objects attachments and parameters as well.
Creation in 1.8
In 1.8 the following [NOT IMPLEMENTED] rules apply to adding a sitegroup to an object:
1) If user is in SGn (n > 0), create object in SGn
2) If parent object is in SGn (n > 0), create object in SGn
3) If sitegroup property is set to SGn (n > 0), create object in SGn
4) Otherwise create object in SG0
This implies that you cannot change the sitegroup of a created object after it has been created. you cannot change the sitegroup using the update method.
The only way to change the objects sitegroup once it is created, is to export it and import it through replication by another sitegroups person.
NB: $obj->update() should return false when a user tries to reset an objects sitegroup and return the error "Sitegroup cannot be changed after creation.", error number 32.
[NOT IMPLEMENTED]
Updating objects
When a SG0 admin updates an object, different attached records like quota or metadata, may be affected. These records should get the same sitegroup as the object - not the sitegroup of the application.
Application sitegroup
Every Midgard application ( which uses midgard connection and midgard database ) runs in a sitegroup context.
The context of a sitegroup'ed application is identified by sitegroup's identifier assigned as member of the midgard connection. Application's sitegroup can be set ( or even changed ) in one way only - by authentication as a user.
Setting the application sitegroup with no authenticated user.
Today, when no user is logged in, the application runs in anonymous mode. If the application is running through Apache, the application sitegroup is set according to the sitegroup of the current page. [NOT VERIFIED]
Anonymous mode as a user.
It is suggested to change the way the anonymous mode works. To run application in anonymous mode( when the application must be used within particular sitegroup context and no person should be logged in ) anonymous account should be created for particular sitegroup. Access control for the anonymous account should be covered by the ACL mRFC.
The anonymous account may be duplicated ( replicated ) between different sitegropups as long as as can be identified by particular sitegroup, even when record itself is identified by the same guid or uuid. When sitegroup has no anonymous user, the application should run in SG0 context.
Issues
- What should be done with available resources when sitegroup context is changed when application runs?
- What should be done with SG0 and with SGn available resources?
Sitegroups and authentication.
Today login to Midgard happens in two ways:
- Through basic authentication where the user may only enter username and password.
- Through the function mgd_auth_midcom($username, $password, $sendcookie)
Many if not most sites uses the mgd_auth_midcom function.
A problem is that midgard needs to determine the sitegroup the user has before checking the password as a username may exist in more than one sitegroup. This is solved in versions up to 1.8 by using a delimiter and the sitegroup name.
A problem with this approach is that the delimiters may be used in the username. When this happens, logins will fail as Midgard cannot divide the username-sitegroup combo properly.