Apache OpenOffice (AOO) Bugzilla – Issue 7859
login cookie expiration far too soon
Last modified: 2003-12-06 14:52:32 UTC
Every morning I process my bug reports, and have to re-login, via the stored password in my browser. This typically wastes half a minute, cutting and pasting bug texts etc. logging in, going to the bug again pasting back etc. Very tedious, and a common problem by all accounts; Why is this expiration in-place ? no other bugzilla site I'm aware of bothers with this, it wastes valuable developer resources, and adds no security over the 'logout' button. Also; why would anyone in their right mind want to file malicious bulk bug reports ;-) and how trivial would it be to prune them, were this ever to happen ? Looks like an over-design decision; can it be reversed ? Thanks.
This issue is very similar to Issue 7069, although it does not request a permanent cookie, and suggests need for a slightly longer cookie expiration. Issue 2148 shows work regarding future plans of the login, but not the cookies.
Login in all Bugzilla variant applies to the session. However, the option of a permanent cookie would be useful, but that should probably be filed in the Bugzilla product at mozilla.org.
Sigh; I think you're confused; there is some evil timeout happening, that is extremely short. Contrast this with my years of use of Gnome bugzilla; where one has to re-authenticate (typically) only on upgrading the browser / changing machine - which is immensely superior. I think you're missing something; please don't make me go read the bugzilla source.
hi, Michael I too have noted inconsistent timeout. It's supposed to be for 8 hours. If you use more than one browser while working, however, that may affect things (or if your browser crashes, is quit, etc). However, I think there is an issue here. Reassigning to support for investigation. thanks louis
Action Plan: 1) File internal issue (PCN) to have ops check the timeout values of the cookie 2) update this IZ when I've received an update from ops. PCN 13048 filed, step 1 complete timeframe: I will update this issue by 11/20/02
Question for reporter: 1. when you start your morning work, are you logging in to OOo first then updating your IZs, or using an open browser from the previous day's work? 2. How long does the session appear to last? Thanks
I use the same browser - logged into the same OpenOffice.org that I was using an hour or so ago; and/or I re-start the browser ( who knows, I have a lot of browser windows open typically ), and it demands re-authentication. This contrasts with the (somewhat-unmaintained, but contrasting suprisingly usable) gnome bugzilla that stores a semi-permamant authentication cookie in my browser - making my life extremely easy. Why _Why_ do we need a session cookie, instead of a more permanant one ? and why do we need to timeout expire anything ? As for timing it precisely - I only know it irritated me intensely when I was filing 3-4 bugs a day; which I am now not doing, since each time I had to authenticate.
Using Mozilla on Linux and IE on win2K I could not reproduce this timeout in IZ. The only time I got a timeout was after I left my browser up overnight and tried to enter a test bug in the morning. The 8 hour timeout was expected though. Once I logged on in the morning I had no problems. An engineer using the OOo site as well as a staging site experienced similar results. Resolving this issue as worksforme.
"The 8 hour timeout was expected though" - worksforme == the problem, why do we have an 8 hour timeout at all ? This length of time seems ideally suited for not giving any 'security', and also frustrating the user. Why have a timeout at all ? - or one that is of the order of months. Why is it reasonable to want people to continually log-in ? 8 hours is far too soon.
8 hours is the default cookie timeout session in the SourceCast software and configured in the settings used by Sun. Your other questions would best be answered by the Sun team leads and I'd suggest following up with them. I'm not trying to belittle your frustrations with the software, but there's no reproducable error here from our end. We'd suggest logging on to the system in the morning, then using IZ afterwards. It may not be what you wanted to hear, but it's the way around this.
reopened to investigate reasons for timeout
reassigned to mh, followup internal discussion
Kenneth, could you explain to us, what extending the timeout to, let's say 240 hours, means? We are looking for a compromise between convenience and performace/security. Which resources are bound to a session? Thanks, Stefan
adding david
reassigning to support
I have this problem with HUGE problems. Here is a typical bug session for me. login, click my issues, enter new bug id, notice login on left has reappeared, update, get error, login, click login twice (yep, first time does not work). click, back until I can update issue, fails again, login, click back, finally updates. NOte that I use galeon browser with tight security regarding cookies, mozilla which has lighter security settings is not quite as bad. There was a note on one list regarding the fact there was a bugzilla upgrade that helped this situation though. Sounded like a knowledgeable response.
First off, the session cookie is a cookie for the sourcecast application, IssueZilla being just one component within SC. It does not matter what tool you use within the SC web interface. Second, the cookie lasts for 8 hours of _inactivity_. It starts accumulating time towards the timeout when the last action took place in the session. If this seems not to be the case, pleas The reason that a timeout of 8 hours is necessary is two-fold. One reason has to do with security. It is a risk to leave an open session that has greater permissions than default/guest for many days given the user has access to all the sourcecast tools with these permissions. The second reason has to do with resources. Every session takes up resources (memory, etc) in the jvm, even when idle. Given there are over 80,000 users, it is highly impractical to allow idle sessions to last 240 hours in duration. Additionally, it is plainly obvious for a user to validate whether or not they are logged in by glancing at the left navbar and taking notice of whether the "login" option is available. If it is listed, you are not logged in. Given browsers ability to cache login information (user/passwd), it is only two clicks (one on the "login" link, another on the "login button") to re-instanciate a session. Is that really so onerous? If so, entering a bug must be a herculean task. ;)
hi thanks, brian, for your commentary. I had a long discussion on this issue with one of the CN engineers, and we tested various browsers simultaneously, to see how the cookies, so to speak, crumbled. I think that one element that could cause issues (perceived) is that many pages are staticized, including the homepage. This means that one cannot, in fact, always rely on the left navbar to indicate whether one is logged in or not. but your points are correct and I agree with them. We initially settled on 8 hours b/c it was a compromise--the initial desire was for a week or so. Given the number of people using OOo daily, I think we have to be wise in our usage. The CN engineer did speculate further that the JVM might boot people who had been inactive longest if there was heavy demand. Would you know if this is the case? thanks, Louis
This is not a cookie expiry problem, I can be just logged in and it will die on me. I fully expect for this update to fail. I logged in at 17:22 is is now 17:23. My average working OOo day is only 3-4 hours yet I get this issue repeatedly.
I have now clicked on a mailnote link (issues@OOo) and I have a totally separate tab from the original one. This will typically fail to work. Since I am testing this feature I bet it does now (local time 17:26)
Ken - if your issue is not a cookie expiry problem, please open another issue as that is what we are discussing here.
Update: Awaiting a response from Stefan on my reply to his query regarding timeout extension and its concomitant effects. I have replied to Louis' question in the internal issue as it is a more conducive arena to deal with that type of question. I will post the results of that conversation when there is a conclusive answer. Action Plan: Wait for a response. Timeframe: Update timeframe provided upon response.
Hi Brian, You say: > The second reason has to do with resources. Every > session takes up resources (memory, etc) in the jvm, even when idle. What resources are you tracking ? and why ? and why are they stored in memory, instead of more persistantly ? and why can a trivial ticket / auth cookie not be stored on the client - where the resource is no problem. > Given there are over 80,000 users, it is highly impractical to allow > idle sessions to last 240 hours in duration. How is that Gnome has myriad bugzilla accounts, and yet never has this problem ? it seems to me there is no necessity for this to be stored server-side by any means. I can't quite imagine what state you're trying to store; what is it ? > If it is listed, you are not logged in. Given browsers ability to > cache login information (user/passwd), it is only two clicks (one > on the "login" link, another on the "login button") to > re-instanciate a session. Is that really so onerous? Yes - this is a _royal_ pain in the backside. Also, there is the acute frustration of total impotence, inasmuch that it seems unfixable. Furthermore, although you can't reproduce this - there is somewhere a bug with this authentication, such that people have to authenticate more frequently than your 8 hour period. It may seem to be a small thing to you to spend 10 seconds per bug report you filed doing totally pointless, wasteful administration, but you're wasting ~10 * <nbugs-filed> seconds in total, which with this '80,000' users the numbers start to look really bad. > If so, entering a bug must be a herculean task. ;) Bugzilla is designed to be fast and easy to use; IssueZilla OTOH seems not to be. As for the 'security' argument, that's just an incredibly feeble excuse for an architectural problem IMHO. I hope that's not too hard - but this really annoys me, repeatedly and persistantly. And seemingly - not just me.
We have answered Stefan's question regarding the impact of increasing the timeout duration and have not heard a response from him. If a longer timeout than 8 hours is desired by the Sun team, they will need to make that request explicitly themselves. And Mike, if you would like a longer timeout duration, you need to make your case to the Sun contacts, not collab directly. The problem of session timeout prior to 8 hours of inactivity is not reproducable, so there is little we can do correct it. timeframe: Respond after Stefan or Martin has weighed in.
we will stick with the 8 hours timeout and i close this bug. But there seem to be other problems with the cookie I will report in a new one.
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details. First step in IssueZilla is unfortunately to set them to verified.
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.