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.