Last modified: 2013-04-22 16:17:04 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 T44832, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 42832 - Can't return to http after login with $wgSecurelogin
Can't return to http after login with $wgSecurelogin
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.21.x
All All
: Unprioritized normal (vote)
: ---
Assigned To: Tyler Romeo
:
Depends on:
Blocks: 39380
  Show dependency treegraph
 
Reported: 2012-12-07 19:32 UTC by Chris Steipp
Modified: 2013-04-22 16:17 UTC (History)
2 users (show)

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


Attachments

Description Chris Steipp 2012-12-07 19:32:50 UTC
When $wgSecurelogin is true, the login has the checkbox "Stay connected to HTTPS after login".

If this option is left unchecked, the user's session cookie is set with the secure flag, but the user is then forwarded to http, and loose their session.

If you have not patched bug 40995, then you will often not see this, since the session frequently will be started under an insecure connection, and is not refreshed on login.
Comment 1 Tyler Romeo 2012-12-07 19:49:15 UTC
Hmm, so since the session is set up when the form loads, from what I see the only way to fix this is to close the session, change the cookie parameters, and then restart the session.
Comment 2 Tyler Romeo 2012-12-07 19:56:45 UTC
https://gerrit.wikimedia.org/r/37488
Comment 3 Brion Vibber 2012-12-07 20:05:46 UTC
I would recommend removing the checkbox -- all logins should go through https or you're just leaving the account open to session stealing if on open networks.
Comment 4 Tyler Romeo 2012-12-07 20:15:31 UTC
I would agree, but some wikis don't want that. I would agree to having an option forcing all logged in users to be on HTTPS, but we should at least have the option of allowing returning to HTTP.
Comment 5 Chris Steipp 2012-12-07 20:18:36 UTC
Brian, I totally agree.

Tyler, I *think* we can add a parameter to set the session as secure or insecure as part of the session refresh on a successful login.

So the login csrf token is checked against the original session, but the new session is secure/insecure based on the checkbox.

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


Navigation
Links