I'm not a dev that contribute too many directly to Django Project, but
aniway I use Django since 0.96, so here is my 2 cents.
While Clay's idea have many cool changes and is a really nice idea that
should be evaluated I share more Tom's and Daniel's point.
Any Django Developer on World that chan
On Fri, Mar 16, 2012 at 10:05 AM, Carl Meyer wrote:
[...]
> I am not sure whether this should happen as a separate step or not. In
> an ideal world, we would have a longer username field. In the real
> world, we have to balance the benefit against the cost, and requiring a
> schema migration from
On Thu, Mar 15, 2012 at 4:49 PM, Carl Meyer wrote:
> Hi Daniel,
>
> On 03/15/2012 09:24 AM, Daniel Sokolowski wrote:
>> Why can we not just increase the length limit on the username field?,
>> Why can't we just throw a validation error if data entered is to long
>> and the schema has not been upda
Hi Daniel,
On 03/15/2012 11:48 AM, Daniel Sokolowski wrote:
> The issue here is that django auth is limited, and restrictive and needs
> hacks to make it use emails as usernames, we can agree on that yes?
Certainly.
> We
> can also agree that contrib.auth2 with LFK is a complex undertaking far
On Thu, Mar 15, 2012 at 2:48 PM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:
> The issue here is that django auth is limited, and restrictive and needs
> hacks to make it use emails as usernames, we can agree on that yes?
I agree with this point.
> We can also agree that contr
On Thu, Mar 15, 2012 at 5:53 AM, Danny Adair
wrote:
Hi Danny,
> I'm sorry I don't know if I like that. I hope I understand correctly
> what you're doing, and that my criticism is seen as constructive.
>
Thanks for reviewing the code and providing feedback.
> This sells itself as "pluggable
limitation on the username
ought to be increased?
-Original Message-
From: Luke Sneeringer
Sent: Thursday, March 15, 2012 2:11 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email
On March 15, 2012, at 12:23 , Daniel Sokolowski wrote:
Carl, I sincerely appreciate
pread than past Django releases.
Regards,
Luke
> -Original Message- From: Carl Meyer
> Sent: Thursday, March 15, 2012 12:49 PM
> To: django-developers@googlegroups.com
> Subject: Re: authentication by email
>
> --
> You received this message because you are subscr
, March 15, 2012 12:49 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email
--
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 unsu
On 03/15/2012 09:41 AM, Daniel Sokolowski wrote:
> Yes it clearly would, however I see two possible solutions to make it
> more friendly:
>
> 1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it -
> I mean the actual commands to execute.
> 2. Catch the DB error and throw a form va
Hi Daniel,
On 03/15/2012 09:24 AM, Daniel Sokolowski wrote:
> Why can we not just increase the length limit on the username field?,
> Why can't we just throw a validation error if data entered is to long
> and the schema has not been updated? I think the answer yes we can and
> easily.
I don't me
That would be a workable compromise, yes?
-Original Message-
From: Daniel Sokolowski
Sent: Thursday, March 15, 2012 12:41 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email
Yes it clearly would, however I see two possible solutions to make it more
friendly
ginal Message-
From: Luke Sneeringer
Sent: Thursday, March 15, 2012 12:28 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email
On March 15, 2012, at 11:24 , Daniel Sokolowski wrote:
Tom makes a good point, but you can already store emails in the username,
they are
7;s certainly
a bigger backwards incompatible change than the Django development community
has traditionally been comfortable with.
Regards,
Luke
>
> -Original Message- From: Tom Evans
> Sent: Friday, March 09, 2012 11:46 AM
> To: django-developers@googlegroups.com
> Subject
oups.com
Subject: Re: authentication by email
On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant wrote:
On 09/03/12 14:49, Tom Evans wrote:
Yes, since no one needs it. Okay no one isn't true, but no one (for true
this time) who needed it stepped up and said "I'll implement it and see
that
it e
On Thu, Mar 15, 2012 at 22:53, Danny Adair wrote:
>[...]
> I'd like to see a later, "proper" auth.user that can undo that chaos.
I originally thought you intended a setting which let's the user
switch from the existing auth to an email auth with corresponding User
model.
As lame as that may be -
On Mon, Mar 12, 2012 at 16:57, Clay McClure wrote:
>[...]
> New django projects can elect to use an entirely different pluggable auth
>[...]
> The pluggable-auth-apps fork is barely two days old, so it's still rough
> around the edges, and I've almost certainly missed some things. I haven't
>[...]
On Sun, Mar 11, 2012 at 4:39 AM, Clay McClure wrote:
What you are really saying is this: being pragmatic means that we
>> prioritise *your* immediate need above the need to keep the code and the
>> docs maintainable, and above the need to maintain compatibility with
>> existing installations.
>
>
On Sun, Mar 11, 2012 at 12:09 PM, Jacob Kaplan-Moss wrote:
> I've written such a pluggable User app. By default, the User model works
> as before. But I've also provided a User model (and forms, admin, backends,
> etc) implementation that removes the limitations of the User model noted
> above and
On 12/03/2012, at 6:58 AM, Joe & Anne Tennies wrote:
> I started a new page off the old
> https://code.djangoproject.com/wiki/SchemaEvolution
> (https://code.djangoproject.com/wiki/SchemaEvolutionDesign). It's not
> complete at this point, I just did a brain dump of what I remembered hearing
On 12/03/2012, at 7:08 AM, Joe & Anne Tennies wrote:
> Can I ask for one change this late in the project to the 1.4 release if it's
> only the documentation for this bug? I'm hoping someone at PyCon might be
> able to "sneak this in."
>
> Can we add a note to the EmailField documentation that
Can I ask for one change this late in the project to the 1.4 release if
it's only the documentation for this bug? I'm hoping someone at PyCon might
be able to "sneak this in."
Can we add a note to the EmailField documentation that states that "The
default 75 character max_length is not capable of
I started a new page off the old
https://code.djangoproject.com/wiki/SchemaEvolution (
https://code.djangoproject.com/wiki/SchemaEvolutionDesign). It's not
complete at this point, I just did a brain dump of what I remembered
hearing in the past. Sounds like I'm not TOO far off with my memory.
Also
On Sunday, March 11, 2012 at 12:39 AM, Clay McClure wrote:
> I've written such a pluggable User app. By default, the User model works as
> before. But I've also provided a User model (and forms, admin, backends, etc)
> implementation that removes the limitations of the User model noted above and
On Fri, Mar 9, 2012 at 10:36 AM, Luke Plant wrote:
What you are really saying is this: being pragmatic means that we
> prioritise *your* immediate need above the need to keep the code and the
> docs maintainable, and above the need to maintain compatibility with
> existing installations.
>
Of co
On 10/03/2012, at 1:52 AM, Joe & Anne Tennies wrote:
> While, I generally agree with the current approach, especially this close to
> release. I'm going to play devil's advocate for a bit.
>
> Schema migrations have been talked about for quite a while. There are at
> least 3 external implement
2012/3/10 Łukasz Rekucki
> On 9 March 2012 21:10, Tom Evans wrote:
> > 2012/3/9 Łukasz Rekucki :
> >> On 9 March 2012 17:46, Tom Evans wrote:
>
[...]
> My point is that this kind of things change and we should have tools
> to deal with that. We already have the exact same problem with IPv6
>
On 9 March 2012 21:10, Tom Evans wrote:
> 2012/3/9 Łukasz Rekucki :
>> On 9 March 2012 17:46, Tom Evans wrote:
>>>
>>> Lets look at one isolated aspect. The User email field in d.c.auth is
>>> too short. Emails can be up to 248 characters long, and d.c.auth only
>>> allows 75.
>>
>> The latest RF
2012/3/9 Łukasz Rekucki :
> On 9 March 2012 17:46, Tom Evans wrote:
>>
>> Lets look at one isolated aspect. The User email field in d.c.auth is
>> too short. Emails can be up to 248 characters long, and d.c.auth only
>> allows 75.
>
> The latest RFC[1] actually specifies this as 256 *octets* with
On 9 March 2012 17:46, Tom Evans wrote:
>
> Lets look at one isolated aspect. The User email field in d.c.auth is
> too short. Emails can be up to 248 characters long, and d.c.auth only
> allows 75.
The latest RFC[1] actually specifies this as 256 *octets* with max of
64 octets for the local part
While, I generally agree with the current approach, especially this close
to release. I'm going to play devil's advocate for a bit.
Schema migrations have been talked about for quite a while. There are at
least 3 external implementations I know of: South, nashvegas, and
django-evolution. I'm unsur
On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant wrote:
> On 09/03/12 14:49, Tom Evans wrote:
>
>>> Yes, since no one needs it. Okay no one isn't true, but no one (for true
>>> this time) who needed it stepped up and said "I'll implement it and see that
>>> it ends up in trunk"
>>>
>>
>> I'm sorry, that
On 09/03/12 14:49, Tom Evans wrote:
>> Yes, since no one needs it. Okay no one isn't true, but no one (for true
>> this time) who needed it stepped up and said "I'll implement it and see that
>> it ends up in trunk"
>>
>
> I'm sorry, that completely mis-characterises the situation. Lots of
> peop
On Fri, Mar 9, 2012 at 3:36 PM, Luke Plant wrote:
> What you are really saying is this: being pragmatic means that we
> prioritise *your* immediate need above the need to keep the code and the
> docs maintainable, and above the need to maintain compatibility with
> existing installations.
>
> Ther
On 09/03/12 09:37, Clay McClure wrote:
> Who's talking about a migration? I'm asking for something that will work
> for *new* installations; existing installations can continue
> authenticating against usernames for all I care :)
>
> Moreover, I'm thoroughly frustrated by the fact that developer
On Fri, Mar 9, 2012 at 8:13 AM, Florian Apolloner wrote:
>> Should these things really take five years? What happened to pragmatic?
>
>
> Yes, since no one needs it. Okay no one isn't true, but no one (for true
> this time) who needed it stepped up and said "I'll implement it and see that
> it end
On Fri, Mar 9, 2012 at 3:23 AM, Danny Adair wrote:
> It's the "required" of username that's the problem if you don't want a
> username at all when authenticating against email.
> It would have to be not required and check required fields in clean()
> where the backend could be asked what's really
My django-email-login app (
https://bitbucket.org/tino/django-email-login/overview) does this by
putting a hash of the email adress in the username field. It isn't as nice
as it could be, but it works.
I would really like to see this solved another way, but it is a hard
problem with the current re
On Fri, Mar 9, 2012 at 21:13, Florian Apolloner wrote:
>[...]
> Yes, since no one needs it. Okay no one isn't true, but no one (for true
> this time) who needed it stepped up and said "I'll implement it and see that
> it ends up in trunk"
It's the "required" of username that's the problem if you
Hi,
On Friday, March 9, 2012 6:54:16 AM UTC+1, Clay McClure wrote:
>
> if settings.AUTH_EMAIL_AUTHENTICATION:
>
Hell, not another ugly setting like this.
Should these things really take five years? What happened to pragmatic?
>
Yes, since no one needs it. Okay no one isn't true, but no one (for
On Fri, Mar 9, 2012 at 20:01, Donald Stufft wrote:
> The major issue is that there is no way to do schema migrations in core
> (currently). So there's no way to handle increasing the length of the
> username field.
I don't understand what the "username" field length has to do with it.
And I thin
Sorry all, disregard my previous email, I misread one thing and
completely missed Wim's original message.
On Thu, Mar 8, 2012 at 11:07 PM, Matt Pegler wrote:
> For the project I am working on, we solved this by making a custom
> auth backend that checks the username against the email column. We'
For the project I am working on, we solved this by making a custom
auth backend that checks the username against the email column. We've
found it to be a nice clean solution to wanting to use email addresses
instead of usernames.
On Thu, Mar 8, 2012 at 9:54 PM, Clay McClure wrote:
> "Django is a
The major issue is that there is no way to do schema migrations in core
(currently). So there's no way to handle increasing the length of the username
field.
More comprehensive solutions require more thought to figure out the pluggable
User models.
On Friday, March 9, 2012 at 12:54 AM, Cl
"Django is a high-level Python Web framework that encourages rapid
development and clean, pragmatic design"—unless you want to do something
seemingly simple like using email addresses for authentication, in which
case you need to monkey patch models and forms to get everything working
right, wh
For the record and as an answer to the previous question, I'd like to
quote Russell who wrote the following in reponse to a ticket of mine:
" The core-endorsed ticket for this problem is #3011. The patch on
that
ticket isn't endorsed, but it points at the real problem - a need to
be
able to spec
Hello,
In the past hour, I did some research on authenticating by email and I
believe Django users would benefit a lot if email authentication was
included in contrib.auth .
Many people have been working on it, and the latest code I could find
is here: https://gist.github.com/586056. I am not a v
47 matches
Mail list logo
