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

Mailman-Developers mailing list
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 

Security Policy: http://wiki.list.org/x/QIA9

Reply via email to