thanks everybody, I think I´m fine from here on ...
patrick
Am 19.07.2006 um 10:04 schrieb Marc Remolt:
>
> Have a look at the 'make_random_password' method in
> 'django/contrib/auth/model.py' - it's the same principle there. In
> case
> you already have a extended user profile, I would
Have a look at the 'make_random_password' method in
'django/contrib/auth/model.py' - it's the same principle there. In case
you already have a extended user profile, I would store the activation
string there. Otherwise I'd make a dedicated model to store them with a
link to the user, the
On 19-Jul-06, at 1:11 PM, patrickk wrote:
> sorry for being stressful - but could you give an example:
> how to generate that string?
> where do you store it and how handle the expiration?
a very crude example:
http://nrcfosshelpline.in/code/browser/trunk/web/views.py
look at the 'register'
sorry for being stressful - but could you give an example:
how to generate that string?
where do you store it and how handle the expiration?
thanks,
patrick
Am 19.07.2006 um 09:40 schrieb Kenneth Gonsalves:
>
>
> On 19-Jul-06, at 12:57 PM, patrickk wrote:
>
>>
>> that makes sense to me.
>>
>>
On 19-Jul-06, at 12:57 PM, patrickk wrote:
>
> that makes sense to me.
>
> still, I have 2 more questions:
> 1. what kind of query do you use for email confirmation (how do you
> generate it)? anything special to consider here? I did use a
> combination of a password-hash with the date_joined
I did some research in the meantime and I do see the security issues.
I just underestimated the effort of doing a registration.
I already thought about your suggestion. considering the previous
arguments I decided not to store the raw password.
thanks,
patrick
Am 19.07.2006 um 09:19 schrieb
that makes sense to me.
still, I have 2 more questions:
1. what kind of query do you use for email confirmation (how do you
generate it)? anything special to consider here? I did use a
combination of a password-hash with the date_joined so far, but I´m
not sure that´s the right way to go.
Hmmm,
if you really want to send the password as you described it and have
considered the arguments of my previous posters, why don't you make a
pre-save method for your user model, which stores the clear text password
in a simple extra model (just one-to-one with clear text pass and link
to
I do something similar to Kenneth.the other approach is to use something like OpenID, and make it somebody else's problem.On 19/07/2006, at 3:16 PM, Kenneth Gonsalves wrote:On 18-Jul-06, at 9:20 PM, va:patrick.kranzlmueller wrote: next problem with my user registration process:how do I send the
On 18-Jul-06, at 9:20 PM, va:patrick.kranzlmueller wrote:
>
> next problem with my user registration process:
> how do I send the password to registered users after they confirmed
> their registration?
>
> the process should look like this:
> 1. registration
> 2. email confirmation
> 3. account
thanks james, jay ...
I do see your arguments. it´s just a litte bit frustrating ...
building the website using django was damn fast. now i´m stuck with
the registration process ... it already took me twice as long as
building the actual website. it´d be cool to have some kind of "best
Most systems do, if they don't send the password, they send a time
sensitive link (randomly generated and hard to guess) that will take the
user to a password change form where s/he gets to enter a new one.
James Bennett wrote:
> (but please note that's just me personally; the
On 7/18/06, James Bennett <[EMAIL PROTECTED]> wrote:
> My personal preference is never to send the password over the wire
> when there's not an extremely compelling reason to. So, if it were me,
> I wouldn't send the password.
(but please note that's just me personally; the PasswordResetForm
On 7/18/06, patrickk <[EMAIL PROTECTED]> wrote:
> 1. so what do you do when a user forgot his password? you obviously
> can´t email it, so you have to set a new one. that seems a little
> complicated (for the user).
Check out the PasswordResetForm, a manipulator defined in
It's considered bad practice to keep a user's password anywhere on your
server in plain view. Many users use the same password across multiple
systems, and if your server was ever compromised, the attacker would
then have emails, usernames and passwords for a lot of different people
thanks james ... your answer leads to more questions:
1. so what do you do when a user forgot his password? you obviously
can´t email it, so you have to set a new one. that seems a little
complicated (for the user).
2. the user should set his own password, I agree. but that doesn´t
mean,
On 7/18/06, va:patrick.kranzlmueller <[EMAIL PROTECTED]> wrote:
> since the password is stored encrypted, I´m not sure how to send it.
There isn't any way to get at the 'raw' password once it's been
encrypted; you'll need to work around this by emailing the password
before it's encrypted, or by
next problem with my user registration process:
how do I send the password to registered users after they confirmed
their registration?
the process should look like this:
1. registration
2. email confirmation
3. account activation & email with username and password
4. now the user can log in
18 matches
Mail list logo
