On Aug 11, 2015, at 05:43 PM, Simon Fromme wrote:

2. Is there a timeframe in which a good Mailman 3 documentation can be expected? I find it quite hard to solve problems myself given the small amount of informationon the web right now.

One of the things I think we need is better holistic documentation which describes how to use the integrated system, from a user's and list owners' perspective. I feel like the core is fairly well documented (it could always be better of course), but since most users don't really interact with the system at that level, it's more geared toward developers.

We'd certainly welcome contributions here.

Cheers, -Barry

On Aug 12, 2015, at 10:28 AM, Stephen J. Turnbull wrote:

The big problem is that as Simon points out we no longer have a truly centralized database. Each component now keeps user information related to itself, but it's not communicated across the components very well.

This is true, and it bites us via the user database. This recently came up in a conversation about the authenticating proxy[1]. There has been discussion about a centralized user database, and I think eventually we'll need something like that, whether it's part of the core or a separate component.

ISTM the core exports pretty good information, but it has no ability to grant privileges in the other components. The other components are in a "pull" relationship with core, so core isn't really able to get information from them. We need to think about providing better communication among the components.

Agreed. Within the core, we have a set of events that get triggered when certain things happen, like a user gets subscribed to a mailing list, etc. What we could do is set up a pubsub that gets notified when these events happen, so Postorius or any other component can be notified when the user database gets updated.

I wonder if we might not have been better off using an object-oriented database like MongoDB for the core. That would allow adding components from external sources as the external sources require.

Perhaps, but for now that ship has sailed. It's certainly not a good idea for non-core components to be mucking about in the SQL database. Let's think about the APIs we'd need to build to provide better communication between components.

Cheers, -Barry

[1] https://gitlab.com/astuart/mailmania

...

I think I would second the idea of having a single component/database that is responsible for the management of user information.

The problem is that the larger Mailman ecosystem is designed to be a loose collection of components so there is no way to define what information each component needs stored at the Mailman Core. It wouldn’t make sense for the data store requirements of Postorius to be baked in to the Mailman Core data structures because Postorius is an optional component of the Mailman suite.

In the case of your original question:

...

...

However, I am having some trouble understanding the procedure of granting users access to the Postorius webinterface.

Whether or not a user has access via the web interface is application specific to Postorius so it should be stored in a local datastore managed by Postorius.

It’s both a strength and a weakness that Mailman Core is quite rigid about “taking care only of its own business”. The big benefit of this strategy is that in future it will continue to be practical to upgrade Mailman Core exactly because it has tightly defined data structures and no knowledge of how other applications in the ecosystem behave. Customised data structures in the Mailman Core would lead to major issues in forward compatibility - imagine the nightmare of trying to upgrade Mailman Core if it included application-specific customisations that had been wound in over time - it would be like chewing gum in your hair - you’d never get it out.

The important thing is that Mailman Core provides a resource permissions model that can be leveraged by other servers such as Postorius so that the central store of Mailman user authorisation information can be applied to application specific data stores. Which is to say, Postorius (or any other application) can store data using the Mailman userid, and can check with the Mailman Core to see if it is a valid user.

Mailman Core’s commitment to minding its own business is a good compromise - its not ideal but it’s not that bad either - the key thing for third party application developers to understand is that Mailman provides a unique ID for every resource (users, domains, lists etc), and provides a permissions model that defines which of these resources users have access to. Third party applications can connect logically to this conceptual framework in a fairly loosely coupled manner.

as

Andrew Stuart writes:

So there is something to be said for a very simple Mailman Core key/value store mechanism that would meet some simple needs. The argument against this is “well you’re going to outgrow it pretty quick anyway so why not immediately start with a more full featured data store”.

I don't think you're going to outgrow it. We have a sufficiently flexible way to name resources (URI is a proof of concept) and accesses, so a permission is just a triple (add a user).

One problem we face is secure communication between components for identification and authentication purposes, which currently isn't present in Mailman at all. *That* could be a real problem, as there may be embedded design decisions that induce a conflict between efficiency and security (I don't think so, but that's the kind of problem one typically runs into). We also need an authorization scheme which doesn't propagate excessive privilege across components, but that can be done in principle by making permissions into quadruples (add the component to distinguish privileges in one component from privileges in another).

This kind of thing has been done for a long time (Kerberos), so I guess the question is do we really need Kerberos, or can we get away with something a lot less complex?

Finally we need the discipline to design and consistently implement a system-wide authorization system. That's undoubtedly the hardest part.

Steve