Cookie path parameter not set if Trac is installed in web root

[christian.seiler@…]

If Trac is directly installed inside the web root (no subdirectory, ​http://example.com/ is the Trac front page), the path parameter of the cookie isn't set at all because req.base_path and req.href() are empty and therefore the python Cookie lib ignores the empty path and does not set it. This causes browsers to use the last "directory" of the current URI (i.e. if the URI is /foo/bar/baz they assume /foo/bar, if the URI is /foo/bar/baz/ they assume /foo/bar/baz, have a look at ​RFC 2109, Section 4.3.1).

Now, if I access a page on /foo/bar and that page sets a cookie, it won't include the Path component, causing the cookie only to be valid beneath /foo. Currently, the following header is returned:

Set-Cookie: name=value;

Correct would be:

Set-Cookie: name=value; Path=/;

As for possible fixes, the _send_cookie_headers function in web/api.py already does some escaping:

            if path:
                path = path.replace(' ', '%20') \
                           .replace(';', '%3B') \
                           .replace(',', '%3C')

The simplest solution would probably to add an else clause:

            if path:
                path = path.replace(' ', '%20') \
                           .replace(';', '%3B') \
                           .replace(',', '%3C')
            else:
                # If trac is installed in the web root, path will be empty,
                # but should be '/'
                path = '/'

Of course, a Trac plugin could not rely on the fact that supplying an empty path would restrict the cookie to a subpath anymore, but those plugins could simply explicitly set path to a subpath in order to restrict the cookie.

This applies to 0.10 and 0.11.

[osimons]

13 months without feedback… Oouch - and sorry!

Your write-up does make sense. There have been various issues with installations at webserver root, and perhaps this could help explain/improve that.

I'll put it on my to-do.

[Remy Blank]

Feel free to schedule for an earlier milestone.

[Remy Blank]

This seems to have been fixed in [7386] for #5637.