Malcolm, <- Remembered the 'l' this time! To keep things simple and avoid fragmenting this discussion into a million different dead end tit for tats , I'll try to reign in the main points.
1. The default authentication method in Django should have no inherent restrictions. Such as blocking '@' in the username. This leaves the default framework open and free of workarounds. This approach would not preclude any project specific requirements. 2. Any authentication method having restrictions should be an opt in method. The current method is a restrictive authentication method, one that does not allow email, and should be made optional. 3. When you boil down the hundreds of specific use cases out there you still end up with the above two points. In which case I would make the argument that if you need to block emails as user names then it is you who should write a new authentication handler. In your own words, the framework allows this and its only a few lines of code. Now for the dead end tit for tat... this is really project philosophy not framework philosophy... hence I feel like it is circular discussion that distracts from the main point... Authenticating by email does not require me to check my email every time I log in. So if my email is no longer accessible (left my job) I can simply log in and change it to a new one. If changing the username requires checking my email then I will have the same problem if I use email as my username or not. You yourself identify the username as mainly an authentication mechanism not necessarily a display value. Thats all the more reason to have a robust restriction free out of the box implementation of authentication. Thanks for reading the feedback, I still fail to see how you can include project specific requirements in a framework? The implementation you are advocating is a subset of the general implementation I would like to see bundled out of the box. Why not move it into an optional module? -Paul On Apr 11, 4:13 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Sat, 2009-04-11 at 07:52 -0700, pkenjora wrote: > > Malcom, > > Well, I'm not "Malcom" (sic), but I'll reply anyway. > > > Google, FaceBook, and LinkedIn have been using email authentication > > for how long now? With the default constraints you've put on Django a > > developer would have to "work around" the out of the box code to make > > the project behave like the big 3 names on the web. > > There's some assumption there that what they're doing is a good idea. > Their systems have the usability problems I've mentioned. It's also not > clear their authentication methods are the best around. In any case, as > I note below (and have written elsewhere), you're simply not restricted > from using this system and can do so without patching Django, if that's > the way you want to go. There's no restriction in place here! > > The combined size of forums and social networking sites not pretending > that my "handle" is an email address is, I'll wager, larger than > Facebook or LinkedIn, certainly. Which has precisely the same small > weight as your examples. The point being that there are valid use-cases > in both directions and you'll notice that that's never been disputed. > > [...] > > > As far as your reasons go, I'm fairly sure its just as easy to > > change the email as it is the username, > > I'm sorry you feel that way. It's patently false. The username is only > used on the site you are creating an account for. Your email address has > much wider usage and creating a new one isn't always possible or > desirable (signing up to one of the hosted services requires agreeing to > T&C that are often unpleasant). The username when creating a new account > on a site has much less currency. > > > I would even argue that my > > username (display name) could change but my login credentials should > > stay the same. > > You are assuming that the username is the display name. That might be a > secondary use for it and it sometimes works well for that. However, the > username is primarily the unique identifier for the user within the > system. It's the thing that won't change. Having a display name, > particularly one that can change is also quite common and it's for > extensions like that that user profile exist for. > > Login credentials are not the same as identifier within the system. The > login credentials should definitely be permitted to change. Having an > account tied to an email address is tragic when that email address is no > longer accessible to you (for example, it was a company address and > you've since left the company). Allowing the email address to change -- > and hence not making it the entity identifier -- is a good thing. > > > You are correct, username authentication has always been around. > > However, the explicit banning and obfuscating of email authentication > > in the default module has not. > > I'm sorry, but that's simply not correct. I pointed that out earlier in > the thread. > > You have the version control history, please feel free to find the > released version of Django where this wasn't the case and correct me if > you really feel this is not the case. > > > That is the part that worries me, that > > is where things are going wrong. > > > We're all professionals here, we all take the time to leave feedback > > in the hopes of improving Django. > > Which is a given. Not a partricularly relevant comment for this thread, > unless you're trying to imply something sinister, since there's no > indication that feedback isn't being listened to. In fact, in this case, > it's being answered with both technical and usability reasons for the > current behaviour. > > > I have a sneaking suspicion that > > project specific requirements crept into the trunk because it was > > easier than patching every time. > > Whereas, I have a sneaking suspicion that you've forgotten your history. > Now we both have sneaking suspicions. It's all very suspicous. :-) > > Part of the problem with threads like this is the built-in assumptions > people are bringing to the table. The username field in the User model > is just the unique identifier in the system. If you want to use the > email address for login, it's fairly easy to do so: writing auth > backends is supported and encouraged. You never have to show the > username to users (so you could generate a more-or-less random > identifier when creating the account) and that's fairly standard > practice in a bunch of projects I've seen. It's also not uncommon to add > a user-editable display name in a user profile class, etc, etc. > > You're argument is about a bit of a red herring because it's assigning > more import to the username field than it deserves. That field simply > isn't intrinsic to a user's experience on the site because you are in > complete control as to what information you show and what information > you authenticate against on your site. Before complaining that "oh, no, > now I have to write my own login method", yes, big deal! You have to > write half a dozen lines once, or use somebody else's. Just like you do > when supporting OpenID or Facebook Connect or other authentication > systems. > > Django has a default auth system. It works well for a large class of > situations. It's also easy enough to use other systems, including an > email address as an authentication facilitator. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
