On 3/14/06, Max Battcher <[EMAIL PROTECTED]> wrote: > > Joseph Kocherhans wrote: > > On 3/14/06, Max Battcher <[EMAIL PROTECTED]> wrote: > >> -1. I don't want to add layer after layer of code to my views to > >> support whatever authentication backends I feel necessary. > > > > You don't have to. There is "one true way" to access authentication > > regardless of the backend. The specific backend(s) are controlled via > > settings. > > This isn't very obvious in your "simple" wiki post. So you are saying > that every authentication backend, if successful, should set > request.user? How is backend ordering handled?
The backends don't have to set request.user. This is handled in the django.contrib.auth.middleware.UserWrapper, which is used by AuthenticationMiddleware and is installed by default. Backend ordering is basically the same as before. Sorry that I didn't document it, it was hinted at in the patch. I've updated the wiki/patch. > All of this was somewhat obvious in the last version of the page. If > you are going to refactor an entire page, at least include information > on where the true differences are. I'm really having a hard time seeing > where your example is any simpler/more useful because you wrote the > document entirely different. I've added a section at the top describing the main differences. > AFAICT, the only real simplification here is the removal of the > Credential abstraction, which couples the backends directly to the > HttpRequest! I'm not sure if this is an improvement. I think you're right here. I forgot about a few cases where the abstraction *does* buy you something (namely http basic/digest auth). I was getting annoyed that each backend has to test for what kind of credentials it's getting and... well, I'm putting it back. > The other thing > is the replacement of a list of backends with only a single backend > setting. This assumes that most people only want one backend, and makes > anyone who wants multiple backends bend over backwards. This is probably just a misunderstanding, although I'd argure that most people *do* only want 1 backend. Please check the configuration example I added and let me know if you still feel that way. Using multiple backends requires adding 2 settings, plus whatever backend specifc settings you need. > It also assumes that every > backend will be able to persist the current logged in user as a simple > user_id number. id != integer. It's simply a unique identifier, usually a username, but it could be a token, an email address, a url or whatever. It just has to be unique for that backend. Sorry, I forgot the the django semantics of "id" implies an integer. Maybe I should go back to using "login" to label the concept. > >> Similarly, > >> once a user is "active" (noted in the session), I want RequestContext to > >> know it so that my generic views are seeing the same thing that the > >> other views are seeing. > > > > I'm not sure where you get the idea that different views would "see" > > anything different. Could you point be more specific? request.user is > > still lazily populated using settings.AUTHENTICATION_BACKEND which > > defaults to using the standard Django tables. > > This is not mentioned in your design document. It's now in the "Authentication" section. Thanks for your feedback Max. I've spent so long with this problem that I didn't dump enough of what's in my head out to the wiki/code. Joseph --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
