Hi Further to the above discussion, I did implement the code and it worked for me for the authentication while using the email id as the username (username=emailid ; valid_user = authenticate (username=username, password=password )
# django-admin.py --version 1.1 beta 1 SVN-10957 1.) The problem is in the admin interface "@" is not accepted as username while I can populate the same from the view.py Is this an expected behaviour or should I raise a ticket ( if at all it doesnt exists ) 2.) Do we have a configuration file or so where we can define these constraints like max_length of user name, accepted characters set in the user name and others. I can very well change the code in django-trunk of my web server, but I dont want to do that since I want to avoid the overhead of re-doing the svn tasks Thanks Vemu On Apr 13, 11:22 am, Praveen <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
