https://bugzilla.wikimedia.org/show_bug.cgi?id=40968
Krinkle changed:
What|Removed |Added
Priority|Unprioritized |Normal
Status|NEW
https://bugzilla.wikimedia.org/show_bug.cgi?id=40968
--- Comment #2 from Tyler Romeo 2012-10-12 02:37:20 UTC
---
Say you're using an extension like Extension:Persona. It does login through an
AJAX API request. However, if you have $wgSecureLogin enabled, it cannot (or
rather should not) use HTTP
https://bugzilla.wikimedia.org/show_bug.cgi?id=40968
Daniel Friesen changed:
What|Removed |Added
CC||mediawiki-bugs@nadir-seen-f
https://bugzilla.wikimedia.org/show_bug.cgi?id=40968
--- Comment #4 from Tyler Romeo 2012-10-12 04:10:49 UTC
---
Yes, but that is irrelevant. If the script is compromised in a MITM attack, the
security of the login process does not matter because the attacker will have
already taken the user's a
https://bugzilla.wikimedia.org/show_bug.cgi?id=40968
--- Comment #5 from Krinkle 2012-10-12 09:34:06 UTC ---
Lets translate it to non-ajax:
When enabling $wgSecureLogin the login link outputted by the server points to
https, so the login procedure goes entirely over https. The login form and
log
https://bugzilla.wikimedia.org/show_bug.cgi?id=40968
--- Comment #6 from Tyler Romeo 2012-10-15 05:05:44 UTC
---
The only problem is that I do not want to fail when not over HTTPS. There needs
to be some way for the user to be forwarded to HTTPS when they try to log in.
However, simply redirecti
