Well I read the discussion thread. I had no idea so much previous thinking had gone into this. Funny that there was so much discussion but no-one has really chimed in with an opinion about how I’ve built the authentication proxy - maybe everyone’s gun-shy. :-)
The only unresolved question for me coming out of all that is “where is it specified which users have access rights to carry out functions at a higher level than the list?”
It appears that such information is not part of the Mailman core user data model and needs to be handled outside Mailman core i.e. at the application level.
Personally I’d store such user information inside the Mailman core data model. Things start to look weird when application X has a different mechanism for deciding who can do admin tasks to application Y. Maintaining such info outside the core also calls for user database synchronisation which would be good to avoid. But I don’t really mind I’m just trying to get a secure way of deciding which users to allow to do higher-than-list-level functions.
My options are:
1: eliminate public access to all functions that operate higher than list level 2: bake my own additional level of user authentication that defines which users have higher level access rights. 3: find a cheat/workaround to store arbitrary keys against users (this my preferred solution) 4: something else
Option 1 drastically reduces the usefulness of the interface if only list level functions can be executed. Not ideal. Option 2 I would prefer to avoid - my authentication proxy doesn’t actually know much about Mailman at an application level - all it does is authorise and authenticate and pass through requests to Mailman if the user is allowed to do it, and reject them if not. Option 3: find some sort of cheat/workaround - preferablyt a way to store additional user information in a user profile field which allows storage of arbitrary keys. Then I could stash some access control information in there that tells me that user X or user Y has some higher level access control. This would have to be do-able via the Mailman REST interface cause it’s the only way that I talk to the system. The ability to store arbitrary key/value information against a user would be the ideal outcome at this stage. Option 4: - other ideas?
Does anyone know if there is a way to do Option 3 currently?
as
On 25 Jan 2015, at 7:37 am, Terri Oda terri@toybox.ca wrote:
On 2015-01-24, 5:08 AM, Andrew Stuart wrote:
you can look back in the archives to the huge discussion we had about unifying the user data store..
Is there search to find that discussion or do I have to manually review all the threads? Any idea what year it was in?
The data store discussion was I think two years ago around the time of pycon. I started it with a thread entitled "Architecture for extra profile info"
https://mail.python.org/pipermail/mailman-developers/2013-April/022852.html
(As Sumana says, mail-archive is usually the best bet for searching the mailman archives. I searched locally, though.)
But I'm serious that it's only worth reading if you're incredibly bored. It became a huge architecture discussion that only ended on the lists with an "agree to disagree." (and I got bombarded with further comments about it on IRC for months after the list discussion ended, so I'm actually kind of still cranky about it.)
I think it's still a thing we need to look in to more seriously, but be warned that it's a topic folk have been passionate about in the past, to the point where progress was not made. On the other hand, one of the people involved in that discussion has moved on to other things and the rest of us do collaborative work together more frequently, so it might be easier to reach a solution now.
Terri
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9