contrib.Auth

[Vitaly Babiy]

Hey Guys,

So 1.2 is almost out the door so I wanted to raise an issue that I would love to start working to fix for 1.3.

As we all have used the contrib.Auth application we know there are some short comings in the application. Here is a couple of issue that I have noticed since using it.

- If you change the auth backend it will make the test suite fail.

- Hard to extend the user object.

I know people have had more, I would like this thread to service as an brainstorming section for what is wrong with the application and even some idea on how to fix them.

--

This is also the first time I have been involved in a big part of django if I am not following protocol please let me know, Thansk.

Vitaly Babiy

[Karen Tracey]

On Mon, Feb 8, 2010 at 6:39 PM, Vitaly Babiy <vbab...@gmail.com> wrote:

Hey Guys,

So 1.2 is almost out the door so I wanted to raise an issue that I would love to start working to fix for 1.3.

Not to discourage you, but be aware the focus of most attention until 1.2 actually goes out is still 1.2. Feature freeze doesn't mean the release is done, it means attention shifts to bug fixing. You many not find many people ready to start thinking deeply about 1.3 just yet.

Karen

[Vitaly Babiy]

Thanks, for the pointer. I think even if this gets people think about the problem its a good start, I will raise this question again after 1.2 release.
Vitaly Babiy

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

[Justin Lilly]

To add another point, this doesn't mean that the day 1.2 hits release that everyone is gung-ho on 1.3. If past releases are any indication, there is usually a refactory period of a few weeks when everyone is basking in post-release bliss.

 -justin

On Mon, Feb 8, 2010 at 6:46 PM, Karen Tracey <kmtr...@gmail.com> wrote:

--

[Russell Keith-Magee]

On Tue, Feb 9, 2010 at 8:15 AM, Justin Lilly <jus...@justinlilly.com> wrote:
> To add another point, this doesn't mean that the day 1.2 hits release that
> everyone is gung-ho on 1.3. If past releases are any indication, there is
> usually a refactory period of a few weeks when everyone is basking in
> post-release bliss.

I believe the post-release period is typically referred to as "sobering up" :-)

To address Vitaly's original point - contrib.auth is on my list of
things I want to address in 1.3.

Yours,
Russ Magee %-)

[Harro]

- Make email unique and username non-required on the model. That would
make implementing something that authenticated by email a lot
easier :)

[Hanne Moa]

On 9 February 2010 09:09, Harro <hvdk...@gmail.com> wrote:
> - Make email unique and username non-required on the model. That would
> make implementing something that authenticated by email a lot
> easier :)

Pff, move emails out entirely. Email-addresses may change. Usernames
shouldn't change. One may have more than one email-address.

Maybe the time is right to make that branch now...

HM

[Dougal Matthews]

On 9 February 2010 08:09, Harro <hvdk...@gmail.com> wrote:

- Make email unique and username non-required on the model. That would
make implementing something that authenticated by email a lot
easier :)

For reference there are some good points here[1] on this topic started by Hanne Moa.

I think ideally the user model would be as simple as only having an ID as we shouldn't make assumptions about requirements for usernames, emails or even passwords with the vast array of login options we have these days. The backends can then extend this to create logins that are based on email, username, oauth, openid etc. Essentially giving us an ID to tie things together and relating different authentication methods for the same user.

Just some food for thought until 1.2 is out of the way and everybody is feeling a bit more sover.

http://groups.google.com/group/django-developers/browse_thread/thread/c522f1e2bf01c3f7 

[andybak]

I recently tried to use the recommended approach for custom user
profiles: http://docs.djangoproject.com/en/dev/topics/auth/#auth-profiles

and all the brick walls I hit were admin related. Whether these are
better fixed in contrib.auth or contrib.admin is hard to say:

1. I can show profile fields in the user changelist but I can't sort,
filter or search on them or use list_editable on them.
2. I can re-register my own ModelAdmin for users to customize the User
admin but I can't add custom filterspecs as that requires editing the
auth models.py

#1 could be mitigated if contrib.admin allowed more ways to following
relationships for things like list_display and list_filter.
#2 requires a more elegant way to write custom filterspecs without
touching models.py - maybe this is already possible?

Andy Baker

[James Bennett]

On Tue, Feb 9, 2010 at 2:09 AM, Harro <hvdk...@gmail.com> wrote:
> - Make email unique and username non-required on the model. That would
> make implementing something that authenticated by email a lot
> easier :)

1. It's *extremely* unlikely that changes will be considered which
require every Django install on the planet to undergo a DB schema
migration.

2. The appropriate time to discuss possible 1.3 features is when the
feature-discussion window for 1.3 comes up. That will happen sometime
in April, probably. Suggestions made now are likely to be forgotten by
the time that happens.

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

[Vitaly Babiy]

Vitaly Babiy

On Tue, Feb 9, 2010 at 3:16 AM, James Bennett <ubern...@gmail.com> wrote:

On Tue, Feb 9, 2010 at 2:09 AM, Harro <hvdk...@gmail.com> wrote:
> - Make email unique and username non-required on the model. That would
> make implementing something that authenticated by email a lot
> easier :)

1. It's *extremely* unlikely that changes will be considered which
require every Django install on the planet to undergo a DB schema
migration.

James this is true. Another reason it would be nice to have a migration framework for Django. 

2. The appropriate time to discuss possible 1.3 features is when the
feature-discussion window for 1.3 comes up. That will happen sometime
in April, probably. Suggestions made now are likely to be forgotten by
the time that happens.

Yeah I plan to bring this up again, around that time frame. 

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

[Harro]

Good suggestions, I think removing username and email from the user
might be a good idea.
Right now I authenticate with the email address stored on the profile
and the username is a random hash :)

As for breaking data and migrations; it shouldn't be that hard to
write a management command that does this.

On Feb 9, 5:54 pm, Vitaly Babiy <vbabi...@gmail.com> wrote:
> Vitaly Babiy
>

> On Tue, Feb 9, 2010 at 3:16 AM, James Bennett <ubernost...@gmail.com> wrote:

> > On Tue, Feb 9, 2010 at 2:09 AM, Harro <hvdkl...@gmail.com> wrote:
> > > - Make email unique and username non-required on the model. That would
> > > make implementing something that authenticated by email a lot
> > > easier :)
>
> > 1. It's *extremely* unlikely that changes will be considered which
> > require every Django install on the planet to undergo a DB schema
> > migration.
>
> James this is true. Another reason it would be nice to have a
> migration framework for Django.
>
>
>
>
>
> > 2. The appropriate time to discuss possible 1.3 features is when the
> > feature-discussion window for 1.3 comes up. That will happen sometime
> > in April, probably. Suggestions made now are likely to be forgotten by
> > the time that happens.
>
> > Yeah I plan to bring this up again, around that time frame.
>
> > --
> > "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-d...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > django-develop...@googlegroups.com<django-developers%2Bunsubscr i...@googlegroups.com>

[Sayane]

I think that an easy way to define your own user model is better idea. Auth app should be more generic. It should define a protocol for user, group and permission objects (and of course there should be back compatible implementation of this protocols used by default). There is a ticket about extending auth app: http://code.djangoproject.com/ticket/3011, but I think this could be done in a better way.

Sorry for my english :-)

2010/2/10 Harro <hvdk...@gmail.com>

To unsubscribe from this group, send email to django-develop...@googlegroups.com.

[Hanne Moa]

On 10 February 2010 23:33, Sayane <say...@gmail.com> wrote:
> I think that an easy way to define your own user model is better idea. Auth
> app should be more generic. It should define a protocol for user, group and

> permission objects /../

Why should permissions and groups be in the same app as the user? Less
reusable that way. Identity is different from authentication is
different from authorization.

Premature optimization or not, as it is today on many sites the
user-table is hit extremely frequently. I'm not sure it is wise to
have layer upon layer between the user in the db and the zillion
things that has a foreign key to it.

HM

[James Bennett]

Once again:

This is really not the time to be discussing this; anything in this
thread's going to be long forgotten by the time 1.2's out and 1.3
feature discussions are going on.

[Clay Gerrard]

How about fixing http://code.djangoproject.com/ticket/5786
"Relax character restrictions on auth usernames"

Jacob already said back in December '07:
"we just need to relax the current restrictions"

The ticket has a patch, and tests...

[Sayane]

It's not only about character restrictions on usernames. Some of developers want to use email as login (so we have to remove username and add unique option to email). Another example are english-only permissions. I would like to replace them with my own i18n permissions. Maybe someone needs something more complicated (for example authentication with external services, like twitter, facebook without creating a new, local user)?

2010/2/17 Clay Gerrard <clay.g...@gmail.com>

How about fixing http://codeStrona główna       Dodaj firmę        Moja firma       Pomoc       Blog       O nas       Konkurs      Kontakt.djangoproject.com/ticket/5786

[Russell Keith-Magee]

On Mon, Feb 22, 2010 at 6:03 PM, Sayane <say...@gmail.com> wrote:
> It's not only about character restrictions on usernames. Some of developers
> want to use email as login (so we have to remove username and add unique
> option to email). Another example are english-only permissions. I would like
> to replace them with my own i18n permissions. Maybe someone needs something
> more complicated (for example authentication with external services, like
> twitter, facebook without creating a new, local user)?

A couple of things to keep in mind:

1) We know about the limitations, and we want to fix them.

2) No, seriously, we know about the limitations, and we want to fix them.

3) I wasn't kidding on the first two points.

As has been said several times in this thread, the limitations with
contrib.auth Users are well known, and they are something we want to
address -- in the Django 1.3 timeframe. Now is *not* the time to be
discussing this.

Yours,
Russ Magee %-)