[Zope-PAS] Re: proposal: IUserAdder plugins

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Miles wrote:
> Hi,
> 
> Thanks for the feedback!
> 
> (answering a couple of points in this one mail)
> 
> Kapil Thangavelu wrote:
>> On Fri, 04 May 2007 14:54:59 -0400, Miles 
>> <miles at jamkit.com> wrote:
>>
>>> I seem to be generating a sizable proportion of the traffic on this  
>>> list!  Apologies in advance for another email...
>>>
>>> My use case is as follows:
>>>
>>> I have a zope website, a php forum and blog that make up my site, 
>>> each  with their own user databases.  Whenever users register through 
>>> the zope  site (I have removed links so they cannot register 
>>> elsewhere), I want to  create corresponding user accounts for them in 
>>> the database for the  forum and the blog.
>>>
>>> However, when a user is created, PAS runs through all the plugins  
>>> implementing the IUserAdder interface, but once a plugin indicates 
>>> that  it created a user, it proceeds no further.
>> right, which makes sense to me, you don't really want it to create  
>> multiple users, shadowing each other for login purposes. only one gets
>> to  login. it sounds like you just want to have your custom useradder 
>> plugin  ordered higher than the default zodb user plugin.
> 
> Well, that is what I want to do - create multiple users in each of these
> applications, but which all correspond to the same actual person/login.
>   This would mean the same account could be used to access all of them.
>   I guess the root of the issue is that there is no way that the
> blog/forum apps can be coerced into using a single source of
> usernames/passwords without substantial rewriting.

One thing you should note is that, from the PAS perspective, there is
only going to be one "user" object, and it won't typically be a
persisten object;  instead, the PAS creates a transient user object
(which may be cached) and then the other plugins "decorate" that
transient object.

If you want to do an "eager" setup in the other applications when a new
user is created in PAS, then the event mechanism is probably your best
bet;  it will simplify things, however, if you don't call that "creating
a user."


> I had planned to create a 'blog useradder' plugin, and a 'forum
> useradder' plugin, and use the existing 'zodb user manager', to deal
> with creating users in each application, rather than a single
> 'blog+forum+zodb' useradder - in order to keep the code for each app
> separated.  Is a single, "large" plugin really the recommended approach
> in this situation?

I would actually recommend *not* doing "eager" setup of the user record
in the blog / forum;  instead, I would expect that application to supply
"reasonable defults" for a user it has never seen before, and then to
allow the user to override those defaults.  The blog / forum / whatever
can then have a plugin registered to add properties to the user, without
needing to do anything when a user is created.

Note that PAS is designed to be useful in cases where the Zope
application is flat not allowed to create users (e.g., behind an SSO
server, or backed by readonly LDAP).  The blog / forum apps can still be
used in such cases if they follow my pattern ("lazy" defaults), but not
if they follow yours.

> I can control which plugins fire by activating/deactivating the
> IUserAdder interface and changing the order of the plugins from within
> PAS, so the "only one plugin can create" restriction is already a bit
> redundant.

Event notification is best used when you want *all* subscribers
notified, and you don't care about order.  The plugins mechanism is
designed to allow for ordering, as well as the "first response" pattern
you see here.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPfcD+gerLs4ltQ4RAn1YAKCpRSVGqC9p+3MxBEGOMfTiEMRcAwCgn48E
yuDC63NDSChigEgZzw6a93s=
=BHeS
-----END PGP SIGNATURE-----