Description

The order cookies related to their cookie path are handled is changed between 1.8 (and before) and 1.9 .

Steps to reproduce

The following procedure describes one specific problem in one specific setup. There could be more incompatibilities caused by changes in the cookie handling. We have a wiki farm on one domain. So we have wikis http://test/a, http://test/b and so on. At one point in time there was one wiki at the root of http://test. All these wikis have created cookies in the client browsers. To reproduce this setup, one hast to edit/create cookies in the browser or change wiki locations like explained above.

First of all a browser with a clean cookie cache is needed. The browser should accept cookies. A plugin to examine/edit cookies is helpful.

To reproduce with a cookie editor (like the Web Developer plugin for FF):

1. Have a wiki with logins on http://test/a

   • The default cookie_path for this wiki will be "/a" (http://hg.moinmo.in/moin/1.9/file/a88ddb0f486b/MoinMoin/web/session.py#l106)

2. Manually set a cookie or just change the path to "/" of a existing cookie for the wiki in your browser
   • Name MOIN_SESSION
   • Value 0e257e5192ec08251dd113a9d9491330c444400c (random)
   • Host test

   • Path /

   • Secure No

   • Valid to <date in future>

3. Surf to http://test/a

4. Login

5. Visit any other side like http://test/a/test or reload the page.

6. You are logged out.

To reproduce only with wikis:

1. Have a wiki with logins on http://test/

   • The default cookie_path for this wiki will be "/"
2. Login this wiki with your browser.

3. Change the location of the wiki to http://test/a and restart the web server.

   • The default cookie_path for this wiki will be "/a"

4. Surf to http://test/a

5. Login

6. Visit any other side like http://test/a/test or reload the page.

7. You are logged out.

After both procedures there will be two cookies in the cache. Example:

• Name MOIN_SESSION

  • Value <random>

  • Host test
  • Path /a
• Name MOIN_SESSION

  • Value <random>

  • Host test
  • Path /

It looks like the order for looking up cookies has changed. When evaluating if a user is logged in first of all the cookie on the root of the domain is looked up, while it is not deleted when logging in.

In 1.8.x we had no problems with stray cookies with a root path.

Component selection

• cookie handling in 1.9

Details

Workaround

• Tell the users to delete the cookie cache once.
• Do not mix wikis on the root of a domain with wikis on a level below (possible with rewrite rules).

Discussion

Just some notes / additional infos:

• the cookie value is the session id, it points into moin's (server side) session storage
• for a single wiki, one usually has the script_root path in the cookie
• for a farm of rather independant wikis, same thing
• for a farm of wikis under same domain and same base path, with unified login and same users, one can share the session_dir and use cookie_path = '/basepath' (or just '/', if that is the common base path), e.g.:

  • http://example.org/wiki1

  • http://example.org/wiki2

  • http://example.org/wiki3

  • cookie_path = '/'
  • session_dir = '/same_sessiondir_for_all_wikis'
  • user_dir = '/same_userdir_for_all_wikis'
  • moin will then accept the same cookie for all wikis and share the session between all wikis - you only need to login once, trail will be for all wikis
  • this "unified login" with a common cookie is not new in 1.9, that worked also in 1.8 (and even older moin version)

Currently, it is a bit unclear still, what exactly is going wrong and how it has to be changed to improve it. Because of wsgi/werkzeug-related refactoring, the cookie and session code is very different in 1.9 compared to 1.8.

Note to anonymous bug reporter: could you please create an account here and subscribe to this page, so you get notified about changes here?

Ideas:

• assuming that moin code gets multiple MOIN_SESSION cookies, maybe we should just select the one that has same path in it as cfg.cookie_path.
• Original reporter: I began testing with both patches today. Everything seems to be working for now.

  • Now I use some wikis with shared user base as mentioned above with the patches from below. For now I use cookie_name = u'<port>_ROOT_<other_wiki_python_class>' in the shared "child" wikis. This might break easily (e.g. when changing port). Another solution might be to set cookie_name = u'<random_helpful_string>' in all shared wikis.

    • Just some unrelated observation to the suggestion for "unified login" above. The trail is shared, but the links always lead to the wiki displayed. So if looking at wiki1/test, and then wiki2 (with the same shared user) the trail will show the "test" page, but the link will lead to the possibly inexistent wiki2/test page.

Plan

• Priority:
• Assigned to:

• Status: please test: http://hg.moinmo.in/moin/1.9/rev/4226fde63931 and http://hg.moinmo.in/moin/1.9/rev/b0c8c2f225f3

CategoryMoinMoinBugFixed