Closed Bug 435909 Opened 16 years ago Closed 16 years ago

services.mozilla.com (weave) accounts seemingly disappear

Categories

(mozilla.org Graveyard :: Server Operations, task)

All
Other
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: myk, Assigned: aravind)

References

Details

Last week I created a Weave account on services.mozilla.com and used it for several days (including Friday).  Yesterday, when I tried to access the account again, I was unable to log in.  Today I tried to create a new account with the same email address and was successful, so apparently my existing account disappeared some time over the weekend.

That seems problematical and possibly indicative of a server bug, since although I'm hacking on Weave, I don't think I did anything that would cause the client to delete the account (in fact, I don't think the client even has that capability).

The account's email address is test@melez.com.  Perhaps the Apache logs or other logs might yield a clue about what happened to the account?
You registered at services.mozilla.com both times?  Not the staging site once and the production site once?
Assignee: server-ops → oremj
Yes, that's right, I registered at services.mozilla.com both times.  And it looks like I'm not the only one whose account disappeared:

https://labs.mozilla.com/forum/index.php/topic,777.0.html
Assignee: oremj → aravind
The account test@melez.com is present in LDAP, so the problem is probably with something else.  This is what I see in the logs.

[Tue May 27 00:51:30 2008] [warn] [client 10.2.80.4] [7427] auth_ldap authenticate: user markus.olausson@gmail.com authentication failed; URI /user/59324f6db3a10d558d880526fd9785945d75e589/ [User not found][No such object]
[Tue May 27 00:51:30 2008] [error] [client 10.2.80.4] access to /user/59324f6db3a10d558d880526fd9785945d75e589/ failed, reason: verification of user id 'markus.olausson@gmail.com' not configured
[Tue May 27 00:51:40 2008] [warn] [client 10.2.80.4] [7429] auth_ldap authenticate: user test@melez.com authentication failed; URI /user/185c00dfd3f485db84c5c15bdde0c7c38fa1264a/ [User not found][No such object]
[Tue May 27 00:51:40 2008] [error] [client 10.2.80.4] access to /user/185c00dfd3f485db84c5c15bdde0c7c38fa1264a/ failed, reason: verification of user id 'test@melez.com' not configured
Note that I recreated my account after it disappeared, so it should show up in LDAP now even if it wasn't there after it disappeared.
Jeremy:  I can't think of why LDAP would be dropping users randomly.  My guess is that the app is causing this.  What/where do I look in the app for this stuff?
The registration code is at pm-proxy01:/var/www/html/services.mozilla.com-userreg but the only time it does anything is at registration, so I can think of any reason it would be deleting accounts.

[root@pm-proxy01 services.mozilla.com-userreg]# grep -r 'mod_del' .
[root@pm-proxy01 services.mozilla.com-userreg]# grep -r 'ldap_delete' .

Other parts that access the app are:

* Apache auth
* redirector script, but that only has a search
* create user directory script, but also only does a search
myk:  Are there any users that are currently experiencing the problem now?  I'd like to try and see whats wrong with their account if anything..
Here's a forum post from someone who experienced the problem two days ago and hasn't mentioned resolving it yet:

https://labs.mozilla.com/forum/index.php/topic,799.0.html
This user seems to have recreated his account as well.  I reset the password and it seems to be working now.

Oremj:  The verify.php functions seems to be checking verifyKey($_GET['key'].  But that seems to be running the search ldap_search($this->ldap_conn, "dc=mozilla", "(mail-verified=$key)", array('uid')).  From looking at some entries mail-verified is always a yes or a no, so I am not sure how it would ever return yes for any account.

Its working for folks, so I must be missing something.  It feels like some path the user the taking is messing up and setting mail-verified or some such attribute to false (denying them access).  When they re-create their account, and re-verify e-mail, it must be setting those attributes to yes again, but scrambling their password.

All that stuff above is just a guess, since I didn't actually trace through all the code.
(In reply to comment #9)
> This user seems to have recreated his account as well.  I reset the password
> and it seems to be working now.
> 
> Oremj:  The verify.php functions seems to be checking verifyKey($_GET['key']. 
> But that seems to be running the search ldap_search($this->ldap_conn,
> "dc=mozilla", "(mail-verified=$key)", array('uid')).  From looking at some
> entries mail-verified is always a yes or a no, so I am not sure how it would
> ever return yes for any account.

When the account is created mail-verified is set to a random sha1 key.  When the user verifies their account it runs that query finds the user and sets mail-verified to yes.
Marking this wontfix for now.  Please re-open when this becomes a priority.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
A few people have been emailing me lately about broken accounts.  I pointed them to this bug, but it's marked private.

Looking over the bug, I see some account emails and some short php/ldap snippets.  Do we want to keep those confidential?  If yes, where do I point folks to? (if not, please make it public! :)
Reopening, I have gotten multiple mails about this problem lately.

The only thing I see in the logs users send me is that suddenly they start getting 401 responses from the server.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Please post the emails of the accounts that have disappeared.  And, request folks not to re-create their accounts.
Right, that's why I want the bug public, so I don't have to get people to mail me and put their addresses here :)

I can file a new bug if you prefer.
Group: infra
Should now be open to everyone.
Blocks: 433979
Summary: services.mozilla.com account disappeared over the weekend → services.mozilla.com (weave) accounts seemingly disappear
please note that if there is any configuration changes or code changes we're going to need to sync up with the branch we're running on sm-labs01 (we need to do that anyway, but just thought i'd mention here so everyone is on the same page)
Please help. My registered account which is the same for bugzilla has disappeared too.
(In reply to comment #18)
> Please help. My registered account which is the same for bugzilla has
> disappeared too.
> 

I was looking at LDAP and it appears that you re-created the account on the 16'th?

Can I get a username where the account has not been re-created?
I'm having an issue where the link I received in the confirmation email doesn't work. When I attempt to resend the confirmation email, I never receive it.

I signed up with the email address: triconium@gmail.com

Thanks.
I was able to use a few days ago - but once only.  It let me login to the website once, but the plugin does not.  Also, I'm not longer able to login to the website.  

I upgraded to FF3-final to see if that would clear things up - but it did not.  (Previously, it was rc3)

Please let me know what additional information you'd like.  My weave email-id is the same as my bugzilla email.

Best regards,
 -dj

I am now able to login to https://services.mozilla.com but cannot login via the Weave FF3 plugin. Could someone at least delete my entire account and I will try to re-register again to see what happens.

Thanks
Susheel
After setting up my own local-weave dav server, I can sync fine to mine. Services.moz still gives me problems logging in via web and add-on.

Any insight on when https://services.mozilla.com logins will be resolved?

Thanks,
 -dj
Thanks to santas little helpers my weave installation seems to be miraculously fixed. I can even login/sync via the plugin now. Whoever you are, thanks. 

-Susheel
This is fixed now in the 0.2 server, I believe.
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.