220817 - Add to FAQ: Why do I have to log in every time I access a page?

Status: RESOLVED FIXED

(Bugzilla :: Documentation, defect, P2)

Description

[Dave Miller [:justdave]]

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.

Comment 1

[Christian Reis]

If it's okay to overload this bug for adding another FAQ, let's add another of
Dave's most thorough answers (I'll leave the rewording of the question to the
bug assignee :-):

>   hi, I am using working on bugzilla database running
> under mysql,and i need to update the contents of
> databse via cvs. can anybody suggest how to do it.
> thanks.

1) make a backup of both your Bugzilla directory and the database.
   a) for the Bugzilla directory this is as easy as doing
      "cp -rp bugzilla bugzilla.bak"                     
   b) for the database, there's a number of options - see the MySQL docs
      and pick the one that fits you best (The easiest is to just make  
      a physical copy of the database on the disk, but you have to have
      the database server shut down to do that without dataloss)       
2) cd into your Bugzilla directory
3) cvs -q update -AdP     <-- if you want to update to the tip
   cvs -q update -dP -rTAGNAME    <-- if you want a specific version
     make sure to replace TAGNAME with BUGZILLA-2_16_3 or BUGZILLA-2_17_4
   If you've made no local changes, this should be very clean.  If you
   have made local changes, then watch the cvs output for C results...
   if you get any lines that start with a C it means there were conflicts
   between your local changes and what's in CVS.  You'll need to fix those
   manually before continuing.
4) ./checksetup.pl
   This will take care up updating the database for you as well as any
   other changes required for the new version to operate.

WARNING: Once you run checksetup.pl, the only way to go back is to restore
the backups.  You can't "downgrade" the system cleanly under most
circumstances.

Comment 2

[Dave Miller [:justdave]]

No, kiko, it's not.  That's bug 220814.

Comment 3

[Christian Reis]

Sorry, I'm trying to clean up on the crack.. but it's hard. :-(

Comment 4

[Vlad Dascalu]

--> FAQ writer

Comment 5

[Vlad Dascalu]

Attachment: XML Docs patch

Comment 6

[Dave Miller [:justdave]]

Comment on attachment 134575 [details] [diff] [review]
XML Docs patch

Jake: hope you're actually around this weekend :)

I need someone that knows docbook better than me to look at this one.

Sooner the better, 2.16.4 is holding on this.You got until 1pm Eastern on
Saturday Nov 1 to answer this review or I take it as-is and we'll let you clean
it up later.

Comment 7

[Christian Reis]

Comment on attachment 134575 [details] [diff] [review]
XML Docs patch

>+          <para>
>+            First, make sure the user has cookies enabled in their browser.
>+          </para>

in *his* browser.

>+          <para>
>+            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.
>+          </para>

I would rephrase this:

 If that doesn´t fix the problem, it may be that the user´s ISP implements a
 rotating proxy server. This causes the user´s effective IP address (the
address
 which the Bugzilla server perceives him coming from) to change periodically.
Since
 Bugzilla cookies are tied to a specific IP address, each time the effective
 address changes, the user will have to log in again.

>+          <para>
>+            With newer versions of Bugzilla (2.17.1 and later) there is a

s/With/In/

>+            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

We´re using "the user" and then move on to "they", we should be consistent.

s/they leave/he leaves/

>+            same as it did before, requiring an exact match on their IP address
>+            to remain logged in. If they uncheck the box, then only the left

s/they uncheck/he unchecks/

>+            side of their IP address (up to the number of bits you specified in

his IP address.

>+            the parameter) has to match to remain logged in.

I would omit the "to remain logged in".

>+          </para>
>+        </answer>  
>+      </qandaentry>

>+      <qandaentry>
>+        <question id="faq-phb-reloginEveryone">
>+          <para>
>+            Why do users have to log in every time they access a page? This
>+            affects everyone who accesses my Bugzilla.

I think this question should be placed *before* the previous one, but consider
that a nit as I can´t seem to word a justification. I guess it´s because it´s a
simpler explanation, and because it´s easier to rule out being wrong.

I also think that there should be a 

  (If this only affects some of your users, see the next FAQ item.)

here to point it ahead.

>+            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.

s/the admin/a Bugzilla administrator/

I don't think "via the web" is required in that sentence.

>+            The value for the cookiepath parameter is the actual directory

s/for/of/

s/is/should be/

>+            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

s/cookiepath/cookiepath, such as '/' (the root)/

>+          <para>
>+            How do you know if you want your specific Bugzilla directory or the
>+            whole site?
>+          </para>
>+          <para>
>+            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:
>+
>+            <blockquote>
>+              <literallayout>
>+        urlbase is <ulink url="http://landfill.bugzilla.org/bugzilla-tip/"/>
>+        cookiepath is /bugzilla-tip/
>+
>+        urlbase is <ulink url="http://landfill.bugzilla.org/bugzilla-2.16-branch/"/>
>+        cookiepath is /bugzilla-2.16-branch/
>+              </literallayout>
>+            </blockquote>
>+          </para>
>+          <para>
>+            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.
>+          </para>

This paragraph should come before the above one, IMHO. The reason is that
having multiple Bugzillas installed is something that is virtually restricted
to people testing or hacking Bugzilla, and even then it should be quite rare.
So it makes sense to show the more common option first.

>+          <para>
>+            If you have had cookiepath set to / at any point in the past and

s/have had/had/

>+            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.

Is there a bug open to fix this (since it is probably an easy fix)? If not, it
would be a good idea to open it, since this seems silly.

(Curiousity: what happens in the reverse case, btw, when you have a more
restrictive setup and then move to /?)

Comment 8

[Christian Reis]

Didn't see Dave's comment. I don't think I'll have time to do this myself (I'm
at a hospital!) so if we don't get the reviewed patch I can offer to fix this
next week.

Comment 9

[Jacob Steenhagen]

Overall the docbook part of it looks good. The one thing I would mention in that
there is an <example/> tag. For more information about it, you can see how it's
been used in installation.xml or administration.xml. That mostly falls as a nit,
however, as I'm sure I would accept it without that tag :)

And it looks like Christian gave a nice review of the content.

And FWIW, I wasn't around this weekend... have to be in Kalamzoo/Battle Creek
all weekend.

Comment 10

[Dave Miller [:justdave]]

denying approval since the current patch has a negative review.  

Comment 11

[Vlad Dascalu]

*** Bug 225750 has been marked as a duplicate of this bug. ***

Comment 12

[Dave Miller [:justdave]]

Comment on attachment 134575 [details] [diff] [review]
XML Docs patch

>In comment #7, Christian Reis wrote:
>
>>+          <para>
>>+            First, make sure the user has cookies enabled in their browser.
>>+          </para>
>
>in *his* browser.

His is a masculine pronoun.  We don't know that the person reading this is
male.  "His or her" sounds stupid.  "Their" is gender neutral, and rapidly
becoming accepted as a neutral third-person singular for that reason.

If we'd rather not deal with that issue, how about restructuring that something
like this:

First, make sure cookies are enabled in the user's browser.

>>+            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
>
>We´re using "the user" and then move on to "they", we should be consistent.
>
>s/they leave/he leaves/

See above.

"If the box is left checked"

>>+            same as it did before, requiring an exact match on their IP address
>>+            to remain logged in. If they uncheck the box, then only the left
>
>s/they uncheck/he unchecks/

ditto

requireing an exact match on the user's IP address

If the box is unchecked

>>+            side of their IP address (up to the number of bits you specified in
>
>his IP address.

ditto

only the left side of the user's IP address

>>+            Why do users have to log in every time they access a page? This
>>+            affects everyone who accesses my Bugzilla.
>
>I think this question should be placed *before* the previous one, but consider
>that a nit as I can´t seem to word a justification. I guess it´s because it´s a
>simpler explanation, and because it´s easier to rule out being wrong.
>
>I also think that there should be a 
>
>  (If this only affects some of your users, see the next FAQ item.)
>
>here to point it ahead.

Yeah, I agree on both points.  Let's swap them and add a pointer to the next
one.

>>+            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.
>
>I don't think "via the web" is required in that sentence.

Yes, it is.  You apparently haven't been paying attention in IRC often enough
to see all the people who've tried to open editparams.cgi in a text editor and
look for it when we leave out that part.

>>+            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
>
>s/cookiepath/cookiepath, such as '/' (the root)/

I think this also needs <strong></strong> (or whatever the equivalent docbook
tag is) to replace the ** around the emphasized phrase.  The ** is only useful
in ASCII text, it looks silly in markup where you have the capability to
actually visually emphasize it.

>>+            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.
>
>Is there a bug open to fix this (since it is probably an easy fix)? If not, it
>would be a good idea to open it, since this seems silly.

Yes, and it's already fixed in fact, too, which means this paragraph should
probably be re-worded.	Bug 165685 comment 5 has the best explanation of the
problem that I've seen, though it was actually fixed on bug 121419, which was
subsequently wiped out when we started using CGI.pm for cookies.  But CGI.pm
supposedly Does The Right Thing anyway.

Comment 13

[Dave Miller [:justdave]]

>(Curiousity: what happens in the reverse case, btw, when you have a more
>restrictive setup and then move to /?)

Then they would never be able to log out, and they'd be screwed if they changed
their password.  Bugzilla would use the most-specific one sent, which would be
the one with the full path, to log them in with.  It would then try to clear it
if they logged out by sending one with a path of / which wouldn't replace or
clear the more-specific one.

Comment 14

[Dave Miller [:justdave]]

>Yes, and it's already fixed in fact, too, which means this paragraph should
>probably be re-worded.

To clarify that, it's fixed on the trunk, but still broken in 2.16.x.  That's
probably a good candidate for backporting. :)

Comment 15

[Christian Reis]

Can we get this moving again?

Comment 16

[Vlad Dascalu]

Yeap, sorry for not following up on that, I'll try to do that soon :)

Comment 17

[Vlad Dascalu]

Attachment: Version 2

This applies cleanly again, but mainly it's the same as the previous one.

Comment 18

[Vlad Dascalu]

Attachment: Version 3

This one has the questions swapped and the first question points to the second
one.

Comment 19

[Vlad Dascalu]

Attachment: Version 4

Comment 20

[Vlad Dascalu]

Attachment: v5

More close to what it should be.

Comment 21

[Vlad Dascalu]

Attachment: v6

Includes fixes for most of the review comments.

Comment 22

[Vlad Dascalu]

Attachment: v6

Oops, last time I uploaded v5 instead.

Comment 23

[Vlad Dascalu]

Attachment: Version 7

I think I'll check in this one. I think I've accounted all suggestions. I've
possibly ignored some nits or accidentally forgot about them. However I've
reviewed the list of comments dozen of times and I think the patch is now ready
to hit the CVS.

Comment 24

[Vlad Dascalu]

Attachment: v8: Checked in

Comment 25

[Vlad Dascalu]

Checking in docs/xml/faq.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/faq.xml,v  <--  faq.xml
new revision: 1.26; previous revision: 1.25
done

Checking in faq.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/faq.xml,v  <--  faq.xml
new revision: 1.8.2.10; previous revision: 1.8.2.9
done

Comment 26

[Vlad Dascalu]

There have been some encoding issues that required post-checkin fixes. Basically
that was related to the ' character.

Checking in faq.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/faq.xml,v  <--  faq.xml
new revision: 1.27; previous revision: 1.26
done

Checking in faq.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/faq.xml,v  <--  faq.xml
new revision: 1.8.2.11; previous revision: 1.8.2.10
done

Comment 27

[j8a8m8i8e]

I had this problem with 2.16.5; changed the cookiepath to "/" and it went away.

Comment 28

[Bill Skellenger]

Using Bugzilla 2.17.6, installed on company intranet.

Did not have any problems at work referring to the site as "http://bugzilla/"
when accessing it with IE.  IE was configured to automatically append
"us.mycompany.com" if you enter "intranet" or "bugzilla" or something within the
company domain.

I started using Mozilla at work, which inherited my IE settings when it was
installed, including the setting above.  I can access Bugzilla by typing
"http://bugzilla/" within the intranet, but I had this login problem as noted in
this FAQ.

Cookiepath is set to "/" in my installation.

I found that in Mozilla, I have to explicitly use the URL:
"http://bugzilla.us.mycompany.com/" to access the site, and the problem goes
away.  With IE I do not have to do this.  Solution for me was simply to change
my Bugzilla bookmark so that I use the full URL when calling it from Mozilla.

Just FYI if someone sees this bug and has tried "everything"...  Maybe this will
help.

Comment 29

[Bill Skellenger]

(In reply to comment #28)

> I found that in Mozilla, I have to explicitly use the URL:
> "http://bugzilla.us.mycompany.com/" to access the site, and the problem goes
> away.  With IE I do not have to do this.  Solution for me was simply to change
> my Bugzilla bookmark so that I use the full URL when calling it from Mozilla.

Disregard the last comment.  The issue lies at least partially in the browser. 
After more investigation it doesn't seem to matter how I specify the URL.

IE does not have this problem with our Bugzilla installation (and around 25
users, all using IE).  After I installed Mozilla, I noticed this issue with
Mozilla only -- and only some of the time.

Bugzilla 2.17.6, Mozilla Firefox 0.9.3.