https://bugzilla.wikimedia.org/show_bug.cgi?id=39380
--- Comment #23 from Daniel Friesen <[email protected]> 2012-08-28 02:48:32 UTC --- (In reply to comment #21) > (In reply to comment #20) > > 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!) > > For any users that notice the protocol, it may be disorienting, but I would > guess most of our users don't really pay attention to it (hopefully I'm wrong > about that!). But the win is that if they click the login link again, they'll > be back using https before they enter their password again. That would be a > step towards helping our users be more secure, even if we have plenty of other > bugs to close too. The problem there though is when they hit the login link they already end up logged in. But now they are sitting on a login page, already logged in, and with no way to bypass it and get back to the page they want to edit. - If they notice they are already logged in they probably won't bother trying to log in again and will be completely confused. Not to mention that forcing someone to login when already logged in is a really ugly experience. - If they try to hit back they will return to http:// and be completely completely confused as they are no longer logged in. I think there are a few things we may want to do to improve the user experience. Firstly we should probably introduce a http cookie for users who log into https. Basically a cookie saying that a user is logged in on https. When we see this cookie on the http version of a page we should immediately redirect them to the https page. This won't be for security but rather to improve the user experience. Secondly we should probably deal with Special:Userlogin's behaviour. The act of a user ending up on a login page when logged in is really strange. There may be some value to logging in while already logged in. But I believe the primary reason for this is a holdover from login and user creation being part of the same page, needing to visit login to get to create user, and admins wanting to be able to create users while logged in. Just like with create user being the same link as login. In the long run we want create user and userlogin to be separate pages. And removal of ever having a combined login+register link, always have separate ones. Right now I think we may want to introduce a &loginlink=1 parameter like we have for &redlink=1. We'll place this on our login link. And when specified this will have the effect of automatically redirecting you to your final destination when you are already logged in. Combined these two things will have the effect of: - When you're already logged in and see a http:// link you will end up back on https:// so you are properly sitting in the place where you are logged in. - When you end up on http:// and the http cookie has disappeared and got out of sync with https clicking on the login link will land you right back on the page you were at, in the https version, already logged in, and also fix your cookie. -- 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
