[Mailman-Developers] Login / User Identification Issues in MM3

[Barry Warsaw]

On Jul 12, 2012, at 12:25 AM, Richard Wackerbarth wrote:

>On Jul 11, 2012, at 9:05 PM, Barry Warsaw wrote:

>> There *should* be enough hooks in the system already for a system
>
>> administrator to say "I want to use Postorius, so I must enable the
>> Postorius IUserManager implementation".
>
>And, by saying this, you imply that the storage of passwords is no longer the
>responsibility of "core".
>
>You have delegated it to IUserManager. And the default Postorius compatible
>IUserManager could store those passwords where ever it wishes. In particular,
>it can store them in the Postorius User database, along with all of the other
>User profile information that the site wants to keep.  > because everything
>talks to that object through the interface, and as long as that keeps its
>contract, the rest of the system should, again Just Work.

Note that when I say IUserManager above I'm talking specifically about the
zope.interface that is used in the core.  You're talking about a conceptual
independent component called a "user manager".  The former is a coding
specification that contains only the things the core is interested in, it
wouldn't be used as an inter-system definition.  The latter would be specified
by its REST API (let's say).  Then the core would have an implementation of
IUserManager which maps its data and functionality to REST calls against this
external component.

>> I have no idea whether the above will be easy or not, since nobody's tried
>> it.  But the system design should allow you to do it this way, and I would
>> be very open to the right hooks, fixes, and extensions to make this
>> possible.  I hope you can see how this approach lets someone run Mailman in
>> many different configurations, from a core-only system, to Postorius, to a
>> system where all the user database is in ZODB or already locked up in a
>> proprietary closed database.
>> 
>> There is another approach of course, which may end up being simpler, if more
>> brittle.  You could just try to keep the two databases in sync.  It doesn't
>> matter too much which is the master, you just have to decide.
>
>Yes, but from my experience, only with great care. As you note that
>arrangement is brittle. I would prefer to avoid it.

It definitely means data kept in two places, and you're right that great care
has to be taken.  What if the core is down for maintenance when a user changes
her password through Postorius?  These are the kinds of things that the
Launchpad integration work addressed, but that was in a highly controlled
environment, with lots of operational assurances.  In our case, we can't just
hand-wave that brittleness away.

>I think that this is the wrong approach to the extent that "core", and here,
>by "core" I think you mean the "admin-by-mail" component, does anything other
>than call the same REST interface that the web UI would use.

It could, though internally, that would be hidden behind the implementation of
IUserManager, IUser, and associated objects.  We're saying the same thing but
in a different way.  The advantage of hiding this behind the zope.interfaces
is that we can have multiple alternative implementations of those interfaces,
so that whether it's REST or a SQL call doesn't matter to most of the core.

>> So for example, an IMember associates an
>> IAddress with an IMailingList.  The standard implementation of that doesn't
>> use a foreign key between the `member` table and the `mailinglist` table.
>> Instead it uses the fqdn_listname, i.e. a string.
>
>I don't agree. Your string which contains the fqdn_listname IS a foreign key
>to the mailinglist table. It may not be the primary key in some
>installations, but it is one-to-one with that key and could be used directly
>as the primary key.

The point is that it's not a foreign key constraint in the members table.
Doing that would, I think, prevent you from putting the mailinglist table in
one database and the member table in another.  It makes the associated queries
less efficient, but provides for a useful measure of flexibility.

Cheers,
-Barry

P.S. FWIW, I think this separate "user database" component with REST calls in
the IUserManager (et al) implementation would not actually be difficult to
mock up.  I don't have the time to do the coding, but would be happy to
discuss details if someone wanted to take a crack at it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120712/5d95bb2a/attachment.pgp>