<correcting top posting>

On 14 Jan 2006, at 07:45, Tom Hallam wrote:

Wichert Akkerman wrote:
The error handling in PlonePAS for user registration is quite
suboptimal: for all errors it just says "The login name you selected is
already in use or is not valid".
For plone.org this causes us to get users that are only created
partially: they are created in a LDAP database, but since
LDAPMultiPlugins does not implement mutable property sheets yet setting
the user properties fails. So we have a new user, but without any
properties. The PlonePAS registry.cpy catches the exception raised by
the property setting code and tells the user that the login name is
already in use or invalid, which is not true.
I'm not sure what the best way to fix this is. Either we should rollback
user creation if it fails halfway (tricky) or add some new exception
types so we can distinguish between fatal errors and non-fatal ones.
Sounds like the problem is more at the plugin design level. Why is PAS trying to set properties for a plugin that does not support them? Really an error should not be happening in this situation.

To me it seems that either the interface should require the plugin to implement mutable properties (this should be part of the interface compliance testing) or PAS should inquire via the interface as to whether the properties are mutable and behave correctly.

It seem that the former is being assumed and that LDAPMultiPlugins are not compliant with the plugin interface requirements (as implemented).

"Mutable property sheets" have nothing to do with any plugin. They are part of the user object implementation (-> PropertiedUser class). There is no interface requirement (and thus no compliance issue) as far as LDAPMultiPlugins is concerned.

A quick look at the plugin interfaces in the PluggableAuthService product will tell you that plugins that claim to be able to edit a user must fulfill IUpdatePlugin. LDAPMultiPlugins do not claim to support this interface, so again no compliance issues with the LDAPMultiPlugins package. Something assumes it can just go and edit the user, and that code is not part of the LDAPMultiPlugins package.

By the way, editing a user object that was assembled with data from the LDAP database makes no sense, anyway. It is not persisted in any way and it cannot write back to where the data really came from, which is the LDAP DIT. Currently the only way to make that happen is by directly talking to the LDAPUserFolder embedded in the plugin. The latest versions of LDAPUserFolder had the former CMFLDAP package folded into it, those can be seen as an example of how a tool acting as CMF member data/membership tool talks directly to a LDAPUserFolder to do the work it needs to do.


Zope-PAS mailing list

Reply via email to