Odoo Addons (MOVED TO GITHUB)

auth_signup: Password reset by email stopped working

Bug #1162914 reported by ThinkOpen Solutions on 2013-04-01

This bug affects 13 people

Affects		Status	Importance	Assigned to	Milestone
	Odoo Addons (MOVED TO GITHUB)	Confirmed	Low	OpenERP R&D Addons Team 1

Bug Description

Steps to reproduce:

1. Go to user profile
2. Click on button to reset password
3. Go to email and click on link to reset password

Expected: Form with fields to insert new password

Observed: normal login form, with pre-filled and read-only username

Possible fix:

I've looked at the code, and it seems it's re-setting the form type as "default" even if it's a reset request. I've commented that line and it seems to work fine now.

Diff:

=== modified file 'auth_signup/static/src/js/auth_signup.js'
--- auth_signup/static/src/js/auth_signup.js 2013-02-28 16:44:17 +0000
+++ auth_signup/static/src/js/auth_signup.js 2013-04-01 17:33:15 +0000
@@ -57,7 +57,7 @@
                     self.rpc("/auth_signup/get_config", {dbname: dbname}).done(function(result) {
                         self.signup_enabled = result.signup;
                         self.reset_password_enabled = result.reset_password;
- self.set('login_mode', 'default');
+ // self.set('login_mode', 'default');
                     });
                 } else {
                     // TODO: support multiple database mode

Tags:

Related branches

lp://staging/~openerp-dev/openobject-addons/trunk-bug-1162914-mahendra

Ready for review for merging into lp://staging/openobject-addons

OpenERP Core Team: Pending requested 2013-04-05

Revision history for this message

Twinkle Christian(OpenERP) (tch-openerp) wrote on 2013-04-04:

reset_password1.png Edit (61.7 KiB, image/png)

Hello Thinkopen Solutions,

I have checked your issue with latest trunk as well with 7.0. As I have shown you in my above image, the 'Name' & 'User name' field is in read only mode. But Its our feature.So, we cannot consider it as a bug.

And As per the usability discussion I just confirm it for the 'Password' field to replace it with the name of 'New Password', which I mentioned it in my above image.

I hope you understand.

Thank you.

Changed in openobject-addons:
assignee:	nobody → OpenERP R&D Addons Team 1 (openerp-dev-addons1)
importance:	Undecided → Low
status:	New → Confirmed
tags:	added: usability

Revision history for this message

Mahendra Barad(OpenERP) (mba-openerp) wrote on 2013-04-05:

Hello,

It has been fixed into https://code.launchpad.net/~openerp-dev/openobject-addons/trunk-bug-1162914-mahendra
branch with following

Revision ID: <email address hidden>
Revision No:8662

Thanks.

Changed in openobject-addons:
status:	Confirmed → In Progress
status:	In Progress → Fix Committed

Revision history for this message

electro (electro1) wrote on 2013-06-23:

sorry but it seems that ThinkOpen is talking about automatic redirection to standard login form when a user is coming from a reset link. If it's so this happens me too

electro (electro1) on 2013-07-04

Changed in openobject-addons:
status:	Fix Committed → Confirmed

Revision history for this message

electro (electro1) wrote on 2013-07-05:

II've done all of my best to investigate this issue.

I remark that we are talking about the case

1. Go to user profile
2. Create a new user or Click on button to reset password
3. Go to email and click on link to reset password

OpenErp will show the reset login form for a bit and immediately the page is redirected to the standard login form with username in readonly

This is not deterministic.

I found that WHEN the procedure is CORRECT I've in the log:
2013-07-05 07:36:59,476 46265 INFO MYDB werkzeug: 127.0.0.1 "POST /auth_signup/get_config HTTP/1.1" 200 -
2013-07-05 07:36:59,975 46265 INFO MYDB werkzeug: 127.0.0.1 "POST /auth_signup/retrieve HTTP/1.1" 200 -

while WHEN is WRONG I've get_config and retrieve calls in reverse order
2013-07-05 09:47:43,361 12032 INFO MYDB werkzeug: 127.0.0.1 "POST /auth_signup/retrieve HTTP/1.1" 200 -
2013-07-05 09:47:44,176 12032 INFO MYDB werkzeug: 127.0.0.1 "POST /auth_signup/get_config HTTP/1.1" 200 -

I've understood that this function are called by 2 different thread, each of them produce a login form. So final login form is that one is produced by latest thread

Threading related issues are really hard to investigate and I'm unable to go on. Anyway I've found a workaround waiting for a real solution.

My Workaround introduce a sleep(0.5) in /auth_signup/retrieve so it will finish as latest and reset will work as expected

I KNOW THIS IS A VERY BAD SOLUTION but I hope that someone who knows openerp source better than me will find a real solution to this issue

Revision history for this message

Bob Wan (bobmail) wrote on 2013-07-28:

I have same question.

Revision history for this message

David BEAL (ak) (davidbeal) wrote on 2013-07-31:

A way to bypass this bug is to copy/past url in another browser (browser with no usual connection with openerp).

It's very annoying for end users.

Revision history for this message

Scribder (scribder) wrote on 2013-07-31:

Hi Dear,

Actually, i have the same issue, when the url of reset password is visited, it will show all fields with Password and Password Confirmation, just in a fraction of seconds, they will disapear, then the login page will be for login, not for password definition.

Im investigating on this, but can't have an idea how to fix it.

Revision history for this message

Andreas Brueckl (andreas-brueckl) wrote on 2013-08-20:

The same problem here.

This bugfix is required whenever a new user is added.
So I cannot follow that the importance is only "Low"!

Revision history for this message

Isaac Richter (laughingjudge) wrote on 2013-09-04:

auth_signup diff against 7.0-20130903-231112-1 Edit (2.1 KiB, text/plain)

It looks like there is a race condition between the rpc calls to /auth_signup/retrieve (verify the auth token) and /auth_signup/get_config (determine whether password reset buttons and signup buttons are permitted). Whichever one finishes second gets to set up the form, so if the auth token verification is faster than the signup checks, the browser will briefly display the reset form before switching to the normal login form.

I've attached a patch against the 7.0-20130903-231112-1 nightly deb that doesn't bother calling get_config if it's already called to verify the auth token.

Revision history for this message

PkLab.net (pklab) wrote on 2013-09-11:

#10

Hi Isaac,

I'm was having same problem but after I've applied your patch, it seems that all is working fine now.

I will post here in case I will discover some additional issues

thank you

cheers

Revision history for this message

Scribder (scribder) wrote on 2013-10-07:

#11

Hi dear Isaac,

Your patch is working for me too.

Thanks a lot.

Revision history for this message

Andreas Brueckl (andreas-brueckl) wrote on 2013-10-07:

#12

Hey,

It also works for me.

Thank you!

Revision history for this message

Marc F Gamma (mnrc) wrote on 2013-12-02:

#13

yes I was affected too, surpirsed that it is low rating

but your fix works

the only limitation is that after a reset request the user has to leave the browser completely (at least on chrome) and reopen it for the right login with password to display

thanks you Isaac