On Feb 17, 2012, at 1:41 PM, Florian Fuchs wrote: > 1) Browserid is very convenient, but I wouldn't rely on it as the only means > to log into the MM web ui.
I agree. It is a reasonable scheme to support, but we need to have "authentication" done on a "plug-in" basis. Structurally, the underlying design should be completely agnostic to the login mechanism. Since Django already has a User model with all kinds of permissions infrastructure, we should be leveraging off of that (extending the User model as needed) for our UI. MM has two kinds of authentication to perform. BrowserID "solves" both at the same time. First, it establishes that the person on the website is a particular user. But it also "proves" that the email address "belongs" to that user. Thus, with BrowserID, we can allow the user to join a mailing list without having to send the confirming email transaction. On the other hand, that confirming email transaction is basically what the browserid.org site does. Thus, with little effort, MM could also act as a secondary authority for the BrowserID protocol. > It relies on client-side code to be run, which has a lot of advantages > usability-wise but also has some accessibility pitfalls. I don't think that's > a reason *not* to implement browserid, but probably more as one of more > auth-methods that site admins can choose when setting up their installation > of mailman. > > 2) The server-side verification part of their example application [1] is done > using node.js. I think creating a similar thing in python and making a django > AuthBackend out of it could be a very nice task. A quick search brought up > two django-browserid implementations ([2], [3]), but in both cases I'm not > sure if this is how we would do it in our web ui. (Both are stand-alone > reusable apps - I think we'd rather integrate something like that directly as > part of our app code. But that's probably debatable...). I'll "debate" the approach. IMHO, we should be leveraging the Django user model and we should not be reimplementing it. If the existing BrowserID implementations fail to provide the necessary functionality, then we should either "fix" one of them or write another implementation which is still generic and could be reused by others. Similarly, authentication schemes such as Kerberos should be able to plug in without caring that they are being used for MM or some other application. > 3) If this is too small a task for the whole summer I think it could be made > part of a slightly larger login/user-related package. The wiki page for last > year's GHC11 Open source day [4] describes some ideas that could fit in > nicely (for example storing some additional user info, like their twitter > account, ... see section "Subscriber info summary"). In keeping with current events: > As I said these are random thoughts... Is there enough entropy? :) Richard _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://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: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
