Last modified: 2008-08-24 02:53:56 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 T16887, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14887 - Configuration option to disable persistent cookies
Configuration option to disable persistent cookies
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-22 14:03 UTC by Thomas Owens
Modified: 2008-08-24 02:53 UTC (History)
4 users (show)

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


Attachments

Description Thomas Owens 2008-07-22 14:03:00 UTC
After having worked on a project that required it, there should be a global variable (such as $wgEnableCookies) which defaults to TRUE, but can be toggles to FALSE. If false, cookies are not put on the computer of a visitor and all checkboxes that result in a cookie being written are removed from the UI. This could be accomplished with a simple flag around all code that results in a cookie being places:

if ($wgEnableCookies) {
//Handle cookies
}
else {
//Handle sessions, no cookies
}
Comment 1 Roan Kattouw 2008-07-22 14:05:28 UTC
Exactly why would you *want* to disable cookies while the client can just deny them? Also, staying logged in relies on cookies: sessions use cookies internally.
Comment 2 Thomas Owens 2008-07-22 14:07:58 UTC
> Exactly why would you *want* to disable cookies while the client can just deny
> them? Also, staying logged in relies on cookies: sessions use cookies
> internally.

For my project, it was US Dept of Defense rules. Sessions are OK, but cookies can not be written by a DOD-sponsored website. I'm sure there are other organizations with similar rules, and this wouldn't be *that* difficult to implement.
Comment 3 Daniel Kinzler 2008-07-22 14:11:57 UTC
Uh, and how are sessions supposed to work without cookies?

Session IDs in URLs are possible in theory (though not implemented by mediawiki). They are, however, more insecure by far. Look up "session fixation".

So, no cookies, no login. 
Comment 4 Thomas Owens 2008-07-22 14:16:51 UTC
(In reply to comment #3)
> Uh, and how are sessions supposed to work without cookies?
> 
> Session IDs in URLs are possible in theory (though not implemented by
> mediawiki). They are, however, more insecure by far. Look up "session
> fixation".
> 
> So, no cookies, no login.

The fix that passed regulations was to:

(1) Remove all checkboxes for remembering a user's login
(2) Set $wgCookieExpiration = 0

So this new global variable would do both automatically, without the need to change any MW file, except for LocalSettings.php, where you could toggle the variable.

Comment 5 Roan Kattouw 2008-07-22 14:18:27 UTC
(In reply to comment #4)
> The fix that passed regulations was to:
> 
> (1) Remove all checkboxes for remembering a user's login
> (2) Set $wgCookieExpiration = 0
> 
> So this new global variable would do both automatically, without the need to
> change any MW file, except for LocalSettings.php, where you could toggle the
> variable.
> 

Wouldn't that make your wiki severely defective? If no one can login, there are no privileged users, so either no one can ban people, delete pages, etc. or everyone can. Both are undesirable.
Comment 6 Thomas Owens 2008-07-22 14:19:48 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > The fix that passed regulations was to:
> > 
> > (1) Remove all checkboxes for remembering a user's login
> > (2) Set $wgCookieExpiration = 0
> > 
> > So this new global variable would do both automatically, without the need to
> > change any MW file, except for LocalSettings.php, where you could toggle the
> > variable.
> > 
> 
> Wouldn't that make your wiki severely defective? If no one can login, there are
> no privileged users, so either no one can ban people, delete pages, etc. or
> everyone can. Both are undesirable.
> 

I can log in and use my assigned privileges. Everything works as expected. The only difference is that when I close my browser, I am logged out. There are also no files left on a computer of a visitor.
Comment 7 Daniel Kinzler 2008-07-22 14:23:55 UTC
$wgCookieExpiration = 0; will still set a session cookie. It will just tell the cookie to expire when the browser is closed.  But note that this is far from "disabling cookies". So, what EXACTLY does the policy require?

Again: cookies are needed to manage sessions. There is no other way to manage sessions (well, technicaly, HTTP-Auth or HTTPS-Auth might be possible, but quite inconvenient for users, and probably impossible to use without logging in).

That bein said: An option to disable the "remember me" checkbox would be fine with me. This is the only one I know of that would cause an additional cookie.
Comment 8 Thomas Owens 2008-07-22 14:27:08 UTC
(In reply to comment #7)
> $wgCookieExpiration = 0; will still set a session cookie. It will just tell the
> cookie to expire when the browser is closed.  But note that this is far from
> "disabling cookies". So, what EXACTLY does the policy require?
> 
> Again: cookies are needed to manage sessions. There is no other way to manage
> sessions (well, technicaly, HTTP-Auth or HTTPS-Auth might be possible, but
> quite inconvenient for users, and probably impossible to use without logging
> in).
> 
> That bein said: An option to disable the "remember me" checkbox would be fine
> with me. This is the only one I know of that would cause an additional cookie.

I'm not up to speed on the exact regulation, but anything relating to sessions is fine, as long as they are invalid upon a browser close or deleted on a browser close. Since this passed current DOD regulations, it's good enough for me. The only thing that I didn't like to do was modify files other than LocalSettings.php, so a way to avoid that would be nice and this seems to be a good solution.
Comment 9 Daniel Kinzler 2008-07-22 14:53:31 UTC
So the option required would be to disable *persistent* cookies. That sounds reasonable. I'll adjust the request description accordingly.
Comment 10 Thomas Owens 2008-07-22 14:54:47 UTC
(In reply to comment #9)
> So the option required would be to disable *persistent* cookies. That sounds
> reasonable. I'll adjust the request description accordingly.
> 

That sounds better. I'm sorry if my terminology is off. I'm far more used to non-web development, so I'm not yet familiar with these terms and phrases.
Comment 11 Chad H. 2008-08-15 01:55:36 UTC
Done in r39376
Comment 12 Chad H. 2008-08-24 02:53:56 UTC
As an update, $wgEnablePersistentCookies was removed. Instead, setting cookie expiry to 0 now disables the setting of any cookies that last beyond the end of the session. All setcookie() calls go through $WebRequest->setCookies() now, so that's a nice clean interface for it.

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


Navigation
Links