[Zope-PAS] Re: PlonePAS error handling

[Jens Vagelpohl]

<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.
>> Wichert.
> 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.

jens