[Mailman-Developers] Browser ID integration with Mailman

Barry Warsaw barry at list.org
Fri Feb 24 00:36:55 CET 2012

On Feb 23, 2012, at 11:04 PM, Florian Fuchs wrote:

>> Even if we came up with a way to extend the core schema and store the data
>> in the core, how would you access it?  There would probably have to be a
>> generic REST API for getting key/value data associated with the user in and
>> out of the core.
>Hmm, that doesn't sound like you particularly like that scenario. ;-)

Not so much. ;)

>I'm not sure if it's a really good idea to use the core as a general data
>store. If user data (or even list data) is augmented with information the
>core doesn't need to operate, why not use a second data source. After all we
>have a system at hand (django) that's designed to do that.


>> I've have a similar question when it comes to authorization.  Just where to
>> do we keep the authorization mapping users and roles to actions they can
>> perform?
>I'm not sure if that's what you mean, but I would say that depends on who the
>main authority is for, say, assigning a role to a certain user for
>instance. What if I revoke the moderator role from a member via the command
>line (I don't think that's currently possible, but let's say it is...). The
>core would have no way of actively inform the web ui (or possibly all the
>many different web ui installations, apps etc...) that this privilege has
>been revoked. So I'd say this is some information the web ui would have to
>request from the core.

Yep.  TBH, this is something I've been struggling with for a long while now.
Remember I've advocated for keeping all those decisions out of the core, but
there has been valid push-back on that (admittedly somewhat lazy ;) stance.

Now, I think we can get notifications pushed from the core to the ui if we
wanted, assuming the ui had some service to notify.  See my previous message
on events.  But in some cases, like the one you mention above, I think it
would also be fine for the ui to query the core to gather the information
necessary to decide whether an action is allowed.  E.g. the ui could ask the
core, via REST, "is this person an owner of that mailing list?".

There are upsides and downsides to this.  For example, do we want to keep the
logic for authorization in the web ui?  That would mean if you integrate the
core with your own custom web ui, then it wouldn't gain any of the benefit of
the authorization logic in the Django app.  OTOH, that might be just what you
want, and I can imagine a site like Launchpad would prefer that, since it has
its own user model.  Ignoring that whole morass does keep the core lean and
mean, which I rather like, especially because I want to release this beast
RSN. ;)

So I'm very tempted to punt on the whole authentication/authorization issue as
much as possible in the core for the 3.0 release, but I'm also happy to keep
the discussion open for possible changes for the future.  I think the
integration work going on between the web ui and the core will give us some
much needed practical experience here.  Right now, it's all too theoretical
for me to make much headway on.

>> I'm very close to punting on this for 3.0 beta (and thus likely for 3.0
>> final), though I'm also happy to revisit it during the Pycon sprint (likely
>> for a hypothetical 3.1).
>Aahhh, the Pycon sprint... :-)

Fun, fun!

Note too that I will be giving a talk on MM3 at Pycon, but fortunately I only
have to fill 30m. :)  I want to be able to release MM3 very soon after the

-------------- 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/20120223/251800b2/attachment.pgp>

More information about the Mailman-Developers mailing list