Closed Bug 624907 Opened 13 years ago Closed 13 years ago

services.stage.mozilla.com reset-password, delete-account are silently broken

Categories

(Cloud Services :: Server: Registration, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Atoll, Assigned: tarek)

References

Details

Attachments

(2 files)

services.stage.mozilla.com serves two applications, /reset-password and /delete-account.  neither is working at this time.  i can't find any evidence in any error_log and the access_log says that it's nothing but 200 OK for every request.  could anyone advise on what the next step in debugging the application should be?
just to be clear, this bug is only on stage, and not on prod right?
Only on stage.  Problem is in the new python code, or in the deployment thereof, as https://stage-auth.services.mozilla.com/user/1.0/mconnor/password_reset returns 401.  Making a password reset call require auth _feels_ like a bug.
Assignee: nobody → tarek
Component: Web Site → Server: Registration
QA Contact: website → reg-server
delete account also fails, and should probably require auth of some sort.  i suspect there's logs in staging reg/sreg to explain what's going on, will followup with said soon
one complete end-to-end attempt to delete-account from the perspective of the ldap slave.  filled out s.stage.m.c form and clicked delete.

Jan 11 20:18:07 weave-stage-slave01 slapd2.4[19872]: conn=3761 op=2 DEL dn="uid=7w56ekcd7npprpavz6ox5g4sdk666cny,dc=3fddd,dc=fddd,dc=ddd,dc=dd,dc=d,dc=mozilla" 
Jan 11 20:18:07 weave-stage-slave01 slapd2.4[19872]: conn=3761 op=2 RESULT tag=107 err=10 text= 

i suspect but have not yet confirmed that "tag=107 err=10" is either permission denied or some variant thereof.
there was also a DEL attempt for the user on the master.  The BIND statement specifies an empty dn="", leading to the DEL's refusal: "modifications require authentication".

the precise time order of this log vs. the slave log is not apparent due to the 1s precision.
Depends on: 625001
Two things here:

- the password_reset API needs an authentication. (filled in bug 625001)

  I found the problem: the Python app provides its own password reset form 
  that uses the password_reset API internally. Calling it from the PHP form 
  results in a 401. The fix consists in making this API public. 

  This is functional-tested in the Python server but with that assumption:
  http://hg.mozilla.org/services/server-reg/file/4cf119665f16/syncreg/tests/functional/test_user.py#l112

  It's not covered in the old functional tests we have and run over dev, 
  so I'll add one test there. with the right assumption, with the fix.

- the delete_user API is tested for this through the old functional tests 
  suite (which are not run yet on stage due to an infra bug 623712) 
  and also through the Python equivalent of the form.

  In order to find the issue for delete_account, I need to be able to reproduce
  it in dev, but I don't think the PHP versions of delete-account is deployed
  there, so that's something we need to do: have an instance of
  those forms pointing to the dev cluster (added bug 625005)

  Once we have this I'll also add a functional test that uses the PHP forms.
No longer depends on: 625001
Depends on: 625001
Depends on: 626974
It seems like the above changes were completed recently, as both delete_user and password_reset work in staging with python reg/sreg now.  Perhaps this can be closed?
Since QA passed all those tests, we can close this
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: