Bugzilla should have a configurable cookie prefix

RESOLVED WONTFIX

Status

()

Bugzilla
Bugzilla-General
--
enhancement
RESOLVED WONTFIX
15 years ago
4 years ago

People

(Reporter: Jonathan Abbey, Unassigned)

Tracking

Details

(Reporter)

Description

15 years ago
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?
(Reporter)

Comment 2

15 years ago
I don't know, sorry.  I didn't see a suggestion on this topic in doing a bug
search, though.

I will investigate.
(Reporter)

Comment 3

15 years ago
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.
(Reporter)

Comment 4

15 years ago
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

Comment 6

13 years ago
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.

Comment 7

13 years ago
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.

Comment 8

13 years ago
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.

Updated

6 years ago
Severity: normal → enhancement
OS: Linux → All
Hardware: x86 → All

Comment 9

4 years ago
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.