Page MenuHomePhabricator

login error
Closed, DeclinedPublic

Description

I see the error reported in bug 51789.
"No active login attempt is in progress for your session."

I was logged out reading a wikimedia page in desktop mode.
I log in.
I am sent to mobile version and am shown that error.

The number of times I end up on mobile version is beyond a joke. I never ever ever want it. Especially when it doesnt work.


Version: unspecified
Severity: major

Details

Reference
bz63821

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:16 AM
bzimport set Reference to bz63821.
bzimport added a subscriber: Unknown Object (MLST).
jayvdb created this task.Apr 11 2014, 3:01 PM

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1919

I suspect this might be a side effect of http://blog.wikimedia.org/2014/04/10/wikimedias-response-to-the-heartbleed-security-vulnerability/

Is this still happening? The login code is pretty separate from mobile so it is unlikely to be a bug our end.

Why unconfirming a bug? If it isnt your department, it can be moved to a different component.

If it was due to the operations response, this is not the first time that passwords have been reset by the WMF, and it wont be the last. The bug exists. It needs to be fixed so it doesnt happen next time.

If you dont think it will be affecting a large number of people (do you have logs to see whether occurrence of this response has spiked?), drop the priority.

Please do not change status fields - see https://www.mediawiki.org/wiki/Bug_management/Bugzilla_etiquette
I marked as unconfirmed as we are currently able to replicate this and identify the problem. Back to my last question, is this still happening to you? If so are there steps you can use to reliably replicate it? Whilst it is only the MobileFrontend product it is unconfirmed. If we can replicate it and get to the bottom of it we can move it to another component and change the status there.

Adding Chris Steipp who may be able to comment on whether this was a one off and how it may have effected people.

PS. FYI the priority field is pretty much ignored on the MobileFrontend extension so setting it won't have any impact on planning or getting it resolved. I hadn't even noticed you'd set it so high until you just pointed it out.

(In reply to John Mark Vandenberg from comment #3)

Why unconfirming a bug?

Because nobody else has seen or reproduced it.

Can only assume this was related to the heartbleed bug response. Please reopen if you can still replicate this.