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

[Richard Wackerbarth]

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

> Thanks for starting this discussion.  Since the thread's already long, I'm
> just going to answer randomly with my own thoughts.

And thanks for your reply. I just spotted something in it that makes me feel that rather than fundamental disagreement, we may simply be saying things differently.  I'll dig through all of the rest of your remarks in detail at an appropriate interval.

> One thing I have a real problem with is defining the database query layer as the interface between components.

Note that I expressed the preference that the interface be defined in terms of the REST access.

As I say in another post, it is not the exact expression of the interface that is important, but that all of the descriptions are isomorphic and that no component accesses shared data by "private" methods.

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

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

> Once the core acts on that change, it will trigger a PasswordChangeEvent which has a reference to
> the user effecting that change.  If Postorius was the master database for
> passwords, we'd have to add a little event subscriber which, when it got a
> PasswordChangeEvent, then talked to Postorius to make that change.  Or maybe
> it updated the shared user data component, or made the appropriate SQL UPDATE
> call.  The key thing again, is that the core just fires the
> PasswordChangeEvent, and other things react to it.
> 
> Alternatively, let's say a user changes their password through the web ui.  I
> think this case is already covered, because the way to keep that in sync with
> the core is to make the appropriate REST call, probably PATCHing the user's
> password.

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.

The implementation of that interface item could reside anywhere in the system and it would manipulate the database through the IUserManager.

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