I've got two separate Bugzilla installations on one server. The first installation uses a cookie path of '/'. My second installation I set the cookie path more restrictively, to '/bugzilla_drydock'. Unfortunately, and has been noted here before (bug 121419), many browsers (including Mozilla 1.6a) seem to have a bad interaction with multiple cookies of the same name from the same host with differing paths. Short of being able to fix all browsers with this problem, it would be useful to be able to prepend the cookie names used by Bugzilla with a prefix from the 'edit parameters' page. This would allow the newer, separate installation of bugzilla to have unique cookie names, thus avoiding the problem with path resolution, no matter what rfc2109 says (see bug 165685).
IS this still an issue with a 2.17 version of bugzilla?
I don't know, sorry. I didn't see a suggestion on this topic in doing a bug search, though. I will investigate.
It appears that this is still an active concern in 2.17.4. Lots of places in 2.17.4 (relogin.cgi, createaccount.cgi, etc.) have hard-coded names for the 'Bugzilla_login' and the 'Bugzilla_logincookie' cookies. It would be useful to have these two strings be parameterized, if possible.
Note that Joel Peshkin recommends this approach in commentary for 165685.
Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa
I would rather see this as an option to trust the server's notion of the URL and utilize it as the cookie path. Our current setup does not allow the flexibility to configure access to Bugzilla like this: http://hostname1/bugzilla/installation and http://hostname2/installation even though both live in the same directory where hostname2 is a virtual host like bugzilla.companyname.com. The better way to do this (in this case) is to allow the server hand us the cookiepath and the same for the urlbase. I am not dealing with this bug at this time, however, I am interested in how this is handled.
BTW - the original bug creating the cookiepath parameter is bug 19910. I should also have said that I think it may be appropriate to name the cookie based on that path.
FYI all - it looks like the variables we want to refer to are HTTP_HOST and REQUEST_URI - both apparently are available in Apache and IIS. If a new environment comes along that we can't support without code updates, we could include support for it in a future release.
The cookiepath parameter allows you to restrict cookies to one specific path. If you have 2 installations, then you 2 distinct paths.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.