Closed Bug 47914 Opened 24 years ago Closed 23 years ago

buglist.cgi always has a not-logged-in page footer

Categories

(Bugzilla :: Bugzilla-General, defect, P2)

Product:
Bugzilla
Component:
Bugzilla-General
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 2.14

People

(Reporter: trudelle, Assigned: myk)

References

(
URL
)

Details

(Whiteboard: [nsbeta2-])

Attachments

(2 files)

hack that works around problem
575 bytes, patch
Details | Diff | Splinter Review
puts hack in buglist.cgi where it belongs
631 bytes, patch
Details | Diff | Splinter Review 
Using today's first M17 spin, I can't stay logged in to bugzilla.  I go to the
query page, see that I'm not logged in, log in, execute a query, and the result
page shows me as not logged in.  I can't even tell if my queries are being run
using my login.  This was also happening on the trunk, and on Friday's build.
putting on nsbeta2 radar, in case the problem is widespread.
Keywords: nsbeta2
Hmm, I'm seeing this on my trunk build too.  I'll investigate.
Just a test.  Ignore.
I am getting the identical behavior with 4.x so I must conclude that it is not a
cookie problem or even a browser problem but rather a bugzilla problem.  Here is
the test that I ran (with both browsers).

1. exit browser
2. remove cookies.txt file
3. reenter browser
4. go to bugzilla.mozilla.org
5. go to query page
6. observe that the last thing on the bottom line says "log in"
7. click on log-in and enter username and password
8. observer that bottom line now says "log out morse@netscape.com"
9. submit a query
10. observe that last thing on the bottom line again says "log in"

Step 10 is bad -- I would have expected it to still say "log out ..."

11. click on any item in the query list
12. bug report is displayed
13. observe that last thing on bottom line says "log out morse@netscape.com"

So it looks like we are logged in again!!!!

Since this is happening with 4.x, I'm marking this as invalid.  Reopen if you
disagree.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
I'll pipe up, today's m18 build tells me that my session has expired after i've
logged in to mail.com, my.yahoo.com... if this bug gets through, then for
whatever reason, bugzilla's login cookie survived.
So, bugzilla *did* ask me for password before committing my last change to this
bug... at least bugzilla lets us get work done when our cookies aren't remembered =)

Can you reopen and try some more sites that rely on cookies?
note also that i don't experience the same inconsistencies, or problems at all
when using 4.x
this should get migrated to bugscape... not having this problem in the mozilla
trunk bits.
I saw it on N6 M18 builds, others have seen it on 4.x too, so I now think it is
a bugzilla problem.  I don't see how that makes it invalid though, it is just a
bugzilla bug.
I marked it invalid because I assumed that it was the server that was 
misbehaving and not the browser.  I concluded this by the fact that (1) I was 
getting identical results on 4.x as I was getting on seamonkey and (2) it 
flipped from logged to not-logged and back to logged without my having done any 
logging in or out.

Leaf's comments sound like something entirely different.  He is talking about 
mail.com and my.yahoo.com.  If there's a problem there I suggest opening a new 
bug report on it and giving detailed set of steps for demonstrating the failure 
(as I have done in this report).

By the way, I'm using the mozilla trunk build, not the commercial one.
Why do I need to file another bug?  I'm still seeing the problem originally
described, on N6 only. You're only using Mozilla?  How can you close a bug as
invalid without testing the problem on the product I've reported it against?
Reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I've tested it on mozilla and I saw the problem.  So why do I have to test it 
on commercial as well -- I believe you that it is happening there too.  But I've 
also tested it on  4.x and saw the same problem, exactly as you described.  
That's why I concluded that the problem is on the server side and not the 
client side.

Let me be clear as to what the symptoms described in this report are.  The 
indication on the bottom of the screen as to whether you are logged in or not 
appear to be incorrect.  In fact, it flips from one to the other.  But there is 
no problem reported in doing things that require you to be logged in (such as 
filing bug reports).  At least not as far as what is mentioned in the 
description of this report.

There may indeed be a problem involved with doing things that require a log-in, 
as mentioned by some of Leaf's comments further down.  But Leaf has now opened a 
bugscape report on that, namely 1915.

And in your comment above you agreed that this is a server-side problem (a 
bugzilla problem you called it) rather than a client-side one.  Well then 
certainly it's invalid as a bug report agains the browser.  That's why I closed 
it as invalid.  I don't even know what the mechanism is for reporting problems 
with bugzilla, but it's certainly not here.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → INVALID
Component: Cookies → Bugzilla
Product: Browser → Webtools
Product -> Webtools, Component -> Bugzilla. That's how its done. Reopening. 
This is a real problem, not an invalid bug report.
BTW, it isn't just the 'log in' text, I don't get the correct default query
either, and have to repeatedly log in to use bugzilla.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
cc rko in case it is just a server problem.
Reassigning to owner of bugzilla component.
Assignee: morse → tara
Status: REOPENED → NEW
QA Contact: tever → matty
I don't really see this anything to do with the server itself. Only possible 
theory would be if lounge's (where bugzilla server is) clock would be totally 
wrong (ie. cookie times would be wrong etc). But the clock seems to be still 
synced well.
This is still occuring today.  Does not occur with Bugscape, Buzilla specific.

Can we get this fixed ASAP please?  I get lots of mail with folks not thinking 
they are logged in when indeed they are...thanks!

Putting on dogfood radar...it is affecting my daily work...too much mail :-)
Severity: major → critical
Priority: P3 → P1
Whiteboard: [dogfood+][nsbeta2-]
If the problem is only manifesting itself in *trunk* builds of commercial, then
i'd be willing to bet that this is a dupe of the problem i filed in bugscape
(which is where commercial build bugs should be filed to begin with).

I really doubt this is a bugzilla issue, because using mozilla builds or 4.x
builds doesn't give me this behaviour.
Doesn't for me either, but other's mileage varies.
Leaf, let me clarify.  The bug reported here (incorrect display of the login 
state) is occuring on mozilla.  And it is occuring on 4.x.
This may be a duplicate of bug 20122. I can never stay logged in because my
requests virtually always come from a different proxy, due to the way requests
are forwarded from one proxy cache to another. So it doesn't depend on your
browser, but on how your local network operates.
I'm not using any proxies.
Just to clarify again, the bug that leaf described above (with mail.com and 
my.yahoo.com) has been split out into a bugscape bug because it was originally 
thought to be occuring on commercial tree only.  It has since been determined to 
be occuring on mozilla tree as well.  So that bug has been moved back to 
bugzilla -- it is bug 46989.

This bug report should not focus on those issues.  It should focus only on the 
fact that the login/logout indicator at the bottom of the bugzilla page does not 
reflect reality.
Summary: Cannot stay logged in to bugzilla → Login/Logout indicator at bottom of bugzilla screen is wrong
As I said above, it isn't just the login text. When this happens, I also get the
generic query page, rather than my login default.  I think my original summary
is more appropriate. If you are seeing the wrong text when you are really logged
in, that should be reported in a separate bug report.
Summary: Login/Logout indicator at bottom of bugzilla screen is wrong → Cannot stay logged in to Bugzilla
You may think you're not using proxies, but they may have transparent proxies at
your network. If the problem appeared unexpectedly one day, your local network
configuration may have changed, so ask your NOC for information.

The reason I insist is that all symptoms described above are perfectly explained
by bug 20122. In order to validate you, Bugzilla checks your emailaddr,
password, *and* hostname. Your web cache (http proxy) may be forwarding the
request to a level-2 cache of its choice. If you have two level-2 caches, the
level-1 cache does not necessarily forward all requests to the same level-2
cache, in which case Bugzilla will see the requests coming from a different
host. The same thing may happen with transparent proxies, even if there is only
one level of caches.

This can result in alternation between logged-in and logged-out; or in some
tests succeeding and some failing, tricking you into thinking that it's thus on
one browser and otherwise on another, whereas it's a matter of chance; or in the
text of the page indicating you are not logged in, and your subsequent request
being granted as if you were logged in, because that request went through a
different cache.

See bug 20122 and its duplicates for more information.
I don't understand how or where a proxy could possibly be involved.  I've never
even heard of a transparent proxy, so I'll have to look up how that works.  One
thought though - if bugzilla uses an id/passwd/host tuple, does that provide for
concurrent access from multiple hosts?  I have 3 machines that I use regularly
to overlap requests, could that be the problem?  Is it logging me out on one
host just because I submit a request from another?  I'm pretty sure I have had
failure cases that didn't involve this scenario, but I'll double-check.
Transparent proxy is a proxy that captures all WWW traffic and gets data back to 
you through proxy and masquarades as the target host. It's a nice way to have a 
proxy service without having each user to configure their clients.

We don't have a transparent proxy @Netscape.
*** Bug 48595 has been marked as a duplicate of this bug. ***
trudelle, I did not see this happen all day 8/14.  Is it looking ok for you this 
week?
Haven't seen it in the past 2 days.
Just to pipe in a comment.  We've seen this periodically over in our neck of the 
woods, but never in a reproducible enough case to be able to track it down, and 
certainly not often enough to get too excited about it.  Downgrading for now 
unless I get more info or sudden insight.
Status: NEW → ASSIGNED
Priority: P1 → P2
Why is this a dogfood+ bug?  Removing the designation so this can be 
reconsidered.
Whiteboard: [dogfood+][nsbeta2-] → [nsbeta2-]
It was dogfood for me when I reported it, but I agree that it has been very
sparse since then, and no longer qualifies.
I've seen this a few times.  I will be logged in and changing bugs. Then it will
appear that I am not really logged in because the bottom bar that contains your
saved queries will not show mine.  When I go to change a bug though I will still
be logged in.

*** Bug 65424 has been marked as a duplicate of this bug. ***
I filed bug 65424, and it seams to be the same as this one, although I find
the comments here a bit confusing. The comment from morse at 2000-08-07
describes what I'm seeing: the script buglist.cgi always shows the not-logged-
in page footer, while the other scripts work as expected. That's not a big
problem, since you are still logged in. You only don't have your custom
queries handy on that page.

Changing summary to make this clearer IMHO.
OS: Windows 98 → All
Hardware: PC → All
Summary: Cannot stay logged in to Bugzilla → buglist.cgi always has a not-logged-in page footer
As I stated in bug 65424, I'm unable to duplicate this.  I dug through the source 
for buglist.cgi last night, and I can't find anything that would trash the 
Bugzilla_login cookie before the Footer routine got called...  so I'm at a loss.  
(Since PutFooter() calls quietly_check_login(), the only way I can think of that 
would happen is if the Bugzilla_login cookie somehow disappeared (out of 
Bugzilla's memory, not out of your browser's) by the time it got that far down 
the page.

I can't believe that the cookie gets trashed here, because I'm still logged
in, I only don't get the footer which tells me so from buglist.cgi. But when
I click on any bug in the bug list, I get the right footer again, without
any need to re-login. There must be something different in the footer generation
in buglist.cgi compared to the other scripts.
it's not getting trashed in your browser.  As you noted, you're still logged in 
when you view a bug.  Remember that HTTP is stateless...  everything about your 
current state of things (including whether you're logged in or not) has to be 
told to Bugzilla again every time you click on something.  So what's most likely 
happening is that Bugzilla is forgetting your login cookie sometime between when 
it starts generating the buglist, and when it gets down to the footer.

Can you make this happen on any other Bugzilla installations besides b.m.o?  
b.m.o hasn't updated to cvs in a couple months...  the code I just stepped 
through is the current cvs code.

If we could reproduce this we could likely fix it very quickly.  So what's
different about some people that causes them to get this problem?
Seems to work on long bug lists.

Can we have a (reduced if possible) URL that exhibits the problem reproducably
for you?  When you say "always", I don't know what sort of queries you always
do.
If you don't get this bug, log out of Bugzilla and log in again. At least I had
to do that this time. (*)
I logged in from a different IP, and went back to the old IP a few days later
without logging in again, and then the footer was okay. I logged out and in
again, and the bug was back.

I have added the sample URL from bug 65424 to this bug. This is an easy way to
reproduce this behaviour.

I do lots of different queries, some from query.cgi, some from remembered
queries in the page footer (see bug 65424), some from bookmarked queries. As
far as I can remember, they all result in the wrong footer. That's why I said
"always".

(*) In case that matters: I always log in by going to the bookmarked URL
http://bugzilla.mozilla.org/showvotes.cgi?Bugzilla_login=MY@EMAIL&Bugzilla_password=MYPASSWORD
with the correct login/password values substituted. If you're curious about why,
see bug 20122 and my comment there at 2000-06-15. I got used to that bug, but
it's still there. :-(
URL: http://bugzilla.mozilla.org/buglist.c...
Interesting enough, I can't reproduce this with my local Bugzilla installation,
I only get this at bugzilla.mozilla.org. Maybe it's already fixed and b.m.o
should only upgrade?

What cvs commands do I need to checkout the code bugzilla.mozilla.org is using
right now?
This problem is the result of data corruption in the "logincookies" table of the
Bugzilla shadow database, which causes buglist.cgi not to be able to find users'
login cookies.  Since buglist.cgi is the only Bugzilla script that uses the
shadow database, it is the only script subject to this problem.

The hack I just attached patches &PutFooter to always use the regular database
rather than the shadow database.  Perhaps it isn't such a hack after all, since
there is no reason why buglist.cgi should run login cookie queries through the
shadow database just because it runs bug queries through it.


DUDE!  You rock, Myk.  This is a huge annoyance on b.m.o.  The fact that we have 
a working patch gets this past the 2.14 cut in my book :-)
Assignee: tara → myk
Status: ASSIGNED → NEW
Keywords: patch, review
Target Milestone: --- → Bugzilla 2.14
r= justdave

This has been checked in.

Due to the large number of carbon copies on this bug, I feel the need for the 
obligatory notice that this bug is being marked FIXED because the patch has been 
checked into the Bugzilla source repository, and new updates of bugzilla will 
include this.  bugzilla.mozilla.org does not automatically run the tip code.  
Although they are close to the tip, they do manual updates, and this fix will not 
be apparent on bugzilla.mozilla.org until after they next update to the tip.

You can check when bugzilla.mozilla.org last updated by clicking this URL:
<http://bugzilla.mozilla.org/cvs-update.log>.  Please DO NOT reopen this bug 
unless bugzilla.mozilla.org has updated at a later date than the date of this 
comment.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
FYI, since the fix that was checked in here only works around the real problem, 
bug 87006 has been opened to address the underlying shadow database corruption.

Since I have never reproduced this problem, I think the only appropriate
verification method is waiting for a couple of months and seeing whether anyone
can reproduce it.
*** Bug 90859 has been marked as a duplicate of this bug. ***
*** Bug 91457 has been marked as a duplicate of this bug. ***
Moving to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: