Last modified: 2013-09-06 15:29:16 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 T31986, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29986 - $wgSecureLogin fails to handle page links, non-SSL content
$wgSecureLogin fails to handle page links, non-SSL content
Status: NEW
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.17.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-20 19:47 UTC by Dan Barrett
Modified: 2013-09-06 15:29 UTC (History)
3 users (show)

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


Attachments
SecureLoginPage.php (480 bytes, text/plain)
2011-07-20 19:47 UTC, Dan Barrett
Details
SecureLoginPage_body.php (986 bytes, text/plain)
2011-07-20 19:47 UTC, Dan Barrett
Details

Description Dan Barrett 2011-07-20 19:47:07 UTC
Created attachment 8806 [details]
SecureLoginPage.php

The SSL login feature enabled by $wgSecureLogin produces pages that can be confusing to users. Here are several use cases that happen when $wgSecureLogin=true.

1. User clicks "Log in". On the login page (which is https), the user does not log in, but clicks another link on the page such as "Recent changes". This link is also https. Suddenly the user is viewing the wiki via SSL, when this might never have been the user's intention.

2. User clicks "Log in". The logo image, which was set by a sysadmin via $wgLogo to be "http://some.other.site/myfile.jpg", gets served over http. The browser (IE) pops up a warning, "Do you want to view only the webpage content that was delivered securely?" The user gets confused or scared by the popup.

Several years ago I published a SecureUserLogin extension in my O'Reilly "MediaWiki" book. It avoids problem 1 by automatically switching from https to http when serving pages other than the login page. (Unless the user wants a totally SSL session.) I believe MediaWiki should do similarly.

I will attach a copy of the extension in case it's useful to you.
Comment 1 Dan Barrett 2011-07-20 19:47:30 UTC
Created attachment 8807 [details]
SecureLoginPage_body.php
Comment 2 Roan Kattouw 2011-07-20 20:25:57 UTC
We're already working on making URLs in MediaWiki protocol-relative as much as possible. Basically, if you set $wgServer = '//wiki.example.com'; in trunk as of a few days ago, that'll mostly work as you expect.
Comment 3 Roan Kattouw 2011-07-20 20:28:57 UTC
Comment on attachment 8806 [details]
SecureLoginPage.php

Change MIME types of PHP files to plain text so Bugzilla will hopefully display them to me without making me download them.
Comment 4 Brion Vibber 2011-07-20 20:35:12 UTC
Using protocol-relative links doesn't have any effect on case 1) since those links are always on the local protocol/host anyway.

Proper 'fix' for that is of course to always use SSL for all logged-in sessions at all times, which is much safer.
Comment 5 Dan Barrett 2011-07-20 20:41:57 UTC
Brion: I see your point about security. Until such time that Wikipedia goes 100% SSL, it would be great if the secure login feature just followed the contract with its user: delivering articles over http unless the user has logged in and checked the "everything SSL" checkbox.  Seem reasonable?
Comment 6 Andre Klapper 2013-09-06 10:06:12 UTC
This really needs retesting now that SecureLogin is enabled by default. See https://meta.wikimedia.org/wiki/HTTPS
Comment 7 Tyler Romeo 2013-09-06 15:29:16 UTC
The bug definitely still exists (you can test it now on Wikipedia itself). However, we may consider WONTFIXing this.

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


Navigation
Links