Closed Bug 591527 Opened 14 years ago Closed 8 days ago

Users having trouble logging into SFx

Categories

(Websites Graveyard :: spreadfirefox.com, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: mary, Unassigned)

References

Details

Hi there:  Can someone look into this?  There have been a many folks that have tried logging in and can't.  Even after a password reset.

Is there a way to check authentication logs?  I feel like something is remiss - these emails all came in this week and Fuzzy for instance, logs in frequently.

Here are the users:

PAZ002
Lawn Bowler
http://www.spreadfirefox.com/user/152383


Starscream1 F22
http://www.spreadfirefox.com/user/256569


Weirdow
http://www.spreadfirefox.com/user/157803


FuzzyFox
http://www.spreadfirefox.com/user/205461
OS: Mac OS X → All
Hardware: x86 → All
Assignee: nobody → paulbooker
Hey PaulC:  Can you look into this while we're waiting on some more info on affiliate points?

Other folks are still experiencing this.  Paul B. thinks it might have to do with cookies or caching if I have it right.
Thanks!
I'm not aware of any Drupal issues with logging in, but I strongly dislike that we allow spaces in usernames :)

What would be most helpful is if someone can reproduce this on the staging server, and then hand me the user/password so I can try it out and debug it.

Sadly I'm fairly busy with SUMO stuff at the moment, so, if there are workarounds, and it's not terribly common, I can't justify spending time on this right now.
This is important, but not critical to shipping the Customer Care, etc. pages -- so it should wait until after that.
NP - added Ken.  He had the most recent problem + can hopefully add some more detail :)
I experienced login problems on spreadfirefox.com a couple of week ago which i tracked down to be attributed to multiple cookies for spreadfirefox.com with the same name which i suspect had arisen while switching between firefox 3.6  and firefox 4 beta

Best, Paul
Thanks, Paul.  So to confirm, I should advise these users (comment 1) to try deleting cookies from Sfx?

Thanks for all of your help!
Agreed.  If you could ask folks to let us know how they get on i'll then follow up if there is any further problems.

Best, Paul
Win Vista Firefox 3.6.10
Cannot login into Spread Firefox even after clearing all cookies and cache.
After requesting a new password and receiving the one time login URL, all is well until I log out.
Then I am unable to log in again. Requesting a password reset again using my username returns "Sorry, unrecognized username or password".
If I use my email address, a get a new one time login URL.

The same happens in Minefield 4.0b7pre in a new, clean profile.

(In reply to comment #2)
> I'm not aware of any Drupal issues with logging in, but I strongly dislike that
> we allow spaces in usernames :)
> 

Hasn't been an issue up until now (if that's the issue to begin with) and wasn't on Spread Thunderbird when I was a member there.
Hi Ken,

Do you have the same problem on the stage server @ http://spreadfirefox.stage.mozilla.com/ ?

Other things you could try..

.. firefox 3.x running under ubuntu virtualized on your windows box with virtualbox  
.. disabling your firefox extensions that have been upgraded recently

I'll investigate some more this evening Ken.

Best, Paul
Appcoast
Hey Ken, what is your username?
Hey PaulC:  PaulB suggested cleaing our caching proxy in front of spreadfirefox.com.  Do you think that would help?

I believe Ken's username is just Ken Saunders.  His id is:  91977

Thanks!
If it's anything like SUMO, POST requests go through caching so that wouldn't be a problem.

I wonder if having spaces in usernames is causing problems, too.
Hey there:  Folks with no spaces are having probs too :(

Or do you mean spacing could affect the whole system?

I don't know if SFx is like SUMO in re. to POST requests.  Will need Buchanan to chime in.
Sorry for the slow reply.
Yes, my username is Ken Saunders.

One time after resetting my password, I removed the space and still had the same login issue.
I think that there once was an issue with capital letters being used in usernames when SFx2 was launched. I haven't tried using all lower case yet. I doubt that's the problem, but who knows right now.

Once thing I'm uncertain of is if my new password is being saved after resetting and submitting it since the password field isn't filled when editing my account.

I don't remember my login credentials for the staging site.
I'd be willing to create a new account there and see how things go if someone wants to provide them.
Ok, I was having issues with all of my SFx accounts.
I changed my usernames (for two accounts) to all lower case and I'm able to log out and in normally, without any issues, and, with a spaces used.
So, ken saunders works, Ken Saunders doesn't, access firefox works, Access Firefox doesn't. :)
Thanks for the feedback Ken, it sounds as though were getting to the bottom of this problem now. 


@Mary ,
Do you know if PHP / MySQL have been upgraded recently on production ?

Best, Paul
Nope - but I will check :)
Thanks Mary
So I may have found the root of this problem. Now that I see it, haven't we had this problem all along and known about it?

Looking at the data, it appears that the `name` (username) column is varbinary, a.k.a. case SENSITIVE. That's bad, IMO, but, regardless, I'd be surprised if you can log in without typing your exact username that you registered.

Ken, I see at least two usernames that might be yours, although they have different emails:
KenSaunders
and
ken saunders

So if your login had a space in it, it was all lowercase. We can talk privately if you don't remember which one you had.


As for all the other usernames in comment 0, I wonder if they tried to log in with exactly those usernames, or messed up the case. I'd be curious to know from others if they've tried logging in matching the case and it still failed.
Thanks for looking into this.  I did have people use their exact names + reset passwords, etc.

So not sure what is shaking :(
I suggest we make that column case insensitive, i.e. turn it into VARCHAR.

The problem is that there will be duplicates if we do, and it will fail.

SFx currently has 312399 total users (on a database from 2 weeks ago or so), out of which 309057 have unique logins. So, there are 3342 duplicates, which is *way too much* to go through on a case by case basis.

I spoke with malexis and I'm suggesting we clean up our database by deleting all of the users that have been inactive for a while.

On SUMO, we did something similar in bug 464087.

Mary, I think this is your call.

Here are some numbers:

Of total registered users:

* 53846 have logged in AFTER January 1st, 2009, out of which 53661 are unique (so only about 180 duplicates)
* 15468 have logged in AFTER January 1st, 2010, out of which 15454 are unique (ONLY 14 duplicates, yay!)
* about 62,000 users registered since January 1st, 2009
    -> about 15,000 of those never logged in

IMO the less data we keep around, the better. Let me know if you'd like any other numbers to make a decision!
Thanks for the numbers.

Paul, I'm wondering if most duplicates are from people signing up twice. How many of the duplicates have unique email addresses? (eg: different email address for both usernames)
Our previous conversation

https://bugzilla.mozilla.org/show_bug.cgi?id=432274
Depends on: 432274
Hi Paulc:  Are you sure this is the root of it?  It just came up and we've had dupes for a while.

I don't feel like we can turn off the dupes right away.  Here is what I initially outlined in terms of communicating to people on the issue:

https://wiki.mozilla.org/Spreadfirefox_duplicate_usernames

Will it be possible to present a custom message to the folks that are affected?
I think it would be best to talk out these scenarios a bit live.

Setting up a meeting for tomorrow.  Anyone else want to join?

Thanks for taking a look into this PaulC :)
I'm not sure this is the root of it. I suppose it could be some module or something we've had custom written. My assumption is just that it's not core Drupal, because that's thoroughly tested code.
(In reply to comment #24)
> Will it be possible to present a custom message to the folks that are affected?
Well, we can email them with the _old_ and the _new_ usernames. We don't need to delete all the duplicates, we can rename them. But as I mentioned in comment 21, it's much preferred that we do this only for the users that are still currently active. I'm not a fan of carrying old data around :)
AMO has a new(ish) policy that seems reasonable and is intended to increase site performance.
http://blog.mozilla.com/addons/2010/07/26/upcoming-changes-to-amo-accounts/

Deleting inactive accounts
"In the next few weeks we plan to delete any accounts that have not logged in since April 2009 who don’t have any add-ons, collections, or reviews associated with them. This will reduce our 4.5 million accounts to a more manageable 800,000."
@Mary ,
Do you know if PHP / MySQL have been upgraded recently on production ?
Can someone confirm the type of the 'name' field in the users table 
 
Best, Paul
Hey there:  Nope, it wasn't updated.

Buchanan or Paul:  Can you answer Paul's second question?

Thanks!
`name` varbinary(60) NOT NULL
A database from September 30.
Hey guys:  Meeting with PaulC right now.  We're going to definitely do the database clean up + I'll start in on the communications.

In the meantime, he's going to do more debugging since this doesn't seem to pertain to dupe usernames at all.  I just put him in touch with one of the users.

Thanks!
Me again!

Here's the wrap up for our discussion.

- PaulC will debug our the login issue since there doesn't seem to be a correlation to dupes.  Issues started to appear at end of August.
- We'll do database clean up. However, we're not going to delete everyone that hasn't logged in since Jan 1, 2009 (that's 250K users).
- Instead:
-- We'll clean up the dupes.
-- Paul will write a script that will append a number to users names + send an email to these people affected to let them know of their user name.
-- I will communicate out on SFx, my blog, Twitter, etc what is happening to reinforce this and let people know it's not a scam :)
-- We'll have this done by Dec. 8th (unless we have another SFx resource)
-- I'll update the other bug (432274)

Thanks so much!
Hi Mary / Paul

I agree there does not appear to be any correlation between our recent login problems and our case sensitive users. There is probably a number of problems here as i mentioned earlier i had a very similar login problem which was attributed to an extra cookie for spreadfirefox.com (with the same name) which came about as a result of switching between firefox 3.6 and firefox 4 beta. In the past we have also had similar login problems resulting from issues with the proxy server in front of the web server. The only other suggestion for our login problem that comes to mind is that the problem is server related either a change in PHP / MySQL but this has been ruled out. Interesting problem :-)   

It's great to hear that were going to resolve our problems with case sensitive users in the database. Just for the record i agree with Paul that we should look at removing users that are not using their accounts and we should also have more hurdles for folks creating accounts one idea might be that they need to get a recommendation from someone in the community who has been a member for a period of time.  

Please feel free to ask if you would like any help with the helper module.

Best,
Paul Booker
Appcoast
Hey PaulC:  Any luck tinkering with this?  Let me know!
Assignee: paulbooker → nobody
Hey guys:  Has anyone been checking into this?  It's still a problem and I've caught up on email and heard from 6 new people.

Please help!
Mary, ever since I changed my username(s) to all lower case (in September), I haven't had any issues.
Perhaps you could share that temporary fix. If it works for those 6 people who have contacted you, then maybe it wouldn't be a bad idea to add that info to the login page, your inbox will become a little lighter, and there will be fewer frustrated members.
Hey guys:  Two new thoughts on this.  It feels like this was a setting change so...can we check the following:

* Recent Drupal security updates + release notes.
* Any setting changes in the user database or admin interface

Thanks!
Hey Alex:  Did you look into what I suggested above?

Please let me know.  Thanks!
Hey guys:  Can I please get some help with this?  It looks like Alex is now gone.  Can anyone else be assigned to this bug?  Disgruntled user emails keep coming my way + this bug has been open for four months :(  Some help pretty please?
Hi Mary,

Just wanted to let you know that i will take another look at this problem today.

Best,
Paul Booker
Appcoast
@Mary

Just read everything that has been written from the top and i don't have any further suggestions right now as to what has brought about the case sensitivity login problem on production.

I would like to investigate if this problem is reproducible on stage but when i try to login on stage right now i get a "The page isn't redirecting properly" page. I'll explore the problem on my local development server a little later today. 

Is it possible to request a list of all changes that have been made to spreadfirefox stage / production servers with dates for 2009 ?


Now might be a good time to mention that Drupal 7 is released today which potentially means that spreadfirefox.com could become a security problem for us should the the Drupal security team release a large security update for Drupal 6 / 7 which normally happens following a new .0 release. Should the Drupal security team release a large security update for Drupal 6 / 7 it may be best to plan to take down spreadfirefox.com while the security risks for us are assessed. 

http://drupal.org/project/drupal

Best,
Paul Boooker
@Mary 

Probably related so i'll mention here that i observed that registration was not working on production a user gets a "pending admin approval" email after completing the registration page but when you look at the User administration page @ admin/user/user the account has not been record in the database. On my local server registration works fine with no "pending admin approval" but my local server is not an exact match with what is on production as i had to install a fresh database. I'll be around later this afternoon / evening to help out further.

Best, Paul
Product: Websites → Websites Graveyard
Status: NEW → RESOLVED
Closed: 8 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.