https://bugzilla.wikimedia.org/show_bug.cgi?id=39380
--- Comment #24 from Tyler Romeo <[email protected]> 2012-08-28 03:32:37 UTC --- (In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > >> experience, which is why I'd rather see effort focused on fixing bug 29898. > > > > But does this change require any other effort besides the change of an > > existing > > setting to true? > > Err, right. I think I remember what's going on here now. So there's > $wgSecureLogin, which basically changes the "log in" link to specify HTTPS. > The > user clicks "log in" and he or she logs in to HTTPS and the user will stay in > HTTPS after successfully logging in. > > However, when the user clicks one of the million HTTP links (in an e-mail, on > a > wiki page, on IRC, elsewhere on the Web), the user will not be automagically > redirected to HTTPS, he or she will _stay_ at HTTP and he or she won't be > logged in any longer. This is very disorienting. The user can click "log in" > in > the corner of the page, but he or she will be transferred to Special:UserLogin > over HTTPS and suddenly the user will appear to be logged in again. > > In short, the issue with just setting $wgSecureLogin to true is that the user > experience kind of sucks, as I understand it. (Feel free to correct me if I've > misread the $wgSecureLogin-related code!) > > (I'm also not sure it actually prevents form submission over HTTP [if the user > navigates to the HTTP version of Special:UserLogin directly].) > > If this is an acceptable situation, it's fine to set $wgSecureLogin to true on > Wikimedia wikis. You'll need to get an okay from Wikimedia Foundation > operations (ops) first before the change can be deployed. The load spike from > logging in over HTTPS should be minimal, but the load spike from users > continuing to use HTTPS after logging in will be less negligible, I think. Ops > will also wants a heads-up so that there isn't an unexplained load spike. This is how $wgSecureLogin works, but is not how it should work. If you notice, enablind $wgSecureLogin adds a "Stay on HTTPS" checkbox to the login form. The intended functionality of wgSecureLogin is that all logins are put over HTTPS, and then the user is given back to whatever they were using before. I just tested this on my test wiki and it doesn't seem to do this, so that's probably a bug, but that's what's supposed to happen. So basically here is what needs to be fixed with $wgSecureLogin: * Actual functionality is fixed * HTTP cookie is set so user will be auto-redirected to HTTPS when logged in there. * Links on the HTTPS login page should be set to the protocol of where the user is coming from (I forget where, but there is a bug filed for this). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
