Last modified: 2014-09-16 16:06:44 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T71319, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 69319 - Allow option to uncheck "Always use a secure connection when logged in" at login.wikimedia.org/wiki/Special:Preferences
Allow option to uncheck "Always use a secure connection when logged in" at l...
Status: NEW
Product: Wikimedia
Classification: Unclassified
SSL related (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: global-prefs
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-09 02:33 UTC by Cometstyles
Modified: 2014-09-16 16:06 UTC (History)
7 users (show)

See Also:
Web browser: Firefox
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Cometstyles 2014-08-09 02:33:13 UTC
I generally use wikimedia wikis on the non-secured http format so over the last 2 years, whenever i end up on a wiki where the "Always use a secure connection when logged in" is checked (by default), i'm forced into https which also forces my other wikis including the major ones into https, which can only be fixed via logging out multiple times on each wiki. I'm a filemover on commons which means when i rename i file, i'm auto-logged into all the wikis the files is on to replace them but because i'm randomly logged out of most of them wikis due to this irritating 'bug', I'm unable to replace the files on those wikis, I'm lucky if i even get 2 wikis done...

so please allow a global option to "uncheck" 'Always use a secure connection when logged in' at https://login.wikimedia.org/wiki/Special:Preferences to allow users like me to keep our http option instead of randomly getting logged out of wikis. currently the 'check' option is greyed out...

Https is slow and does not cache, and I'm on a somewhat slow internet access with limited data so being forced to cache scripts everytime i refresh just wastes away my data and I'm not the only one, all 3rd world countries have users on slow internet connection, they are probably affected in the same way..when i was on dialup on enwiki between 2006-2010, i was fast and that time there was no https option, now even on a slightly faster speed (7mbps connection), it feels worse than dial up at times when i end up on https ...
Comment 1 Andre Klapper 2014-08-09 17:40:48 UTC
So the request is that the by-default-enabled setting "Always use a secure connection when logged in" on https://login.wikimedia.org/wiki/Special:Preferences should not be greyed out?

Wondering why it's greyed out - Chris, do you know?

Also see https://meta.wikimedia.org/wiki/HTTPS#Disabling for general info.
Comment 2 Chris Steipp 2014-08-11 21:46:19 UTC
login.wikimedia.org really should never be visited by end users, and users don't have edit rights there. That is why they can't edit any preferences.

The preference on loginwiki has almost no impact on your use of https on other wikis (unless you're actually putting in your username and password there). It will enforce that the actual login handshake (which is uncachable anyway, since we're logging you in) goes over https if you're not from China/Iran.

I think the issue Cometstyles is hitting is that logging into a project that didn't have the preference set (ie., zh.wikipedia.org), and we set the forceHTTPS cookie at the top-level domain for the project (.wikipedia.org), so other wikis in project would start redirecting to https, even though their cookies are good for both http and https.

The fix for this is either a global preference, which unfortunately we don't have yet. Or we set forceHTTPS per wiki, which was actually the original design, but was changed a while back because it makes it really hard to usefully examine your cookies.
Comment 3 Cometstyles 2014-08-14 14:52:14 UTC
I figured login.wikimedia.org was the "global special:preference" and changing it there would affect all wikis..it could be a good idea to make it the Global Preference panel for wikimedians..Wikia has a global option on their wikis, I wonder why we are so behind...
Comment 4 Cometstyles 2014-09-15 14:01:49 UTC
And trying to remove the "forcedHTTPS" cookies kills all my logins and i can no longer log in and then i'm forced to delete all my cookies related to "centralauth" and then i have toi manually log oint oall wikis one by one by visiting them...I sometimes edit over 40 different wikis a day, this is very very very irritating..please find a fix fast, Allow users the option to OPT-OUT of https......FGS!!...
Comment 5 Andre Klapper 2014-09-15 15:06:11 UTC
(In reply to Cometstyles from comment #0)
> Https is slow

It's been explained on IRC already that this is not correct, and that the reason for the slowness when using HTTPS is likely not HTTPS itself but something outside (provider? routing?); and comment 2 has explained that the specific HTTPS preference that you refer to is only applied for the *handshake* anyway.

Summarizing how I understand things: 
The problem that you experience is very likely triggered by something else and changing that preference would not solve your problem.
Comment 6 Cometstyles 2014-09-16 14:01:31 UTC
Its less about it being slow and more about it being irritating..why should you en"forcehttps" on me (via cookies) even though i have disabled that option in that wiki's preference? ..you people are refusing to see this as a bug/a problem..but its a major pain in the ass for me so please, allow users to globally TURN OFF this pathetic option, no one cares about security on the wiki...

You are sacrificing speed for security (which is unnecessary).. I edit 40+ wikis a day from all domains and this is seriously becoming quite irritating..even deleting the "forcehttps" cookies logs me out of everything and prevent me from login back in unless i delete all centralauth related cookies..if you refuse to fix this, atleast come up with a global script to allow users to bypass this idiotic option.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links