Re: auth.User usernames

[Tom Evans]

On Sat, Feb 18, 2012 at 4:25 AM, Tai Lee  wrote:
> It's not that hard to just set up a OneToOneField back to User, and
> use signals to automatically create a User when you create your own
> User/Profile. Then you can still make use of 3rd party apps that rely
> on contrib.auth or contrib.sessions, and also make use of groups from
> contrib.auth, etc.
>
> Cheers.
> Tai.
>

Once you are aware of the issue, it's easier to change the code so
that it DTRT in the first place. Any other solution has notable
downsides, like the username field not being what the user enters to
log in with, the email field not being correct.

Eg, with your fix authenticating/storing longer emails on a
UserProfile object may work, but it's unlikely that third party code
which sends emails will be aware that the correct email address to use
is user.get_profile().real_email_field rather than user.email.

Those sorts of bugs are much harder to find/fix than the actual bugs,
which are that both email and username fields are too short, and the
username field has arbitrary restrictions on what it can contain.

Cheers

Tom

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.User usernames

[Tai Lee]

It's not that hard to just set up a OneToOneField back to User, and
use signals to automatically create a User when you create your own
User/Profile. Then you can still make use of 3rd party apps that rely
on contrib.auth or contrib.sessions, and also make use of groups from
contrib.auth, etc.

Cheers.
Tai.


On Feb 17, 9:13 pm, Jonathan Slenders 
wrote:
> On 16 fév, 13:05, Tom Evans  wrote:
>
> > 75 isn't large enough these days for either email or username. We run
> > a patched version of django for some time that has changed both these
> > fields to 255 characters in order to accommodate the needs of our
> > users. See RFC 3696.
>
> This and other issues made us moving away from contrib.auth and
> contrib.sessions. It's not too hard to write your own custom
> authentication and session middleware, and you can migrate whereever
> you want to. The main problem is if you depend on other libraries with
> rely on the existance of auth.models.User, like contrib.admin.
>
> Personally, I think a lot of the apps in django.contrib have a lack of
> flexibility. Maybe it's good to leave these apps as they are, but
> start something like contrib_v2, as the improved version.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.User usernames

[Donald Stufft]

It's not just the django.contrib apps you lose, it's any app that uses a 
ForeignKey  
to users. Which can be a lot of them.


On Friday, February 17, 2012 at 5:13 AM, Jonathan Slenders wrote:

>  
> On 16 fév, 13:05, Tom Evans  (http://googlemail.com)> wrote:
> > 75 isn't large enough these days for either email or username. We run
> > a patched version of django for some time that has changed both these
> > fields to 255 characters in order to accommodate the needs of our
> > users. See RFC 3696.
> >  
>  
>  
> This and other issues made us moving away from contrib.auth and
> contrib.sessions. It's not too hard to write your own custom
> authentication and session middleware, and you can migrate whereever
> you want to. The main problem is if you depend on other libraries with
> rely on the existance of auth.models.User, like contrib.admin.
>  
> Personally, I think a lot of the apps in django.contrib have a lack of
> flexibility. Maybe it's good to leave these apps as they are, but
> start something like contrib_v2, as the improved version.
>  
> --  
> 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 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>  
>  


-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.User usernames

[Jonathan Slenders]

On 16 fév, 13:05, Tom Evans  wrote:
> 75 isn't large enough these days for either email or username. We run
> a patched version of django for some time that has changed both these
> fields to 255 characters in order to accommodate the needs of our
> users. See RFC 3696.

This and other issues made us moving away from contrib.auth and
contrib.sessions. It's not too hard to write your own custom
authentication and session middleware, and you can migrate whereever
you want to. The main problem is if you depend on other libraries with
rely on the existance of auth.models.User, like contrib.admin.

Personally, I think a lot of the apps in django.contrib have a lack of
flexibility. Maybe it's good to leave these apps as they are, but
start something like contrib_v2, as the improved version.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.User usernames

[Tom Evans]

On Wed, Feb 15, 2012 at 10:37 PM, Donald Stufft  wrote:
> I know this has been discussed before, but I wanted to bring it up again in
> light of the oncoming Djnago 1.4 beta.
>
> Can we increase the length of the username field in auth.User?
> I think that a max_length of 75 (to match the default EmailField) would allow 
> developers
> a lot more breathing room with regards to what they use as the value for 
> username.

75 isn't large enough these days for either email or username. We run
a patched version of django for some time that has changed both these
fields to 255 characters in order to accommodate the needs of our
users. See RFC 3696.

Schema migration concerns aside, it is a pity that Django continues to
ship with a non conforming understanding of what an email may be.
Personally, I believe this is a nonsense concern - if you state in the
relnotes that a field has changed size, and that you must update your
database schemas, **and people don't do it**, the only issue that can
occur is that when a user attempts to use a longer email address or
username the failure is an IntegrityError instead of a form error. Big
whoop, should have read the relnotes.

Each django "minor"* version release that I have updated through has
included equally disruptive changes, I don't see why the prevarication
over this one.

I understand that the timing isn't great for this right now, but this
is not an unknown or new problem. Another major release slips by
without a fix for this. mañana, mañana…

Cheers

Tom


* As in '1.1 -> 1.2', not as in 'insignificant version'

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.User usernames

[Tai Lee]

I created a generic `accounts` app which has (among other things) it's
own `Profile` model with a username field and a OneToOneField pointing
at `User`. I added an authentication backend to my settings that
checks usernames from my model. Of course there are other supporting
components, forms, signals, etc., but this has removed any Django
username limitations for me pretty easily.

This might be a little inconvenient, but it works well here and I
still have a `User` for every `Profile` so I can hook into Django
sessions and groups. If you are having trouble with `User.username`
right now or anticipate issues in the near future, I suggest you
implement something similar yourself, or find an open source generic
app that does it for you, as I think it will likely be a very long
time until this is resolved in Django.

Cheers.
Tai.


On Feb 16, 9:57 am, Donald Stufft  wrote:
> On Wednesday, February 15, 2012 at 5:49 PM, James Bennett wrote:
> > On Wed, Feb 15, 2012 at 4:37 PM, Donald Stufft  > (mailto:donald.stu...@gmail.com)> wrote:
> > > I know this has been discussed before, but I wanted to bring it up again 
> > > in
> > > light of the oncoming Djnago 1.4 beta.
>
> > So, here's the thing: you're asking for a fairly significant,
> > massively backwards-incompatible change which requires every Django
> > install on the planet to do a schema migration... about four hours
> > before we feature-freeze 1.4. There is simply no way this is going to
> > get in on that time scale; 1.5, maybe, if the inherent problems can
> > get ironed out, and if you're strongly interested in making this
> > happen I'd invite you to help out with that.
>
> > But 1.4 beta -- and thus feature freeze -- happens tonight, and it's
> > flat impossible to land something of this magnitude before that
> > happens.
>
> 1.5 would work as well ;) Sorry I sometimes speak before I think things 
> through,
> thoroughly. django.auth in general is something that i'm interested in and I 
> want
> to try and improve to be more flexible, I just hadn't though of a general 
> solution yet
> and a "easy" (code wise) fix appealed in a shorter term "provide some 
> improvement"
> sort of way.
>
>
>
>
>
>
>
> > --
> > "Bureaucrat Conrad, you are technically correct -- the best kind of 
> > correct."
>
> > --
> > 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 
> > (mailto:django-developers@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com 
> > (mailto:django-developers+unsubscr...@googlegroups.com).
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.User usernames

[Łukasz Rekucki]

On 15 February 2012 23:57, Donald Stufft  wrote:
>
> 1.5 would work as well ;) Sorry I sometimes speak before I think things
> through,
> thoroughly. django.auth in general is something that i'm interested in and I
> want
> to try and improve to be more flexible, I just hadn't though of a general
> solution yet
> and a "easy" (code wise) fix appealed in a shorter term "provide some
> improvement"
> sort of way.
>

AFAIR, the last consensus was to get some basic schema alternation API
into Django (see the last GSOC), so that we can fix things like that.
So the general solution would be doing that ;). Just changing it,
helps new installations, but breaks old ones.

PS. Since Facebook started generating fake addresses, 75 characters on
the email field is also no good, so matching that doesn't solve
anything ;)

-- 
Łukasz Rekucki

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.User usernames

[Max Thayer]

I and some folks in my area (Boston/Cambridge, MA) are thinking of ways to
provide a solution to this problem that neither requires schema migration
nor breaks backwards compatibility. David, if you (or anyone on this
mailing list) is interested, email me and let's coordinate our efforts.

Alternatively, if all you need is a longer username, this monkey patch
works nicely: https://github.com/GoodCloud/django-longer-username

Best regards,
Max

On Wed, Feb 15, 2012 at 5:57 PM, Donald Stufft wrote:

> On Wednesday, February 15, 2012 at 5:49 PM, James Bennett wrote:
>
> On Wed, Feb 15, 2012 at 4:37 PM, Donald Stufft 
> wrote:
>
> I know this has been discussed before, but I wanted to bring it up again in
> light of the oncoming Djnago 1.4 beta.
>
>
> So, here's the thing: you're asking for a fairly significant,
> massively backwards-incompatible change which requires every Django
> install on the planet to do a schema migration... about four hours
> before we feature-freeze 1.4. There is simply no way this is going to
> get in on that time scale; 1.5, maybe, if the inherent problems can
> get ironed out, and if you're strongly interested in making this
> happen I'd invite you to help out with that.
>
> But 1.4 beta -- and thus feature freeze -- happens tonight, and it's
> flat impossible to land something of this magnitude before that
> happens.
>
>
> 1.5 would work as well ;) Sorry I sometimes speak before I think things
> through,
> thoroughly. django.auth in general is something that i'm interested in and
> I want
> to try and improve to be more flexible, I just hadn't though of a general
> solution yet
> and a "easy" (code wise) fix appealed in a shorter term "provide some
> improvement"
> sort of way.
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>  --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.User usernames

[Donald Stufft]

On Wednesday, February 15, 2012 at 5:49 PM, James Bennett wrote:
> On Wed, Feb 15, 2012 at 4:37 PM, Donald Stufft  (mailto:donald.stu...@gmail.com)> wrote:
> > I know this has been discussed before, but I wanted to bring it up again in
> > light of the oncoming Djnago 1.4 beta.
> > 
> 
> 
> So, here's the thing: you're asking for a fairly significant,
> massively backwards-incompatible change which requires every Django
> install on the planet to do a schema migration... about four hours
> before we feature-freeze 1.4. There is simply no way this is going to
> get in on that time scale; 1.5, maybe, if the inherent problems can
> get ironed out, and if you're strongly interested in making this
> happen I'd invite you to help out with that.
> 
> But 1.4 beta -- and thus feature freeze -- happens tonight, and it's
> flat impossible to land something of this magnitude before that
> happens.
> 
> 
1.5 would work as well ;) Sorry I sometimes speak before I think things through,
thoroughly. django.auth in general is something that i'm interested in and I 
want
to try and improve to be more flexible, I just hadn't though of a general 
solution yet
and a "easy" (code wise) fix appealed in a shorter term "provide some 
improvement"
sort of way. 

> -- 
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
> 
> -- 
> 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 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 
> 


-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.User usernames

[James Bennett]

On Wed, Feb 15, 2012 at 4:37 PM, Donald Stufft  wrote:
> I know this has been discussed before, but I wanted to bring it up again in
> light of the oncoming Djnago 1.4 beta.

So, here's the thing: you're asking for a fairly significant,
massively backwards-incompatible change which requires every Django
install on the planet to do a schema migration... about four hours
before we feature-freeze 1.4. There is simply no way this is going to
get in on that time scale; 1.5, maybe, if the inherent problems can
get ironed out, and if you're strongly interested in making this
happen I'd invite you to help out with that.

But 1.4 beta -- and thus feature freeze -- happens tonight, and it's
flat impossible to land something of this magnitude before that
happens.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

auth.User usernames

[Donald Stufft]

I know this has been discussed before, but I wanted to bring it up again in
light of the oncoming Djnago 1.4 beta. 

Can we increase the length of the username field in auth.User? It is a common
pattern for emails to be used instead of usernames for a site, and 30 characters
makes it difficult to follow that pattern. There are work arounds but they are 
all
a lot less elegant than increasing the length of the username field. I think 
that
a max_length of 75 (to match the default EmailField) would allow developers
a lot more breathing room with regards to what they use as the value for 
username.
75 Would support most emails, usernames, UUIDs, etc. If 75 is too long for the
"username" case you could set the max_length of the form to 30 still, allowing
developers who want to use a longer value the ability to either subclass the 
form
or provide their own form, which they can easily do, while still using the 
auth.User
model which replacing is not something that is particularly easy or clean to do.

Obviously there the overall problem of contrib.auth being inflexible to the 
differing
requirements of varying problems but I don't think we should let a possible
future improvement stop a small improvement that can be made today, in
other words don't let the best be the enemy of good.


-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.