This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I'm using Mozilla 0.9.2 as my WebBrowser before migration our bugtracking system I used to have opened more webrowser's windows to work over the Issuzilla. I had 2 or more browser's windows(instances or processes) for displaying different queries, 1 or more windows for work with bugs, etc. But I had to log only once to the Issuzilla, I can say " I didn't need to log 'cause I was permanently loged in" But now, for each instance of webrowser(I mean new window open from current one )I had to login (The same is valid for another window wich was started as separeted proccess.) It's quite annoying to log in with each browser's window.
Also at least a few days ago it was true that you had to log into each subsite (editor.netbeans.org, form.netbeans.org) separately in order to use IssueZilla (meaning only which host was found in the URL you accessed IZ with; the category of the issue not relevant). Perhaps this has been fixed since though. Also a few days ago bug messages were given with links of the form http://netbeans.org/..... which you could not log into at all! (you had to use www.netbeans.org etc.) though this seems to have been since fixed.
Now I foccused on it more deeply and here're more observations: This problem as valid (probably) only for extra browser proccesses- seems like they don't shared cookies between them. (Not true for new session=>new window from current one) But it is still annoying because of .... I don't mind to login in each browser window/proccess, but "login" move me to unwanted URL from which I must difficulty go back. Example: From Email client I jump to Issue link to modify that issue. But I must login which move me to http://www.netbeans.org/servlets/TLogin and going back to the issue link is difficulty. Eg. I must click on BUG link and enter issue number by hand to the filed to get to thi intendent url link(issue). Another Example: From extra browser proccess I go to query page. I need to modify some bugs from the result, but again I moved to the unwonted url, from which I must somehow do this guery again,...etc...
This issue has been entered as sc-support107, pcn4889
Assigning to support.
accepting for support
Moving this to P3 per conversation with Michael Boyer.
I am increasing priority of this bug, because it is realy annoying problem when I have to log in more than 15 times/day. Consequences when I am not logged in (and I do not know about that) are folloving: - new issues are submited as from guest@netbeans.org, I have no feedback and I do not know about it - when I have writen for example long comment to some issue and I am commiting it, I have to login and everything is lost - at least 3 pages must be loaded before execution of any predefined query instead of only 1 page with results and offten is server response so slow, that it is almost impossible to pass out the sequence of login,loged,query and result pages
This is believed to be a short timeout issue, which is in the queue of the engineering support person, but behind issue 13665. Daniel, if you would like to raise the priority of this issue, please speak with Michael Boyer so that he can discuss it with us this evening.
*** Issue 13755 has been marked as a duplicate of this issue. ***
Well, in case the SourceCast system is architected well, this issue already should have been resolved, fixed and verified for at least two weeks! What's happening with this issue? Why it's taking so long time? In well architected systems this is up to *one* minute configuration task!
Rudolf be reasonable. Your comment here is uncalled for and of no benefiet to anyone - there's no additional info relevant to the bug; Is this the kind of comment you would like to see from a user filing a bug for the IDE ? It's a P2 issue, which means Collab are well aware of our estimate of it's priority, and are working on it as such.
A longer timeout is in testing on the staging server.
The login timeout has been increased to 8 hours. Significant load testing has been carried out over the past day to insure performance. Memory usage should not be significantly affected. Performance monitoring will be increased over the next few days to make sure that there are no negative effects resulting from this change.
Appears to be fixed.
Verified.
It seems that login timeout is solved:-), but What's about the page you're moved to after you press LOGIN button? Eg. from mail I click to link with bug to witch I want to make some commnet, but I had to login, and then I moved to UNWANTED PAGE instead to stay on the URL I'm on before login Because of that reason above I'm reopening this issue. If you don't feel that this is not realted to login problem, pls let me know and I fire another bug. thanks, Daniel
I agree, there is no change for me after this fix. Before I could enter this comment, I had to login again. Sollution may be in cooperation with Password Manager (inside Explorer or Mozilla) or set the login cookie as permanent. There was not this problem with previous Issuezilla and Bugzilla.
Thanks Adam for your comment. You expressed what I missed:-)
The izzue that you do not go back to the original page after logging in, is documented in IZ 13568 (as well as this one). We've used this one for the time out, and 13568 to discuss where the user should be after login. Please add any relevant comments to 13568
OK. I'm going to attach last to comments to te mentioned bug. thanks, and verifiing it as it was ('cause the time out works:-)
I think that the root of problem is that Mozilla and IE password managers are not supported. It was not addressed yet.
Adding last comment to 13568 and closing this issue.
Marking issue as resolved.
8 hours is valid only if I don't close the web browser (Netscape Navigator 4.74). Sometimes I need to restart browser (all instances) and browser don't remember my login and displays login/password fields.
or simply browser crashs.And that is not very rare phenomenon:-(
This is true (that restarting the browser means you need to log in again), and it is a working as designed issue (the vast majority of our customers want it this way). The way I would deal with this, to make everyone happy, would be to provide settings which domain admins could change, allowing them to choose the lengh or existence of a login timeout for the site and whether or not restarting the browser would log someone out. You are welcome to open an enhancement request along these lines. Please note: This would be a _very_ significant enhancement (not a minor change).
Additional note: Mozilla or modern versions of IE allow you to save login information. This would be an alternative option.
As Taska suggested to fill an enhancement....I'm doing it now... After a short speech with Mike Boyer we settled on to reopen this issue and mark it as ENHANCMENT with P4 priority rather then to write the new one and copy into it all those information from this bug. ---------------------------------------------------------------------- SO THE REQUIREMENT IS: just turn back the behaviour of login process and login timeout of IZ as it behaved in previous version of IZ or Bugzilla or what was it. SIMPLY: BROWSER SHOULD STORE SOME KINDA COOKIES, THAT IT WILL FACE OUT RESTART OF BROWSER (OR EVENT RESTART OF COMPUTER:-) probaly depends on setting of browser's history ----------------------------------------------------------------------
I entered a new enhancement request for this, including both my take and Daniel's take on the issue (PCN6007), and put it in product management's queue.
Just another voice--I would also very very much like to have the login cookie be stored as a permanent, not session, cookie. Browsers crash all the time. My browser shuts itself down sometimes when I try to queue up too many offline mails (don't ask). It's the browser's fault of course, but the reality is that in the former BugZilla installation I could log in once and be all set for a couple of weeks, and now I find myself logging in to the site at least five times a day, and it is annoying. An 8-hour timeout is OK with me (would prefer something longer but this is a performance issue); the main problem is the session vs. persistent cookie. So if this were somehow configurable by a domain admin it would be perfect--or even a parameter that could be tuned at SC installation time, with no admin GUI if that is difficult to write. Assuming you are simply keeping the login information with a Set-Cookie header (used as an index to a servlet session ID I guess?), this should only be a matter of adding persistence info to that cookie according to the spec, if I remember my CGI programming days well.
*** Issue 16322 has been marked as a duplicate of this issue. ***
*** Issue 17187 has been marked as a duplicate of this issue. ***
*** Issue 18083 has been marked as a duplicate of this issue. ***
*** Issue 24961 has been marked as a duplicate of this issue. ***
Not sure what has happend to this one; no real development in over 8mths, and a steady stream of duplicates indicates this is a real problem for many people. Upping priority.
I have requested an update on this issue internally. At the moment we do not store persistent cookies, which would be required to accomplish this. The ramifications of doing so are under consideration, but no conclusions have been reached.
I spoke with an engineer on this, and he sees the ramification that if many users share the same machine there will be cookie clashing. To minimize this, we have plans to implement a user preference that indicates whether to persist the cookie by asking whether the machine you are using is shared. This feature is being considered for the Truckee release at this time.
Target milestone was changed from not determined to TBD
Upping priority again, this is a day to day annoyance for every single netbeans.org developer. We are etting more queries/complaints about this daily. RE asking whether this is a shared machine or not - nice idea, but definitely not a priority for us. I don't imagine many developers will be sitting in internet cafes (or public machines anywhere) checking their buglists :-) Not that the problem does not potentially exist, but compared to the larger picture that this issue describes, not a problem for us. I think we would rather have the root problem fixed quicker and live with the potential cookie clashing problem, than wait for the described solution. Unless that can be done real quick too :-)
updating whiteboard. this has been slated for the truckee 1 release.
This enhancement is targeted for the Truckee1 release of SourceCast. During the upgrade to that release we can verify this issue or reopen if necessary.
The milestone for this issue has been defined as Truckee2.
*** Issue 34209 has been marked as a duplicate of this issue. ***
Collab, can you pls let us know if Truckee 2 is SourceCast 2.6, which we are about to move to ? If not, I think we need to up priority and request a sooner fix. There are 7 duplicates of this issue noted here, all filed independantly - ie this is a big deal for a lot of people, and we need it fixed, soon.
Hi Jack, truckee is 2.6 let me know how you would like me to proceed from here. Eric
Truckee2 is 2.6 sorry if I was unclear missing the 2 there. Eric
Just to clarify - our affectionate external name for Truckee 1.x is 2.6. Truckee 2 is in the planning stages for next year.
Update: Changing the status of this issue to Resolved, Fixed. The solution for this issue has a target milestone of Truckee2. Action Plan: CollabNet support will review this issue during the upgrade to this release to confirm its resolution. If there are problems with the solution we will reopen this issue. If the solution appears to be working, we will reassign the issue to the original poster, requesting confirmation The original poster can then set the status to "Closed" or "Reopened" if necessary. Next Update: CollabNet support will review this issue during the staging process for the next upgrade. Thanks, Priya.
long time elapsed from last resolutin.... Hope, that new Truckee2 is on the way;-)
*** Issue 39930 has been marked as a duplicate of this issue. ***
I'm veryfying bugs and found out that this one is mine and IMHO this RFE 's not fixed. Reproduction: ============= 1)Start your browser. 2)Login to the netbeans.org site 3)Close your browser 4)Start your browser within shorten period of 8 hours 5)Try to enter/modify an issue. 6)You're required to login :-( Accourding RFE this should be fixed, so you shouldn't be asked for another login within 8 hours whether you close your borser or not. Sorry for reopening...
Dan, unfortunately CollabNet's closing policy goes like this : Close the issue when it is planned to be fixed in some future release. That means that it might be fixed in Truckee2 already, or maybe not. We don't know when Truckee2 will come, and we don't know when we will upgrade to it either. But whenever that happens is when we find out if we get the fix, or if the plan went wrong and it will be fixed later. So unfortunately, to stick with current standard policy, this issue should be CLOSED. If you disagree with the closing policy, or if you want to escalate the issue (ie you think this state is not satisfactory) pls take it up internally (Dan P, me).
OuKej :-) can live with different rulezzzz for different people, but there is no spase in my brain to remember it ;-/
CollabNet support - please verify which version of CEE this is fixed in, associate version number to nickname. i.e. - Is Truckee 2 equated to version 2.0? Thanks, Eric
As part of the scoping effort, this enhancement has been considered for the release 'Hudson' which is tentatively planned to be released on Q2 of 2005. The upgrade version for NB is going to be 2.6.x and this issue is considered to be fixed in releases above 3.x.
opening to change the resolution state.
This is now considered for Hudson release. As such marking this as RESOLVED->REMIND to make sure to review this when the release is due. Updated Keywords accordingly.
*** Issue 52242 has been marked as a duplicate of this issue. ***
Reopening. This issue is now over 3 years old, has 8 duplicates, the fix has slipped one release and is now *considered* for a release that is up to 1 year away. I'd like to request this be re-evaluated - it is a significant issue for us. To recap : we would like login cookies to be persistent, not session based. The current 8hr session means that every nb.org user has to log in at least daily, and depening on browser crashes or restarts, ususally more like 2,3,4...+ times per day. This is very unsuitable for the style of work that netbeans.org users need to do. In past discussions Collab pointed out that persistent login cookies would cause security issues if users shared computers. We had indicated that is not a concern for us; also, in the most recent duplicate (issue 52242) Randahl suggests adding a "remember me" checkbox to the login form. This sounds like a great idea, and would allow users to choose whether their session is persistent or not, I guess thus avoiding the shared machine issue altogether. The exact mechanism of the fix isn't so important to us (I guess). Considering the age and "popularity" of this request, and that a fix is still not in sight ("considered" means it may not happen even 1 year from now), I request that this issue be given more urgent attention.
What I don't understand is isn't Netbeans (Sun?) paying for CollabNet? CollabNet does not appear to be an OSS product, but rather a commercial one. How can CollabNet postpone important issues with their product for years? There are many people who work for other companies (like myself) who are being exposed to these problems with CollabNet through Netbeans. We are also being shown that CollabNet does not fix their issues (for years!). Does CollabNet not realize this could result in loss of sales? Does CollabNet not think that people like myself would steer clear of CollabNet for our own uses if our company was in the market for such a product? Sorry to rant, but this has gone on way too long.
The urgency and timeframe for this issue is updated in the internal issue.
ping... There is new release of SourceCast running on netbeans.org. Will this issue be solved with this new release?
I tested this first thing after the upgrade, and I see no change as a user.
it seems to me that support doesn't support. Am I wrong when I expect at least explanation or answer on questions said in last months in this issue? This comment isn't clear for me: ------- Additional comments from sripriya Thu Dec 16 09:01:05 +0000 2004 ------- The urgency and timeframe for this issue is updated in the internal issue. I want know more about problems in open source support, could you please explain the timeframe in which is this issue planned. Internal issue sez nothing. When (if ever) is it planned to fix this issue? Thank you.
Another 6 months has passed since any response from support. Any update ? This continues to be an issue. It is now approaching 4 years since we first requested this improvement. New nb.org users continue to bring it up, unimpressed that the site is set up this way.
Any news?
Apparently this issue was considered to be resolved in Hudson release. However I don't see it considered any more for that and pushed back further. We will take this up again with engineering on this. In the meantime assigning this to Andreas (the SUN engagement manager for CN).
As far as I know the current domain wide "Session timeout for authenticated session" is set to 480 minutes (8 hours) on the Danube-S stage box (stage.netbeans.org). Is this an acceptable solution?
Hi, event that I don't know what do following expresions stand for: current domain wide the Danube-S stage box the fact is that once you log on netbeans.org site then close your browser and open your browser again, you are not logged in anymore. So from my point of view it doesn't work as I've already wished.
Dan, the stage box has got URL http://www.stage.netbeans.org/ Support, although I lowered all security and privacy controls in my IE, this feature still does not work as expected. I was working with URL <http://www.stage.netbeans.org/servlets/UserList>. I logged in, quitted the browser and relaunched with that servlet URL. Browser was always redirected to <http://www.stage.netbeans.org/servlets/Login?cookieCheck=on> . I was able to reproduce the same behavior with Mozilla Firefox 1.0.7 on Win XP SP2.
> As far as I know the current domain wide "Session timeout for authenticated > session" is set to 480 minutes (8 hours) on the Danube-S stage box > (stage.netbeans.org). Is this an acceptable solution? Ani, netbeans.org has had an 8hour timeout since ~August 2001 (see Kaucin's comment Fri Aug 10 16:17:01 +0000 2001). This is not the soloution we are looking for. Jesse summarised best on Fri Oct 12 09:28:05 +0000 2001, though it has been re-summarised several times here since then. We want persistent cookies. A configurable timeout would also be great. We were told this would be fixed in Truckee1. Then Truckee 2. Then Hudson. And now it is not even in consideration ?
This is still under consideration, following it up internally.
to crm
Almost 1 year since my last comment, 2 years since I requested it be re-evaluated as it is (still!) significant for us, 6 years since the first request. What's the status of this reqeust ?
*** Issue 96514 has been marked as a duplicate of this issue. ***
Jack, We have found this to be something we are considering for a future release. Currently Product Management reviewed all future roadmaps, functionality, and options and even though we have not found this request to be considered on any roadmap we will continue to asses it for future opportunities. If you feel you would like this request to be considered/implemented by our Services team they would be willing to create a Statement of Work (SOW) for a fee to help expedite the implementation of this request. Please reply back to this email and we will help contact you Sales Account Manager (SAM) to contact you with the details. Thank you for your valuable feedback and we hope you will continue to collaborate and send our team your enhancement requests for we do review and value every one Regards, Ramya Support Operations
Marking the issue as resolved later to facilitate Support for reviewing it as this would be considered to be fixed in the future release of CEE. Regards, Ramya
I don't agree with the RESOLVED state. It isn't resolved -> reopening, provide right Target Milestone instead of closing the issue. Tahnk you.
*** Issue 125982 has been marked as a duplicate of this issue. ***
Marking the issue as resolved LATER.
Srivathsan, The issue has already been changed to resolved-later state and then reopened (by Lukas). Why is it again changed to that state? I don`t see any reliable justification.
Dima it's because of this condition has not been met (((CurrentYear - YearOfIssueCreation) mod (Priority+Int(Random(3))) == 0)
.
After careful review, we found this to be a custom request to address your specific business requirement. We have reviewed all future roadmaps, functionality, and options but did not find an area this request applied to CollabNet's future goals. If you feel you would like this request to be considered/implemented, please forward your suggestions to our Services team. Regards, Karishma CollabNet Support Operations
@Karishma I'm in a position of making purchasing recommendations for a large company, and we are currently looking at making a purchase of a software of which Collabnet is a vendor. This issue, which was dogged and avoided by Collabnet for 7 years, and now dismissed outright after that 7 year wait, has been my proof-in-the-pudding example of the service Collabnet offers. As a result, I have been vocal in recommending against Collabnet products. I feel there is absolutely no excuse for this, and you should take seriously the kind of image it projects, because it does cost you money in the end.
2Karishma Can you, please, explain how do your "future roadmaps, functionality, options and goals" prevent your company from fixing a bug which makes quite a few people waste quite precious time every day and incredibly annoys your customers?
With reference to desc72 mentioned: >>>>>>>>> I was working with URL <http://www.stage.netbeans.org/servlets/UserList>. I logged in, quitted the browser and relaunched with that servlet URL. Browser was always redirected to <http://www.stage.netbeans.org/servlets/Login?cookieCheck=on> . >>>>>>>>> Performing the same operations stated above now retains cookies & though you close the browser & open the browser, you will be able to use the same URL. However,this works in hand with the "Session timeout for authenticated session". Considering the fact that the Netbeans has httpd connections set to 1250 & if there are unused connections which would be maximizing the max httpd connections, *session timeout for authenticated session* was introduced,based on which we need to close the in numerous connections which may affect site performance. Please feel free to contact us with any clarifications. Regards, Ramya Support Operations
Jack, >>We want persistent cookies. A configurable timeout would also be great. Did you check desc90? Does that answer your question? We have a configurable authenticated session timeout starting from CEE 3.5.1. CollabNet can perform this configuration if you provide us a fixed time which would hold the login as expected by the users. Regards, Ramya
With ref to desc90,desc91 & considering the fact of "security breaches & max httpd connections", this feature has been addressed through "Session timeout for authenticated session",hence marking the issue as fixed. However,if you have alter opinions on further enhancing this "session timeout for authenticated session", please file a new issue which would help both of us & also reaching a resolution with quicker TAT. Regards, Ramya Support Operations
I did not understand a word... This issue was marked as fixed, but I still have to login every day! What should I change in my browser - firefox, or somewhere else to resolve it???
We recently moved out from Collabnet's infrastructure