<correcting top posting>
On 14 Jan 2006, at 07:45, Tom Hallam wrote:
Wichert Akkerman wrote:
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.
The error handling in PlonePAS for user registration is quite
suboptimal: for all errors it just says "The login name you
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
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
user creation if it fails halfway (tricky) or add some new exception
types so we can distinguish between fatal errors and non-fatal ones.
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
It seem that the former is being assumed and that LDAPMultiPlugins
are not compliant with the plugin interface requirements (as
"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