I think that's a bit different from the originally reported issue, but it
seems like a reasonable thing to fix if we can.
On Monday, January 26, 2015 at 5:43:54 PM UTC-5, Florian Apolloner wrote:
>
> I can reproduce the issue:
>
> Log a user into the admin
> Change iteration count
> Use a new bro
I can reproduce the issue:
Log a user into the admin
Change iteration count
Use a new browser (or private window) and log the same user into the admin
Refresh the admin page of the first user -> login window
Cheers,
Florian
On Thursday, January 15, 2015 at 2:31:55 AM UTC+1, Tim Graham wrote:
>
>
On Thursday, January 15, 2015 at 6:03:40 AM UTC-3, Nic West wrote:
>
> Authenticated returns a user instance assumably with the correct hash why
> not do some thing like:
>
> authenticated_user.count = 0
> authenticated_user.save()
Yes, I implemented that fix last night, but I really like the
Authenticated returns a user instance assumably with the correct hash why not
do some thing like:
authenticated_user.count = 0
authenticated_user.save()
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To
On Thu, Jan 15, 2015 at 12:05 AM, Horacio G. de Oro
wrote:
> If you see the new hash in the database, I think that, maybe the admin, is
> saving the user instance with the new hash. And doing that, ie: save()'ing
> the user returned by authenticate() solved the issue for me too (but I
> don't wan
I think therefore you could resolve the issue by doing
save(update_fields=['count']) in your code.
On 15 January 2015 at 06:31, Horacio G. de Oro wrote:
> Yeap. Removing the save() done in solved the issue.
>
> And some component is doing and update() - not a save(). I see in the
> Postgresql l
Yeap. Removing the save() done in solved the issue.
And some component is doing and update() - not a save(). I see in the
Postgresql logs an UPDATE of the hash with the new increment, that includes
only the "password" field.
I thought that autenticate() produced a read operation on the DB... n
I do something like.
# get the user to check tries
user = User.object.get(username=username)
assert user.count <= 3
# authenticate
authenticated_user = authenticate(...)
# auth failed
if not authenticated_user:
user.count++
user.save()
raise
As part of the authentication process, I increment/reset authentication
tries of the user. And to check this, I get the user from the DB before
doing the authentication. I think this is causing me the issue. I reset the
countre of login attempts in an instance of user that is different than the
I haven't tested the issue outside my project. But while debugging, I saw
the new hash in the user instance returned by authenticate(), but that new
hash never went to the database since I haven't done a 'save()' of the user
instance.
If you see the new hash in the database, I think that, maybe
Hi Horacio,
Thanks for the report. Unfortunately, I can't reproduce this issue.
My steps to reproduce using the project from the tutorial:
Bump PBKDF2PasswordHasher.iterations to a higher value
Login at /admin/
Confirm at /admin/auth/user/#/ that the password of the user I logged in as
reflects
The problem is because the iterations in PBKDF2PasswordHasher where updated
to 15000, so it updates the password, but later,
SessionAuthenticationMiddleware detects a password change and PUF! the
login doesn't work.
Right new I've created a PBKDF2PasswordHasher implementation with
iteartions =
12 matches
Mail list logo
