On 5/18/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I'm +1 on these changes, including using "!" as the "look somewhere
> else for the password" designator.
Would it really be "look somewhere else for the password" or would it
be more like "if you got this far (all other authentication
On 5/10/07, Simon Willison <[EMAIL PROTECTED]> wrote:
> I propose the following changes:
I'm +1 on these changes, including using "!" as the "look somewhere
else for the password" designator.
Jacob
--~--~-~--~~~---~--~~
You received this message because you are
Sorry, I misunderstood.
The last association is only deleted when the password is set.
Got it.
Regards,
Max
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send
> The problem with using a random password is that you can't answer the
> question "does this account have a password set?". I need to be able
> to answer that question because my OpenID implementation allows users
> to associate mupltiple OpenIDs with a single account. I want to let
> them
On May 11, 4:23 pm, Niels <[EMAIL PROTECTED]> wrote:
> > Or you could use the traditional
> > Unix password invalidator -- "!" -- which might be more mnemonic for
> > some people and is easier to pick out of a data dump than a space (and
> > will also never be a valid string, since we use '$' as
On Fri, 2007-05-11 at 08:23 -0700, Niels wrote:
> On May 11, 5:07 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > > So does that mean that I should store a single blank space in the
> > > password field to represent "no password set"?
> >
> > The purists will be breaking out the
On May 11, 5:07 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> > So does that mean that I should store a single blank space in the
> > password field to represent "no password set"?
>
> The purists will be breaking out the pitchforks and flaming torches
> ( :-) ), but that would be a
On Fri, 2007-05-11 at 14:51 +, Simon Willison wrote:
> On May 11, 3:40 pm, Martin Winkler <[EMAIL PROTECTED]> wrote:
> > > Certainly Oracle treats them empty string as equal to NULL. But does
> > > that mean you can't put an empty string in a "not NULL" column in
> > > Oracle?
> >
> >
On May 11, 3:40 pm, Martin Winkler <[EMAIL PROTECTED]> wrote:
> > Certainly Oracle treats them empty string as equal to NULL. But does
> > that mean you can't put an empty string in a "not NULL" column in
> > Oracle?
>
> Exactly. If you want to insert something meaningless into a column that
>
> Certainly Oracle treats them empty string as equal to NULL. But does
> that mean you can't put an empty string in a "not NULL" column in
> Oracle?
Exactly. If you want to insert something meaningless into a column that
has a NOT NULL constraint in oracle, then you have to put at least
one
Simon Willison wrote:
> The problem with using a random password is that you can't answer the
> question "does this account have a password set?". I need to be able
> to answer that question because my OpenID implementation allows users
> to associate mupltiple OpenIDs with a single account. I
On May 11, 7:50 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> > At the moment, django.contrib.auth does not support creating a user
> > account without setting a password.
>
> Why not generate a random one? It won't break an ability to authenticate
> using OpenID or any other backend for that
alized method to associate
IS> OpenID's with User's but it's not the question of this thread.
See the subject: "Changing django.contrib.auth to make passwords optional".
IS> "Ugliness" is a subjective thing and I personally don't see
IS> 'make_random_password' as particu
On May 11, 5:30 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> I'm working on a new component for my Django OpenID package which will
> provide support for associating one or more OpenIDs with a
> django.contrib.auth User. As part of this, I want to include the
> ability to register for a new
Mikhail Gusarov wrote:
> Because generation of random password is an ugly workaround. Your solution
> requires long comment which explains to the reader of code, why do random
> password is needed in first place.
A comment in my code is about username part, not password :-). I would
indeed be
On Fri, 2007-05-11 at 09:50 +0200, Michael van der Westhuizen wrote:
> Hi Simon,
>
> On 5/11/07, Simon Willison <[EMAIL PROTECTED]> wrote:
> >
> [snip]
> > 1. The 'password' field in the User model should be altered to have
> > blank=True.
> >
> > This would allow us to set blank passwords as an
Hi Simon,
On 5/11/07, Simon Willison <[EMAIL PROTECTED]> wrote:
>
[snip]
> 1. The 'password' field in the User model should be altered to have
> blank=True.
>
> This would allow us to set blank passwords as an empty string. It
> would not require existing installations to make any schema changes
Twas brillig at 10:50:57 11.05.2007 UTC+04 when Ivan Sagalaev did gyre and
gimble:
>> At the moment, django.contrib.auth does not support creating a user account
>> without setting a password.
IS> Why not generate a random one? It won't break an ability to authenticate
IS> using OpenID or
Simon Willison wrote:
> I'm working on a new component for my Django OpenID package which will
> provide support for associating one or more OpenIDs with a
> django.contrib.auth User. As part of this, I want to include the
> ability to register for a new user account using an OpenID instead of
>
I'm working on a new component for my Django OpenID package which will
provide support for associating one or more OpenIDs with a
django.contrib.auth User. As part of this, I want to include the
ability to register for a new user account using an OpenID instead of
a password.
At the moment,
20 matches
Mail list logo
