Hi Richard, On Friday, February 17, 2012 21:59 CET, Richard Wackerbarth <rich...@nfsnet.org> wrote: > 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.
Agreed. Django's User model most definitely covers all our needs. The thing I am not sure about is: What kind of user info ends up in the core DB and what should be stored in the web ui db. In theory we don't need any kind of permanent storage in the web ui, because the core already has a pretty comprehensive user model (storing user names, email addresses, roles, memberships etc). OTOH it could make great sense to enhance this data with all kinds of crazy things that could be stored in the web ui. Or to store some user data temporarily to reduce API calls. But this means we'd have two different data sources since the web ui should not access the core db directly. > 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. Yep, very convenient. The process would be initiated via the client-JS and verified server-side in the django-backend. Without ever touching the REST API. > 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. I think Barry has had some similar ideas... > > 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. I agree, no re-implementing the User model! In fact, I think we mean the same thing, because django's custom auth backends are simply a way to handle auth externally *and* tie that to the existing user/permissions system. Of course, if we implement such a custom backend we should do it in a generic and reusable way. I just think making a full-blown django app for what is usually just a .py file might be a bit overkill... But as I said: debatable... ;-) I guess in the end it's not a question of whether or not we make use of the Django User model. (At least to me) the question is: Do we use it to store user data permamently in the web ui or just temporarily on a request/session basis. Or a mix of both. > In keeping with current events: > > > As I said these are random thoughts... > > Is there enough entropy? :) Well, not completely random, I guess ;-) Florian _______________________________________________ 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
