When I have two project named 'test' and 'test1', If I log int test, test1 can't log in!

[buaa.byl@…]

This is my configure:

<LocationMatch "/trac/[^/]+/login">
  AuthType Basic
  AuthName "Trac"
  AuthUserFile /home/trachome/trac_pool/apache.passwd
  Require valid-user
</LocationMatch>

I have two project: 'test' and 'test1'

If I log in test, then I can't log in test1. But if I log in test1, then I can log in test! I don't know why.

This configure still not work

<Location "/trac/test/login">
  AuthType Basic
  AuthName "Trac"
  AuthUserFile /home/trachome/trac_pool/apache.passwd
  Require valid-user
</Location>

<Location "/trac/test1/login">
  AuthType Basic
  AuthName "Trac"
  AuthUserFile /home/trachome/trac_pool/apache.passwd
  Require valid-user
</Location>

Does it bug for apache? I use apache 2.2 + trac 0.11.6 thanks.

[buaa.byl@…]

I test tracd, got the same error.

[Christian Boos]

Try using different realms, i.e. different values for the ​AuthName directive.

(This is technically speaking an InstallationIssue, and should have been asked on the MailingList, but I'm interested in the answer as well)

[buaa.byl@…]

Replying to cboos:

Try using different realms, i.e. different values for the ​AuthName directive.

(This is technically speaking an InstallationIssue, and should have been asked on the MailingList, but I'm interested in the answer as well)

I am sorry.This just happen in Opera browser. Officall Configuation work fine in FireFox and IE. But there are difference between FireFox and IE:

When I login test in FireFox, username and password no need for login test1! 
And in IE, login each project need username and password. no matter clicked "remember my password".

Maybe IE think that two site is difference, and FireFox/Opera think that two site is same?Have trac use cookie to remember session?

I will try more.

[buaa.byl@…]

just open project test1 and then open test

[anonymous]

then I login project test. It is ok.

[buaa.byl@…]

then login test1, fail. and cookie is modify not expect.

[buaa.byl@…]

open test first and then open test1, cookie is difference.

[buaa.byl@…]

then login test1 first. It is ok.

[buaa.byl@…]

then I login test, It is ok too. but cookie is also modify!

[buaa.byl@…]

Then normal cookie in other project.

[anonymous]

I found cookie difference!

• In firefox, if open project, will create trac_session and trac_from_token cookie for each project. If login each project, trac_session of this project will delete, and trac_auth create.No matter login test first or login test1 first.

• In opera, if open project, also create trac_session and trac_from_token cookie for each project. But if I open test first, then open test1 , there are neither trac_session nor trac_from_token for test1!Just for test. If I open test1 first, It is normal.

• In opera, if login test first, will create trac_auth for test.And then I try to login test1, It just modify trac_session for test1, trac_auth for test1 no create.

• In opera, if login test1 first, will create trac_auth for test1. And then I try to login test.It's ok, but cookie is still missing trac_form_token of test1.

And, if there have two project named "test1" and "test2", the cookie in opera act same as firefox.Each project have trac_auth and trac_form_token.(but trac_session not delect).

I will write some test for mod_python to make sure this is bug for opera or for trac. Thanks.

[buaa.byl@…]

If setup two apache instance with difference tcp port,and each project under same url(only difference is port, This will create two different mod_python env.) And I check cookie in opera, the request is same as before.but everything ok, why? Is there trac bug just with opera browser?

[Remy Blank]

comment:16:ticket:2438 shows the headers for requests corresponding to this case, and it seems that this anomaly is due to the URL of one project being a prefix of the other. Some browsers (Safari, Opera) seem to send the trac_auth cookies for both projects when accessing the one with the longer URL. We could try to add a trailing "/" to the cookie path, maybe this will work around the issue.

[buaa.byl <buaa.byl@…>]

Replying to rblank:

comment:16:ticket:2438 shows the headers for requests corresponding to this case, and it seems that this anomaly is due to the URL of one project being a prefix of the other. Some browsers (Safari, Opera) seem to send the trac_auth cookies for both projects when accessing the one with the longer URL. We could try to add a trailing "/" to the cookie path, maybe this will work around the issue.

I make a patch, and it seems work fine in firefox3.6/ie7/opera11. I using trac 0.11.6, does someone test. Thank you.

[buaa.byl <buaa.byl@…>]

Modify trac_auth

[buaa.byl <buaa.byl@…>]

Modify trac_session

[buaa.byl <buaa.byl@…>]

Modify index template, because modify auth, the request must be "​http://server/projects/test/" .

[buaa.byl <buaa.byl@…>]

I apply this modify myself and see if everything ok. If someone get better modify idea, please tell me. Thank you.

[Remy Blank]

Adding a slash to the cookie path is not an option, as it breaks authentication on the root URL (e.g. http://example.com/mytrac) on some browsers (Opera, Chrome), while others work fine (Firefox).

So at this point, I'm afraid it's an incompatibility between browsers, and the solution that will annoy the fewest people is to keep the current cookie paths, and advise not to set up two Trac instances where the base URL of one is a prefix of the other. We should probably document that in the guide.

Opinions?

[j.beilicke@…]

Replying to rblank:

Adding a slash to the cookie path is not an option, as it breaks authentication on the root URL (e.g. http://example.com/mytrac) on some browsers (Opera, Chrome), while others work fine (Firefox).

Was able to confirm this by fiddling around with setting [trac] auth_cookie_path

So at this point, I'm afraid it's an incompatibility between browsers, and the solution that will annoy the fewest people is to keep the current cookie paths, and advise not to set up two Trac instances where the base URL of one is a prefix of the other. We should probably document that in the guide.

Documentation is recommended, i think.

Opinions?

What about this comment? I didn't test it yet. Would this be a possible workaround?

In general I am interested to know, if the behavior of Safari and Opera is correct. Didn't find any info regarding sending cookies multiple times (for slightly equal paths).

[Remy Blank]

Replying to j.beilicke@…:

What about this comment? I didn't test it yet. Would this be a possible workaround?

Interesting! I should have read #2438 more carefully. And indeed, ​RFC:2965 specifies:

If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific. Ordering with respect to other attributes (e.g., Domain) is unspecified.

So the first cookie is the right one. I'm going to try and come up with a proper implementation of this workaround (the suggestion in #2438 is rather ugly). Thanks for the heads-up.

[Remy Blank]

This is due to ​this issue in Python, for which a ​patch has been provided but not applied.

The following patch seems to fix the issue for me:

trac/web/api.py

@@ -159 +159 @@
     _strict_set = BaseCookie._BaseCookie__set
 
     def _loose_set(self, key, real_value, coded_value):
+        # If a key appears multiple times, the first occurrence has the
+        # narrowest scope, keep that
+        if key in self:
+            return
         try:
             self._strict_set(key, real_value, coded_value)
         except CookieError:

How does it work for you?

[Remy Blank]

Full patch including a unit test.

[buaa.byl <buaa.byl@…>]

Replying to rblank:

This is due to ​this issue in Python, for which a ​patch has been provided but not applied.

The following patch seems to fix the issue for me:

trac/web/api.py

@@ -159 +159 @@
     _strict_set = BaseCookie._BaseCookie__set
 
     def _loose_set(self, key, real_value, coded_value):
+        # If a key appears multiple times, the first occurrence has the
+        # narrowest scope, keep that
+        if key in self:
+            return
         try:
             self._strict_set(key, real_value, coded_value)
         except CookieError:

How does it work for you?

I will try, but I still have a question:Does opera/safari always send current project cookie first and then send the error cookie?

If I access this step:

1. test
2. test1
3. test

I expect browser will send cookie like that in orginal trac:

1. test:[cookie of test]
2. test1:[cookie of test1, cookie of test]
3. test:[cookie of test, cookie of test1]

If not so, I think this patch may not work fine.

I will check it later.

So at this point, I'm afraid it's an incompatibility between browsers, and the solution that will annoy the >fewest people is to keep the current cookie paths, and advise not to set up two Trac instances where the base >URL of one is a prefix of the other. We should probably document that in the guide. Opinions?

It is Ok.

[Christian Boos]

Patch applied on demo-0.13 and on this instance. It works great with Chrome (9.0.597.47), Firefox (3.6.13, 4.0b8), IE9beta, Opera (10.63, 11.0). It seems to work with Safari (5.0.3), although I initially had trouble to login in /demo-0.13, but after a restart of the browser I couldn't reproduce the problem anymore.

So it's a clear win, great work for narrowing down this issue from an "InstallationIssue" qualification on my part, to an elegant fix, Remy!

[buaa.byl <buaa.byl@…>]

Replying to rblank:

This is due to ​this issue in Python, for which a ​patch has been provided but not applied.

The following patch seems to fix the issue for me:

trac/web/api.py

@@ -159 +159 @@
     _strict_set = BaseCookie._BaseCookie__set
 
     def _loose_set(self, key, real_value, coded_value):
+        # If a key appears multiple times, the first occurrence has the
+        # narrowest scope, keep that
+        if key in self:
+            return
         try:
             self._strict_set(key, real_value, coded_value)
         except CookieError:

How does it work for you?

This patch work fine, but cookie is ugly. Also modify unexpect! See attachment. Thanks.

[buaa.byl <buaa.byl@…>]

after apply 9951-cookie-multiple-r10429.patch

[Remy Blank]

Replying to cboos:

So it's a clear win, great work for narrowing down this issue from an "InstallationIssue" qualification on my part, to an elegant fix, Remy!

Credit goes to valankar@… on comment:1:ticket:2438, I only implemented it cleanly.

Patch applied in [10430].

Replying to buaa.byl <buaa.byl@…>:

This patch work fine, but cookie is ugly. Also modify unexpect!

That's expected, both cookies are sent back for /test1. The patch ensures that the right one is selected.