Closed
Bug 220817
Opened 21 years ago
Closed 21 years ago
Add to FAQ: Why do I have to log in every time I access a page?
Categories
(Bugzilla :: Documentation, defect, P2)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.16
People
(Reporter: justdave, Assigned: goobix)
References
Details
(Whiteboard: [fixed in 2.16.6] [fixed in 2.18rc1])
Attachments
(1 file, 8 obsolete files)
5.88 KB,
patch
|
Details | Diff | Splinter Review |
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•21 years ago
|
||
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.
Reporter | ||
Comment 2•21 years ago
|
||
No, kiko, it's not. That's bug 220814.
Comment 3•21 years ago
|
||
Sorry, I'm trying to clean up on the crack.. but it's hard. :-(
Updated•21 years ago
|
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.18
Assignee | ||
Comment 5•21 years ago
|
||
Assignee | ||
Updated•21 years ago
|
Attachment #134575 -
Flags: review?(justdave)
Assignee | ||
Updated•21 years ago
|
Flags: approval?
Reporter | ||
Comment 6•21 years ago
|
||
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.
Attachment #134575 -
Flags: review?(jake)
Reporter | ||
Updated•21 years ago
|
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
Comment 7•21 years ago
|
||
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 /?)
Attachment #134575 -
Flags: review?(justdave)
Attachment #134575 -
Flags: review?(jake)
Attachment #134575 -
Flags: review-
Comment 8•21 years ago
|
||
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•21 years ago
|
||
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.
Reporter | ||
Comment 10•21 years ago
|
||
denying approval since the current patch has a negative review.
Flags: approval?
Assignee | ||
Comment 11•21 years ago
|
||
*** Bug 225750 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 12•21 years ago
|
||
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.
Reporter | ||
Comment 13•21 years ago
|
||
>(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.
Reporter | ||
Comment 14•21 years ago
|
||
>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. :)
Reporter | ||
Updated•21 years ago
|
Whiteboard: [wanted for 2.16.5] [wanted for 2.17.7]
Assignee | ||
Updated•21 years ago
|
Assignee: justdave → vlad
Assignee | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•21 years ago
|
Whiteboard: [wanted for 2.16.5] [wanted for 2.17.7] → [wanted for 2.16.6] [wanted for 2.18rc1]
Comment 15•21 years ago
|
||
Can we get this moving again?
Assignee | ||
Comment 16•21 years ago
|
||
Yeap, sorry for not following up on that, I'll try to do that soon :)
Reporter | ||
Updated•21 years ago
|
Flags: documentation2.16?
Flags: blocking2.18+
Flags: blocking2.16.6+
Assignee | ||
Comment 17•21 years ago
|
||
This applies cleanly again, but mainly it's the same as the previous one.
Attachment #134575 -
Attachment is obsolete: true
Assignee | ||
Comment 18•21 years ago
|
||
This one has the questions swapped and the first question points to the second one.
Attachment #145248 -
Attachment is obsolete: true
Assignee | ||
Comment 19•21 years ago
|
||
Attachment #145249 -
Attachment is obsolete: true
Reporter | ||
Updated•21 years ago
|
Flags: documentation2.16?
Assignee | ||
Comment 20•21 years ago
|
||
More close to what it should be.
Attachment #145250 -
Attachment is obsolete: true
Assignee | ||
Comment 21•21 years ago
|
||
Includes fixes for most of the review comments.
Attachment #145280 -
Attachment is obsolete: true
Assignee | ||
Comment 22•21 years ago
|
||
Oops, last time I uploaded v5 instead.
Attachment #145285 -
Attachment is obsolete: true
Assignee | ||
Comment 23•21 years ago
|
||
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.
Attachment #145286 -
Attachment is obsolete: true
Assignee | ||
Comment 24•21 years ago
|
||
Attachment #145287 -
Attachment is obsolete: true
Assignee | ||
Comment 25•21 years ago
|
||
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
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•21 years ago
|
Whiteboard: [wanted for 2.16.6] [wanted for 2.18rc1] → [fixed in 2.16.6] [fixed in 2.18rc1]
Assignee | ||
Comment 26•21 years ago
|
||
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•21 years ago
|
||
I had this problem with 2.16.5; changed the cookiepath to "/" and it went away.
Comment 28•20 years ago
|
||
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•20 years ago
|
||
(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.
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•