Re: Some questions about LiveUser

Christian Schäfer wrote:

that's what I thought. so I use the groups feature to implement what I refere to as role and use it again to implement classes. so on the application level both will be the same, but on usage these two kinds of groups will differ. right? that would not satisfy my needs really.. :-(

Why not? You described yourself that it all comes down to one single thing: Rights. You assign rights to classes, you assign rights to roles. So if you can have those sets of rights in groups, your problem is solved. If you need to put different names on things, you can for example just prefix your group names with the entity names you want: Class_MyClass, Role_Tutor, Role_Administrator etc. ... Your application can simply react to rights being granted or not and doesn't have to care about putting names on things. Thing is, if we start supporting entities called "roles" and "classes", soon other people will pop up and demand support for more entities, called for example "rooftops", "kitchensinks" or "pets"... whatever is thought as hyperultraessential for an application. But in the end, it comes down to be able to assign rights to... well, groups :-)

I understood that LiveUSer will use PEAR::DB as an interface for database access, this should be able to extend to PEAR::DB_ldap[2] right? so that there's a SQL-to-LDAP translation in between..?

There is no SQL-to-LDAP translation, they're totally different concepts. As I understood it, you can still use the familiar PEAR::DB API with DB_ldap, but you have to pass valid LDAP search patterns to a call to query(), for example: $db->query('cn=Christian,o=Krachstoff,ou=Coders'); So you could technically just take one of the existing DB containers as a basis but rewrite all methods containing SQL calls. However, I have never done any real work with an LDAP server and have not yet touched DB_ldap, so the above is based on my personal assumptions of the package.

an alias is an ldap feature. it means that an ldap server creates a link to an account on a second ldap server rather than creating the account redundantly. if asked, the ldap will reply with some sort of 'I do not have that account you're asking for, but I know who might got it'.

Ah. That's not currently supported by LiveUser, as that's obviously not possible with RDBMS or XML files. LiveUser will just query any server in the configuration array for a user, and it will do it in the order defined by the array. Whoever has the user first will win :-) But I'm sure such a feature could be implemented within an LDAP-specific auth container. CU Markus