You please check the satchmo package there they are using email as username in satchmo-registration using user=generate_id(email,firstname)
On Apr 13, 9:44 am, pkenjora <pkenj...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
