Last modified: 2013-08-04 09:03:06 UTC
Right now, if you log into the wiki under HTTPS protocol, then visit a page under HTTP protocol, it shows you as logged out. This is bad practice, because requires logging in again. The cookies should be shared in HTTP and HTTPS.
Dupe of bug 29898?
Not really. Bug 29898 talks about if a user wants to always use HTTPS for login (JUST for login), and how to enforce all sessions to be secure. This bug, however, is about retaining the login status if at some point you decide to switch protocols. For example, I may use HTTP primarily and even decide to login over HTTP (and therefore not use the feature 29898 is suggesting); however, after I'm logged in, if I click on a DIFF link which has HTTPS in the beginning of it, I still want to show as logged in. They are related features, but not the same.
(In reply to comment #2) > For example, I may use HTTP primarily and even decide to login over HTTP (and > therefore not use the feature 29898 is suggesting); however, after I'm logged > in, if I click on a DIFF link which has HTTPS in the beginning of it, I still > want to show as logged in. With a completely reset Web browser (no cookies, no cache, etc.), if I navigate to <http://en.wikipedia.org> right now and successfully log in, when I subsequently navigate to <https://en.wikipedia.org>, I'm also logged in. Logging in via HTTP will log you in to both HTTP and HTTPS. Given this, I'm still unclear what the bug is here. Does this feature not work for you?
The reverse doesn't work. Log into HTTPS and then visit the site under HTTP.
(In reply to comment #4) > The reverse doesn't work. Log into HTTPS and then visit the site under HTTP. Right. This is a security feature. It prevents users from unwittingly exposing their session information over HTTP after they've properly logged in via HTTPS. I believe this bug is invalid.
I'm not sure if this is against security standards. From bug 29898 comment 2 by Brion Vibber: > 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. If it is reasonable to allow HTTP users to use HTTPS for login and then be redirected back to HTTP, then it is also reasonable to allow a user who started on HTTPS, and logged in on HTTPS, to retain their cookies in HTTP too. I will wait for further input from others.
It's not secure to send https cookies over http. So if a user requests https on mediawiki login, we set the flag to only send the session cookie for page reqests over https. Otherwise an attacker just has to give a victim an image or redirect to http://en.wikipedia.org, and can sniff their session cookie.
Is this bug WONTFIX/INVALID then?
(In reply to comment #7) > It's not secure to send https cookies over http. So if a user requests https on > mediawiki login, we set the flag to only send the session cookie for page > reqests over https. Otherwise an attacker just has to give a victim an image or > redirect to http://en.wikipedia.org, and can sniff their session cookie. I wonder why major online services like GMail or Yahoo! do that then. They only use HTTPS for login, by default.
Gmail is https-only since .... a year or two ago? We should be following that model and dropping all HTTP login support these days.
