Last modified: 2014-11-17 10:35:05 UTC
With the early protocol-relative link HTTP+HTTPS parallel deployments starting (bug 20643), we notice there's not currently any way to specify that, as a particular user account, you want to make sure you log in on HTTPS only. This means it's easy to accidentally log in insecurely even though you wanted to log in securely. (This should also be sometimes on by default to force all sessions to be secure -- $wgSecureLogin sorta goes in this direction but doesn't force everything.) In addition to making sure you're automatically sent through to the secure version (or not), this will allow users to receive the appropriate URL scheme in their email notifications: bug 29878. Bonus points for being able to redirect from http to https links in order to bump over to a live SSL login session when following generic links found elsewhere. (may need another bug)
(In reply to comment #0) > With the early protocol-relative link HTTP+HTTPS parallel deployments starting > (bug 20643), we notice there's not currently any way to specify that, as a > particular user account, you want to make sure you log in on HTTPS only. This > means it's easy to accidentally log in insecurely even though you wanted to log > in securely. Remember that this requires our login form to first ask for the user's name, and then their password on a different page. I think I'd rather we just ran all logins through HTTPS to begin with.
Running all login forms through HTTPS, then after that either keeping you in secure HTTPS-land or giving you an insecure cookie and shoving you back to HTTP, is common practice. Forcing all logged-in sessions EVER onto HTTPS is my real preference, but I don't know if we're ready for that yet. :)
(In reply to comment #2) > Forcing all logged-in sessions EVER onto HTTPS is my real preference, but I > don't know if we're ready for that yet. :) Yes, same. I'm a bit unsure why an (intermediate) user preference would be good here. User preferences are generally fairly evil; they're made worse by a lack of support for global (Wikimedia-wide) user preferences. It'd be simpler and saner to switch all e-mail links to be https when the time comes rather than going down the road of different messages based on user preferences. The only thing stopping people from using the secure server currently are the ugly URL scheme and the speed. I think waiting until both of these are resolved (hopefully in short order) and then forcing all users through https makes more sense than a user preference here. Admittedly other sites such as Facebook and Twitter have user preferences for https support. Some sites such as Gmail do not.
(In reply to comment #3) > Admittedly other sites such as Facebook and Twitter have user > preferences for https support. Some sites such as Gmail do not. Casey tells me I'm wrong about this, and I am. http://mail.google.com/support/bin/answer.py?hl=en&ctx=mail&answer=74765 explains that there is a user preference in Gmail, but that the default is for https. I guess the common practice is to offer an option. I'm still unclear on the virtue of making this optional, though.
*** Bug 31432 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Bonus points for being able to redirect from http to https links in order to > bump over to a live SSL login session when following generic links found > elsewhere. (may need another bug) This was filed as bug 31432 and then duped to this bug. To accomplish this securely, we would need to do the following: * When logging in over HTTPS and the pref is set, set the login cookies securely (as always) but set an insecure cookie that specifies that the user wants HTTPS * On every HTTP request, check for the presence of this cookie and redirect to HTTPS if so. This also requires that the name of this cookie be added to the XVO header. It appears that Liangent (in filing bug 31432) and Ryan (through an in-person conversation with me) both came up with the same plan separately.
*** Bug 32061 has been marked as a duplicate of this bug. ***
This can be done on the client side for Firefox and Chrome. https://www.eff.org/https-everywhere
*** Bug 12807 has been marked as a duplicate of this bug. ***
Does this report depend on bug 36456?
This preference would be similar to GMail's preference I suppose. It would: * Affect e-mail notifications and other communication outside the site * Make sure that logging-in forwards you to HTTPS if not already * Set a non-secure cookie with the same expiration and domain that indicates the user is logged in on HTTPS and will make mediawiki redirect whenever a HTTP url is used (bug 36456) Note that this option is only available if the site is configured with a protocol relative url as wgServer. And if the wgCanonicalServer has https, we may want to treat this preference as a hidden pref that is always true.
*** Bug 36456 has been marked as a duplicate of this bug. ***
Related: change I60f44a10.
Change I60f44a10, which implements the functionality described by Roan in comment #6 has been merged. It's triggered by selecting the "Stay connected to HTTPS after login" checkbox when logging in, which is visible when $wgSecureLogin is true. Is there any work remaining on this bug?
(In reply to comment #14) > Change I60f44a10, which implements the functionality described by Roan in > comment #6 has been merged. It's triggered by selecting the "Stay connected to > HTTPS after login" checkbox when logging in, which is visible when > $wgSecureLogin is true. Is there any work remaining on this bug? There still doesn't appear to be a way, as a user, to specify that you want to receive communications that specify a particular protocol (cf. comment 0, comment 11, and bug 29878 comment 8). Your patch addresses the cookie portion and the user option _at login_, but the general user preference is not implemented (or alternately, a particular protocol is not mandated), as far as I can tell. This may or may not be the subject of a separate bug, though. Generally, I'm not sure the approach of using a "Stay connected to HTTPS after login" is a good idea. It doesn't serve a second use-case well (e-mail and other communications) and it seems like weird clutter on the login form UI. If any preference is to be implemented at all (and I'm not sure that mandating for logged-in users and user communications is really that bad), I think it should be done in the same place as every other user preference. This also gives it the benefit of having an easy-to-set default value.
Fully agree that my component that was marked as duplicate( [[Bugzilla:32061]] send emails with https urls) does not seem to be implemented. Of course, I would be comfortable with all urls to be https, and my problem goes away (and for those who prefer secure login)
The MW issue isn't going to be solved any time soon, so bumping to future.
https://gerrit.wikimedia.org/r/47089
Any reason not to WONTFIX this and simply force HTTPS for all sessions? The other 'big sites' like Gmail and Facebook have long since moved to HTTPS-only for all logins.
(In reply to comment #19) > Any reason not to WONTFIX this and simply force HTTPS for all sessions? > > The other 'big sites' like Gmail and Facebook have long since moved to > HTTPS-only for all logins. This isn't for logins, but for HTTPS all the time while logged in. And both Gmail and Facebook still have user preferences for whether users want to use HTTPS or not after login.
Please show me the preference in Gmail to turn off SSL; I'm pretty sure they removed it years ago. Facebook does have one hidden, which is a pretty bad practice since it allows session hijacking.
Screenshots aren't working for me at the moment, but I see the option right now in my general settings for Gmail. (And here's the help page it links me to as well: http://support.google.com/mail/answer/74765?hl=en&ctx=mail).
Ah, thankfully that option is entirely disabled for our corporate account, and only HTTPS is allowed. *shudder* Guess I'm no longer surprised that people get their gmail accounts hijacked in China, eh?
What is preventing us from 'leading' and turning it off? What are the consequences of turning it off and not giving choice?
Change 47089 merged by jenkins-bot: Change secure login to use a user preference https://gerrit.wikimedia.org/r/47089
Change 79960 had a related patch set uploaded by Demon: Change secure login to use a user preference https://gerrit.wikimedia.org/r/79960
Change 79963 had a related patch set uploaded by Demon: Change secure login to use a user preference https://gerrit.wikimedia.org/r/79963
Change 79963 merged by jenkins-bot: Change secure login to use a user preference https://gerrit.wikimedia.org/r/79963
Change 79960 merged by jenkins-bot: Change secure login to use a user preference https://gerrit.wikimedia.org/r/79960
