Bugzilla losing my login every page...forced to relogin...why?

[Mike Klein]

I am using Bugzilla 2.16.3 on a RH9 system. Additionally I have patched
bugzilla in standard way for graphing capabilities.

On most pages, other than showing bugs, each click to a different page
(like defining products or groups) forces me to re-login.

Logins are successful as I'm shown a logout link at the bottom of the
page...but 90% of any subsequent clicks cause me to relogin...

It doesn't seem to be a cookie blocking problem...I have no cookie
policies and can see cookies in my browser for bugzilla.

Why could this be happening?

thanks in advance,

mike

[David Miller]

Post by Mike Klein
I am using Bugzilla 2.16.3 on a RH9 system. Additionally I have patched
bugzilla in standard way for graphing capabilities.
On most pages, other than showing bugs, each click to a different page
(like defining products or groups) forces me to re-login.
Logins are successful as I'm shown a logout link at the bottom of the
page...but 90% of any subsequent clicks cause me to relogin...
It doesn't seem to be a cookie blocking problem...I have no cookie
policies and can see cookies in my browser for bugzilla.
Why could this be happening?

This will soon be a FAQ:



Q: Why do users have to log in every time they access a page? This only seems
to affect some of my Bugzilla's users, others stay logged in.

A: First, make sure the user has cookies enabled in their browser.

If that doesn't fix it, see if the user can find out whether their ISP uses a
rotating proxy server. That is, if every time they hit Bugzilla, they
appear to
be coming from a different IP address. The Bugzilla cookies are tied to a
specific IP address, so if their IP changes, they will have to log in again.

With newer versions of Bugzilla (2.17.1 and later) there is a parameter called
"loginnetmask", which you can use to set the number of bits of the user's IP
address to require to be matched when authenticating the cookies. If you set
this to something less than 32, then the user will be given a checkbox for
"Restrict this login to my IP address" on the login screen, which defaults to
checked. If they leave the box checked, Bugzilla will behave the same as
it did
before, requiring an exact match on their IP addres to remain logged in. If
they uncheck the box, then only the left side of their IP address (up to the
number of bits you specified in the parameter) has to match to remain
logged in.

================================

Q: Why do users have to log in every time they access a page? This affects
everyone who accesses my Bugzilla.

A: The most-likely cause is that the "cookiepath" parameter is not set
correctly
in the Bugzilla configuration. You can change this (if you're the admin) from
the editparams.cgi page via the web.

The value for the cookiepath parameter is the actual directory containing your
Bugzilla installation, ****as seen by the end-user's web browser****. Leading
and trailing slashes are mandatory. You can also put any directory which is a
parent of the Bugzilla directory for the cookiepath. But you can't put
something that isn't at least a partial match or it won't work. What
you're actually doing is restricting the end-user's browser to sending the
cookies back only to that directory.

How do I know if I want my specific Bugzilla directory or the whole site?

If you have more than one Bugzilla running on the server (some people do -
we do on landfill :) then you need to have the cookiepath restricted
enough so that the different Bugzillas don't confuse their cookies with one
another.
Examples:

urlbase is http://landfill.bugzilla.org/bugzilla-tip/
cookiepath is /bugzilla-tip/

urlbase is http://landfill.bugzilla.org/bugzilla-2.16-branch/
cookiepath is /bugzilla-2.16-branch/

On the other hand, if it's the only Bugzilla on the server, and you don't
mind having other applications on the same server with it being able to see
the cookies (you might be doing this on purpose if you have other things on
your site that share authentication with Bugzilla), then you'll want to
have the cookiepath set to "/", or to a sufficiently-high enough directory
that all of the involved apps can see the cookies.
Examples:
urlbase is http://bugzilla.mozilla.org/
cookiepath is /

urlbase is http://tools.mysite.tld/bugzilla/
but you have http://tools.mysite.tld/someotherapp/ which shares
authentication with your Bugzilla
cookiepath is /

If you have had cookiepath set to / at any point in the past and need to set it
to something more restrictive (i.e. /bugzilla/) then anyone who has already
accessed Bugzilla while the cookiepath was set to / will need to delete their
Bugzilla-related cookies in their browser before their logins will function
properly again.

[Jouni Heikniemi]

Post by David Miller
A: The most-likely cause is that the "cookiepath" parameter is not set
correctly in the Bugzilla configuration. You can change this (if you're
the admin) from the editparams.cgi page via the web.

This seems to be a pretty common issue. Could we add some logic to
editparams so that if cookiepath is not set, it would use something like
ENV{URL} (or SCRIPT_NAME or PATH_INFO) to propose the correct value (in
help text or right up in the field)?


Jouni

[Mike Klein]

Thanks for the quick response...I just figured my problem out myself
(right after posting of course). Yes it had to do with cookie path.

I have bugzilla in /usr/local/bugzilla, with a link under my docroot to
this directory (which has realm auth). Then setup an alias in apache to
point to link. Cookie was set to path of link rather than alias...yet
all of my pages launched bugzilla via alias...which wasn't what
cookiepath was set for...it was using the links path.

I'd made some 'minor' changes to web site structure a while back w/o
accessing bugzilla to see if anything broke. Indeed it had.


Thanks again...

mike

Post by David Miller

Post by Mike Klein
I am using Bugzilla 2.16.3 on a RH9 system. Additionally I have patched
bugzilla in standard way for graphing capabilities.
On most pages, other than showing bugs, each click to a different page
(like defining products or groups) forces me to re-login.
Logins are successful as I'm shown a logout link at the bottom of the
page...but 90% of any subsequent clicks cause me to relogin...
It doesn't seem to be a cookie blocking problem...I have no cookie
policies and can see cookies in my browser for bugzilla.
Why could this be happening?

Q: Why do users have to log in every time they access a page? This only seems
to affect some of my Bugzilla's users, others stay logged in.
A: First, make sure the user has cookies enabled in their browser.
If that doesn't fix it, see if the user can find out whether their ISP uses a
rotating proxy server. That is, if every time they hit Bugzilla, they
appear to
be coming from a different IP address. The Bugzilla cookies are tied to a
specific IP address, so if their IP changes, they will have to log in again.
With newer versions of Bugzilla (2.17.1 and later) there is a parameter called
"loginnetmask", which you can use to set the number of bits of the user's IP
address to require to be matched when authenticating the cookies. If you set
this to something less than 32, then the user will be given a checkbox for
"Restrict this login to my IP address" on the login screen, which defaults to
checked. If they leave the box checked, Bugzilla will behave the same as
it did
before, requiring an exact match on their IP addres to remain logged in. If
they uncheck the box, then only the left side of their IP address (up to the
number of bits you specified in the parameter) has to match to remain
logged in.
================================
Q: Why do users have to log in every time they access a page? This affects
everyone who accesses my Bugzilla.
A: The most-likely cause is that the "cookiepath" parameter is not set
correctly
in the Bugzilla configuration. You can change this (if you're the admin) from
the editparams.cgi page via the web.
The value for the cookiepath parameter is the actual directory containing your
Bugzilla installation, ****as seen by the end-user's web browser****. Leading
and trailing slashes are mandatory. You can also put any directory which is a
parent of the Bugzilla directory for the cookiepath. But you can't put
something that isn't at least a partial match or it won't work. What
you're actually doing is restricting the end-user's browser to sending the
cookies back only to that directory.
How do I know if I want my specific Bugzilla directory or the whole site?
If you have more than one Bugzilla running on the server (some people do -
we do on landfill :) then you need to have the cookiepath restricted
enough so that the different Bugzillas don't confuse their cookies with one
another.
urlbase is http://landfill.bugzilla.org/bugzilla-tip/
cookiepath is /bugzilla-tip/
urlbase is http://landfill.bugzilla.org/bugzilla-2.16-branch/
cookiepath is /bugzilla-2.16-branch/
On the other hand, if it's the only Bugzilla on the server, and you don't
mind having other applications on the same server with it being able to see
the cookies (you might be doing this on purpose if you have other things on
your site that share authentication with Bugzilla), then you'll want to
have the cookiepath set to "/", or to a sufficiently-high enough directory
that all of the involved apps can see the cookies.
urlbase is http://bugzilla.mozilla.org/
cookiepath is /
urlbase is http://tools.mysite.tld/bugzilla/
but you have http://tools.mysite.tld/someotherapp/ which shares
authentication with your Bugzilla
cookiepath is /
If you have had cookiepath set to / at any point in the past and need to set it
to something more restrictive (i.e. /bugzilla/) then anyone who has already
accessed Bugzilla while the cookiepath was set to / will need to delete their
Bugzilla-related cookies in their browser before their logins will function
properly again.