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 met
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 s
# Blog post here: http://www.buriy.com/2007/may/12/django-openid-users/
# Download here: http://www.buriy.com/media/openid-solution.zip
For anyone interested, the OpenID 2 release of our python OpenID
library[1] will include a Django app with an example consumer and
server, in addition to the exa
Blog post here: http://www.buriy.com/2007/may/12/django-openid-users/
Download here: http://www.buriy.com/media/openid-solution.zip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
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 ema
> 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 delete
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 a
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 pitchfo
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 backwar
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?
> >
> > Exactly.
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
> has
> 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 space
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 wan
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 mat
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_ra
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 use
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 gl
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
> a
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, djang
22 matches
Mail list logo
