0

I've managed to set up a shared mod_perl Bugzilla environment using the PROJECT variable, and it works perfectly.

Now I'm trying to do the same thing on a different server, with the same basic setup, except that the hosts sharing Bugzilla are running SSL as well. That means they also have different, unique IP addresses.

Although this second setup basically works, I'm running into problems with login and cookies. Logins for the two Bugzillas interfere with each other, causing repeated login prompts and 'bad password' messages. Apparently this is fairly common with certain Bugzilla setups, but note that I do not have that problem with my original shared mod_perl Bugzilla (the one without SSL).

I believe Bugzilla defaults to sharing cookies, and that's presumably the root of the problem, and I've tried playing with both cookiepath and cookiedomain, with no success.

Has anyone out there cracked this problem?

Additional: I'm running Bugzilla 4.4.4. Bugzilla1 is bugs.domain1.com; its cookiedomain is '' and cookiepath is '/'. Bugzilla2 is bugs.domain2.com; its cookiedomain is '' and cookiepath is '/'.

Although normally when making changes to a Bugzilla/mod_perl setup I restart Apache to allow changes to kick in, my understanding is that this is not necessary when only the params files are changed (including changes to cookiedomain and cookiepath) (confirmed).

I tried setting the two cookiedomain values to 'bugs.domain1.com/' and 'bugs.domain2.com/', but that just resulted in no cookies being created at all.

I used LiveHTTPHeaders to watch what happens with the login-related Bugzilla cookies. As long as the two Bugzillas are working normally (no spurious login prompts), the cookies being passed around make sense. Before login, the Bugzilla_login_request_cookie is set with a unique value. After login, Bugzilla_login_request_cookie is effectively cleared, and two new cookies are set: Bugzilla_login and Bugzilla_logincookie. When one of the Bugzillas suddenly prompts for login again, although I see no change in the cookies being passed to the server in the GET header, the server returns this:

Set-Cookie: Bugzilla_login_request_cookie=<new value>; path=/; secure; HttpOnly

Something is making Bugzilla think the user is no longer logged in, and Bugzilla is responding by setting a new value for Bugzilla_login_request_cookie, which triggers the login process again.

Update: On the advice of a Bugzilla developer, I've reported this as a bug (#1005931) in the Bugzilla bug tracking system (Bugzilla).

  • 1
    If you turn off SSL on the new server, does it start working? If so, I suspect that you're accidentally creating some kind of cross-site "attack" that's being blocked. – bombcar Apr 30 '14 at 5:27
  • 1
    You need to provide more information about the domain names you are using, and their structure. (E.g. "Bugzilla 1 is foo.example.com and Bugzilla 2 is bar.example.com. My cookiepath is X and my cookiedomain is Y.) – Gervase Markham Apr 30 '14 at 10:42
  • 1
    Also, what Bugzilla version are you using? The release notes for 4.4.2 say: "The PROJECT environment variable is now correctly taken into account when mod_perl is enabled (this variable allows several installations to share the same codebase)." – Gervase Markham Apr 30 '14 at 10:43
  • 1
    Those blank cookiedomains look suspicious - can you try setting them to reflect the servername? My bugzilla cookies have a domain set (bugs.domain.com) - even though my cookiedomain is blank. Do your cookies correctly show the right domain? – bombcar May 1 '14 at 22:44
  • 1
    Another option would be to configure (on a test server) a dual shared-SSL setup using SNI and a single IP. – bombcar May 1 '14 at 22:49
0

From your additional reporting, this sounds like a bug in the new mechanism we added to prevent login-page XSRF. Please can you file it at https://bugzilla.mozilla.org/ ? Thanks :-)

There's only one place in the code this cookie is set - CGI.pm line 314 (on trunk). And it's only set if Bugzilla thinks there's no logged-in user. And, as you say, that should not be so.

Gerv

  • Interesting. But before I report this as a Bugzilla bug in the Mozilla Bugzilla Bugzilla, I'd like to make sure it's really a bug. Can you provide any additional insight into how I can test whether the new anti-XSRF mechanism is actually failing? – boot13 May 5 '14 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.