You can do it however you like, since the user will never see it.
Something as simple as taking the email address, replacing "@" with "AT"
and "." with "DOT" might work.
One thing I did for a client was take the email address, trip off
everything after the "@" and then continue adding a number to the end of
the username until it was unique. So if t...@example.com registered
first, he would be username "tim" and t...@foo.bar.org would be username
"tim1", since "tim" was already in use. Since all registration is
normally done through one or two places, it only required setting up the
registration form handling view and writing a management command tool to
add a user manually. These days, I might also add some admin overrides,
but I didn't need that at the time.
Regards,
Malcolm
One reason is that usernames can be made to be unique, since you're
selecting a new username and if the one you choose is already taken, you
can choose another one. You cannot, however, easily change your email
address and there are cases of different people sharing a single email
address or the same person needing/wanting to create multiple accounts.
Another reason is likely simply historical; usernames that *aren't*
email addresses are much more readable and traditional in social-based
sites and that was what was used in the initial implementation. The
uniqueness problem mentioned above is very real, however, so Django is
protecting people from doing dumb things here. If you want to work
around that, it's possible and fairly easy, but not heavily advisable.
> I always like Django because it didn't try to force development down
> a specific path. All developers have their own way and every project
> is unique, for a long time Django accommodated that. I'm a bit
> worried about where this is going...
It's not "going" anywhere. The username requirements have been the same
since the very first day you used Django. Don't frame this as something
slipping out of control, please.
>
> I'm worried that the workarounds just introduce unnecessary
> complexity.
Almost as if you shouldn't workaround a valid constraint, isn't it? :-)
Regards,
Malcolm
You are correct, username authentication has always been around.
However, the explicit banning and obfuscating of email authentication
in the default module has not. That is the part that worries me, that
is where things are going wrong.
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
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