deprecation of AUTH_PROFILE_MODULE

[Mikhail Korobov]

Hi folks, 

what do you think about deprecating AUTH_PROFILE_MODULE and .get_profile() or removing the suggestion to use it from the docs in 1.4 release?

There are broader issues with extending User model but I think this one can be handled separately.

Some links:

* http://code.djangoproject.com/ticket/15937

* https://groups.google.com/d/topic/django-developers/WPGqQ1dGnCQ/discussion

* https://groups.google.com/d/topic/django-developers/1Xj8Zzdokrw/discussion

[Karen Tracey]

On Sun, May 1, 2011 at 12:39 PM, Mikhail Korobov <kmi...@googlemail.com> wrote:

Hi folks, 

what do you think about deprecating AUTH_PROFILE_MODULE and .get_profile() or removing the suggestion to use it from the docs in 1.4 release?

There are broader issues with extending User model but I think this one can be handled separately.

-1 on deprecating it before having something better to replace it.

Karen

[Russell Keith-Magee]

Completely agreed. get_profile may not be ideal, but it's better than
providing nothing, and cleaning up get_profile will be a logical
extension of any good auth.User refactor.

Yours,
Russ Magee %-)

[Carl Meyer]

On 05/02/2011 07:15 AM, Russell Keith-Magee wrote:
>>> what do you think about deprecating AUTH_PROFILE_MODULE and .get_profile()
>>> or removing the suggestion to use it from the docs in 1.4 release?
>>> There are broader issues with extending User model but I think this one
>>> can be handled separately.
>>
>> -1 on deprecating it before having something better to replace it.
>
> Completely agreed. get_profile may not be ideal, but it's better than
> providing nothing, and cleaning up get_profile will be a logical
> extension of any good auth.User refactor.

Deprecating get_profile() is pretty low on my priority list, but I'm a
bit confused by these two comments. What exactly does get_profile()
offer that needs to be "replaced" or is actually "better than providing
nothing"? Or, more specifically, better than recommending a
OneToOneField and the usual ORM accessor (even leaving aside the
multiple-profiles case)? In every way that I can see, it is worse than
that: it's a special case, requires additional cognitive overhead to
learn, more characters to type, more runtime processing, more code in
Django to maintain, and adds zero value.

The only possible argument for it I can see is that it provides a
standardized way for reusable apps to get at a project's user profile
model. But given that no assumptions can be made about what is on the
profile model, the range of useful uses for that is pretty much limited
to one case: providing some pre-built URLs etc for creation and editing
of profiles; i.e. django-profiles. And even that case gains nothing from
AUTH_PROFILE_MODULE being a built-in feature of Django as opposed to an
external setting documented by django-profiles itself.

I don't mind leaving get_profile() around, I guess, but IMO the best
argument that can be made for that is "it's useless but mostly harmless,
and it's not worth making people change their code to remove it." I'll
continue to recommend in IRC and elsewhere that people avoid using it.

Carl

[Jeremy Dunck]

On Mon, May 2, 2011 at 9:54 AM, Carl Meyer <ca...@oddbird.net> wrote:
...

> I don't mind leaving get_profile() around, I guess, but IMO the best
> argument that can be made for that is "it's useless but mostly harmless,
> and it's not worth making people change their code to remove it." I'll
> continue to recommend in IRC and elsewhere that people avoid using it.

Given a blank slate, what would Auth look like these days? And can we
work towards that?

[Carl Meyer]

On 05/02/2011 11:38 AM, Jeremy Dunck wrote:
> Given a blank slate, what would Auth look like these days? And can we
> work towards that?

Now, why you gotta get all constructive and forward-thinking and stuff? ;-)

Here's my list of core ideal-contrib.auth desiderata that I keep seeing
crop up in related threads:

1. A specification of the minimal useful interface for a User (perhaps
in the form of an abstract base model?)

2. A way to provide your own User class that extends the minimal spec,
in a single table (i.e. MTI need not apply).

3. A way for reusable apps to access and point foreign keys at the User
model (solutions that involve magically transporting models into other
modules need not apply - Django's been there, not going back).

4. A migration path that meets our backwards-compatibility standards.

Abstract base models already can handle 1 & 2, but if we take that
approach we still lack solid proposals for 3 & 4. And of course there
are many questions left untouched here (groups? permissions?), but these
are the core elements that I don't think I've heard much, if any,
disagreement on. I'd be interested to know if anyone sees a problem with
any of the above, or what people would add as core requirements.

Carl

[Shawn Milochik]

Since it wasn't stated explicitly in that last wish-list, I'd like to
add: No assumption that the primary key is an integer.

[Jannis Leidel]

On 02.05.2011, at 19:22, Carl Meyer wrote:

> On 05/02/2011 11:38 AM, Jeremy Dunck wrote:
>> Given a blank slate, what would Auth look like these days? And can we
>> work towards that?
>
> Now, why you gotta get all constructive and forward-thinking and stuff? ;-)
>
> Here's my list of core ideal-contrib.auth desiderata that I keep seeing
> crop up in related threads:
>
> 1. A specification of the minimal useful interface for a User (perhaps
> in the form of an abstract base model?)
>
> 2. A way to provide your own User class that extends the minimal spec,
> in a single table (i.e. MTI need not apply).
>
> 3. A way for reusable apps to access and point foreign keys at the User
> model (solutions that involve magically transporting models into other
> modules need not apply - Django's been there, not going back).

As I've said before in person and on IRC, 2. and 3. will most likely be
possible with the app-loading branch. It introduces a notion of an app
class that would (among other things) allow to override the default auth
app by mimicking its API.

This is done by simply telling the app cache to consider a different app
as the app with the "auth" app label. E.g.:

$ cat myapp/models.py
from django.db import models
from django.contrib.auth.models import BaseUser # abstract base user

class User(BaseUser):
middle_name = models.TextField()

class Meta:
verbose_name = "My user"

$ cat myapp/app.py
from django import apps

class MyAuthApp(apps.App):

class Meta:
label = 'auth'
db_prefix = 'auth'

Then, in good tradition of duck typing, we use models.ForeignKey('auth.User')
to point to that custom user class, forcing the app cache to return the
myapp.models.User class.

> 4. A migration path that meets our backwards-compatibility standards.

As far as I understand there is little effort needed to split the User
model in an abstract base class and a concrete implementation that is
similar to the current class. Whether this needs some kind of migration
path is a different story.

Jannis

[Russell Keith-Magee]

On Tue, May 3, 2011 at 1:28 AM, Shawn Milochik <sh...@milochik.com> wrote:
> Since it wasn't stated explicitly in that last wish-list, I'd like to add:
> No assumption that the primary key is an integer.

Certainly worth stating, but I don't think it's a major technical
challenge. An abstract base class approach should allow for the
concrete class to define the primary key type that is in use.

Yours,
Russ Magee %-)

[Russell Keith-Magee]

"Better than nothing" was perhaps a bad choice of phrase on my part.
My point is that it does serve a purpose, however tangential -- it
provides an API hook that we can point at when someone says "How do I
put custom data on my User object". For me, when combined with the
fact that it's not hurting anyone to keep it around, this tangential
documentation benefit is the reason to keep it around until we "fix"
User -- even if we de-emphasise its use.

Yours,
Russ Magee %-)

[Alper Çuğun]

I looked into this today with 1.5 hitting and working on a project and this seemed relevant.

On Monday, 2 May 2011 19:22:53 UTC+2, Carl Meyer wrote:

1. A specification of the minimal useful interface for a User (perhaps

in the form of an abstract base model?) 

A User should not require a username. Usernames are a hideous remnant that are impossible to justify on consumer facing websites. Authentication on e-mail should be built-in if not the default.

 

4. A migration path that meets our backwards-compatibility standards.

I saw the configurable User model that just landed in 1.5 but for a non-library developer this is not very useful. It looks like a very large amount of code for a rather small function.

Furthermore: “If you intend to set AUTH_USER_MODEL, you should set it before running manage.py syncdb for the first time.” is somewhat prohibitive to existing projects. “you may need to look into using a migration tool like South to ease the transition.” is not really a solution unless it is obvious what changes should be made.

Also I don't understand: “This example illustrates how most of the components work together, but is not intended to be copied directly into projects for production use.” Code that is ready for production is the point of the documentation for me. If this isn't, I think it's a documentation bug.

Best,

Alper

[Russell Keith-Magee]

On Thu, Feb 28, 2013 at 4:24 AM, Alper Çuğun <al...@alper.nl> wrote:

I looked into this today with 1.5 hitting and working on a project and this seemed relevant.

On Monday, 2 May 2011 19:22:53 UTC+2, Carl Meyer wrote:

1. A specification of the minimal useful interface for a User (perhaps

in the form of an abstract base model?) 

A User should not require a username. Usernames are a hideous remnant that are impossible to justify on consumer facing websites. Authentication on e-mail should be built-in if not the default.

 

A user *doesn't* require a username. It requires a unique identifying field. However, by default, for historical reasons, the Django's built-in User model has a username field. The whole point of the new feature is that specifying an alternative is now a simple activity.

4. A migration path that meets our backwards-compatibility standards.

I saw the configurable User model that just landed in 1.5 but for a non-library developer this is not very useful. It looks like a very large amount of code for a rather small function.

It's not clear what you're suggesting here. Django has a built in User model. That hasn't changed. You can now specify your own User model, and reuse large parts of Django's built in parts if that is helpful in your circumstances. What exactly is your concern here?

 

Furthermore: “If you intend to set AUTH_USER_MODEL, you should set it before running manage.py syncdb for the first time.” is somewhat prohibitive to existing projects. “you may need to look into using a migration tool like South to ease the transition.” is not really a solution unless it is obvious what changes should be made.

Well, this is a situation where we can't provide documentation, because everyone's specific circumstances will be different. The best advice for custom user models is "set it before you run syncdb", which is what we've said. If you've already run syncdb, you'll need to migrate your models… but exactly what that entails will entirely depend on what your own project has done.

 

Also I don't understand: “This example illustrates how most of the components work together, but is not intended to be copied directly into projects for production use.” Code that is ready for production is the point of the documentation for me. If this isn't, I think it's a documentation bug.

The point of that comment is that you shouldn't treat the documentation as a cargo-cult, just copying and pasting. What is there will *work*. However, in a real application, you need to pay attention to error messages, validation conditions and so on.  

Yours,

Russ Magee %-)

[Luke Sneeringer]

I do think that there's a pretty common "alternate use case" which we could support more easily. That's the use case where someone wants a User model that is either:

 * exactly like the Django User model, but with e-mail address as the unique identifying field instead of username
 * exactly like the above bullet, but with additional fields

The new 1.5 user customization makes adding fields to the user model a very trivial task, but it's still a lot of code to make e-mail addresses serve the function of usernames. You need to write the model, define USERNAME_FIELD, REQUIRED_FIELDS, and all the methods, which basically work almost identically to the auth.User reference implementation. It's also not very DRY.

I was considering writing an implementation of this, which I think would see a lot of use, and putting it up on PyPI, but it seems like something that would be even better if offered as part of Django itself.

Here is, I think, a way we could do it without breaking backwards compatibility:

 * Make an EmailBasedUser class which functions identically to User, except that email is the USERNAME_FIELD.
 * Make auth.User subclass EmailBasedUser, add `username` and set it as USERNAME_FIELD. User would still be AUTH_USER_MODEL.
 * Provide instructions in the documentation saying, "If you only want this one change, set AUTH_USER_MODEL to django.contrib.auth.EmailBasedUser

What is driving me here is that I think that this is a very common use case -- "I just want email addresses to function as usernames", and Django 1.5 still seems to require a lot of code to do that. It seems like it should be a quick change -- "just change this one setting" -- and it's not.

I'd be interested in actually doing this if folks on the list think it's a good idea.

Best Regards,

Luke Sneeringer

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Florian Apolloner]

Hi,

On Friday, March 1, 2013 9:00:28 PM UTC+1, Luke Sneeringer wrote:

I'd be interested in actually doing this if folks on the list think it's a good idea.

Doing it outside of Django core if fine, inside core is -0 to -1 from me.

Cheers,
Florian

[Jacob Kaplan-Moss]

On Fri, Mar 1, 2013 at 12:04 PM, Florian Apolloner
<f.apo...@gmail.com> wrote:
> Doing it outside of Django core if fine, inside core is -0 to -1 from me.

I actually strongly disagree: I think Django *should* ship an
"authenticate-using-email" system. It's *SUCH* a common desire, and
it's actually fairly tricky to get all the pieces in place to do it
right. I just cruised StackOverflow: it's asked a ton, and the answers
all have something not-quite-right about them, especially now that 1.5
has shipped.

So I'm +1 on including something in core. Luke, do you think you can
work up a patch? I can't promise it'd go in -- I'm not going to
overrule a -1 from Florian by fiat -- but I think having a concrete
patch on the table will make it easier to make a decision. So if you
don't mind doing a bit of "spec work" that'd probably give you us best
chances of getting this in.

Jacob

[Florian Apolloner]

Hi Jacob,

On Sunday, March 3, 2013 5:08:24 PM UTC+1, Jacob Kaplan-Moss wrote:

I actually strongly disagree: I think Django *should* ship an
"authenticate-using-email" system.

Out of curiosity, since I barely have this need by myself: Is it "authenticate-using-email" or "use-email-as-username". Authentication via Email can be done via a backend easily (though we should make the email column unique then). So I am wondering what the main issue here is: is it having username beeing a required field (an uuidv4 should suffice as a workaround currently) or something different?

I can't promise it'd go in -- I'm not going to
overrule a -1 from Florian by fiat -- but I think having a concrete
patch on the table will make it easier to make a decision.

No worries, if it would exist it would have been a -0.5; either way, a concrete patch would certainly help. If it does make it into core I'd still prefer the most minimal solution possible.

Regarding the current proposal: Luke, can you tell us how your changes would play with the current forms etc? Especially since some forms have a hard coded dependency on a concrete user model (by design). I'd prefer not to duplicate all those forms if somehow possible.

Cheers,
Florian

[Daniel Greenfeld]

I agree that email-as-username should be a built-in User abstract model (or something) in Django. It's an incredibly common use case and for once I think Django could use some additional functionality.

+1 to email as username model in core.

Danny