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.

Bug 13479 - Login valid until I restart browser/not pure 8 hours [ cookie ]
Summary: Login valid until I restart browser/not pure 8 hours [ cookie ]
Status: RESOLVED INVALID
Alias: None
Product: obsolete
Classification: Unclassified
Component: collabnet (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker with 12 votes (vote)
Assignee: support
URL:
Keywords:
: 39930 (view as bug list)
Depends on:
Blocks: 50893
  Show dependency tree
 
Reported: 2001-07-10 17:48 UTC by dmladek
Modified: 2009-11-08 02:27 UTC (History)
9 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dmladek 2001-07-10 17:48:25 UTC
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.
Comment 1 Jesse Glick 2001-07-10 20:51:32 UTC
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.
Comment 2 dmladek 2001-07-11 07:43:00 UTC
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...
Comment 3 kat 2001-07-11 23:48:33 UTC
This issue has been entered as sc-support107, pcn4889
Comment 4 Taska 2001-07-13 05:40:52 UTC
Assigning to support.
Comment 5 Taska 2001-07-13 05:44:32 UTC
accepting for support
Comment 6 Taska 2001-07-14 01:22:19 UTC
Moving this to P3 per conversation with Michael Boyer.
Comment 7 Adam Sotona 2001-07-31 09:44:42 UTC
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
Comment 8 Taska 2001-08-02 05:17:51 UTC
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.
Comment 9 Taska 2001-08-02 20:09:13 UTC
*** Issue 13755 has been marked as a duplicate of this issue. ***
Comment 10 rbalada 2001-08-03 10:31:00 UTC
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!
Comment 11 jcatchpoole 2001-08-03 16:25:33 UTC
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.
Comment 12 Unknown 2001-08-08 05:51:15 UTC
A longer timeout is in testing on the staging server.
Comment 13 Unknown 2001-08-10 17:17:01 UTC
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.
Comment 14 mboyer 2001-08-14 12:01:30 UTC
Appears to be fixed.
Comment 15 mboyer 2001-08-14 12:02:36 UTC
Verified.
Comment 16 dmladek 2001-08-15 09:05:53 UTC
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
Comment 17 Adam Sotona 2001-08-15 09:15:08 UTC
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.

Comment 18 dmladek 2001-08-15 10:05:07 UTC
Thanks Adam for your comment.
You expressed what I missed:-)
Comment 19 mboyer 2001-08-15 11:03:27 UTC
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

Comment 20 dmladek 2001-08-15 11:35:16 UTC
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:-)
Comment 21 _ pkuzel 2001-08-17 15:17:44 UTC
I think that the root of problem is that Mozilla and IE password
managers are not supported. It was not addressed yet.
Comment 22 Unknown 2001-08-18 00:20:52 UTC
Adding last comment to 13568 and closing this issue.
Comment 23 Unknown 2001-08-18 00:22:00 UTC
Marking issue as resolved.
Comment 24 rbalada 2001-08-27 18:09:32 UTC
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.
Comment 25 dmladek 2001-08-29 09:09:02 UTC
or simply browser crashs.And that is not very rare phenomenon:-(
Comment 26 Taska 2001-09-08 01:05:10 UTC
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).
Comment 27 Taska 2001-09-08 01:06:02 UTC
Additional note: Mozilla or modern versions of IE allow you to save
login information.  This would be an alternative option.
Comment 28 dmladek 2001-09-10 14:32:46 UTC
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
----------------------------------------------------------------------
Comment 29 Unknown 2001-10-09 20:50:29 UTC
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.
Comment 30 Jesse Glick 2001-10-12 10:28:05 UTC
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.
Comment 31 mvinar 2001-10-23 08:46:12 UTC
*** Issue 16322 has been marked as a duplicate of this issue. ***
Comment 32 jcatchpoole 2001-10-23 15:04:17 UTC
*** Issue 16322 has been marked as a duplicate of this issue. ***
Comment 33 mvinar 2001-11-20 09:52:07 UTC
*** Issue 17187 has been marked as a duplicate of this issue. ***
Comment 34 rbalada 2001-11-26 14:23:42 UTC
*** Issue 18083 has been marked as a duplicate of this issue. ***
Comment 35 jcatchpoole 2002-06-21 11:28:59 UTC
*** Issue 24961 has been marked as a duplicate of this issue. ***
Comment 36 jcatchpoole 2002-06-21 11:32:01 UTC
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.
Comment 37 kat 2002-06-21 22:13:28 UTC
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.

Comment 38 kat 2002-06-27 22:24:50 UTC
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.
Comment 39 Marek Grummich 2002-07-19 16:45:45 UTC
Target milestone was changed from not determined to TBD
Comment 40 jcatchpoole 2002-08-08 10:04:08 UTC
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 :-)
Comment 41 Unknown 2002-08-09 00:30:05 UTC
updating whiteboard.  this has been slated for the truckee 1 release.
Comment 42 Unknown 2002-08-21 00:34:58 UTC
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.
Comment 43 Unknown 2002-09-10 21:37:56 UTC
The milestone for this issue has been defined as Truckee2.
Comment 44 jcatchpoole 2003-06-06 10:27:00 UTC
*** Issue 34209 has been marked as a duplicate of this issue. ***
Comment 45 jcatchpoole 2003-06-06 10:30:06 UTC
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.
Comment 46 Unknown 2003-06-06 23:12:45 UTC
Hi Jack,

truckee is 2.6
let me know how you would like me to proceed from here.
Eric
Comment 47 Unknown 2003-06-07 00:28:33 UTC
Truckee2 is 2.6 sorry if I was unclear missing the 2 there.
Eric
Comment 48 shartley 2003-06-20 22:35:25 UTC
Just to clarify - our affectionate external name for 
Truckee 1.x is 2.6.  Truckee 2 is in the planning stages 
for next year.
Comment 49 Unknown 2003-07-23 10:44:24 UTC
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.
Comment 50 dmladek 2003-07-29 12:50:45 UTC
long time elapsed from last resolutin....
Hope, that new Truckee2 is on the way;-)
Comment 51 jcatchpoole 2004-05-05 17:41:34 UTC
*** Issue 39930 has been marked as a duplicate of this issue. ***
Comment 52 dmladek 2004-07-29 10:29:23 UTC
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...
Comment 53 jcatchpoole 2004-07-29 10:48:52 UTC
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).
Comment 54 dmladek 2004-07-29 10:57:52 UTC
OuKej :-) can live with different rulezzzz for different people,
but there is no spase in my brain to remember it ;-/
Comment 55 ejrenaud 2004-09-17 15:25:45 UTC
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
Comment 56 Unknown 2004-10-13 15:50:43 UTC
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.
Comment 57 Unknown 2004-11-03 20:42:53 UTC
opening to change the resolution state.
Comment 58 Unknown 2004-11-03 20:49:09 UTC
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.
Comment 59 jcatchpoole 2004-12-09 11:26:46 UTC
*** Issue 52242 has been marked as a duplicate of this issue. ***
Comment 60 jcatchpoole 2004-12-09 11:43:22 UTC
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.
Comment 61 dmartin01 2004-12-09 16:10:49 UTC
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.
Comment 62 Unknown 2004-12-16 09:01:05 UTC
The urgency and timeframe for this issue is updated in the internal 
issue.
Comment 63 Lukas Hasik 2005-03-18 10:42:18 UTC
ping...
There is new release of SourceCast running on netbeans.org. 

Will this issue be solved with this new release?
Comment 64 dmartin01 2005-03-18 15:23:10 UTC
I tested this first thing after the upgrade, and I see no change as a user.
Comment 65 Lukas Hasik 2005-03-24 13:52:23 UTC
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.
Comment 66 jcatchpoole 2005-05-11 11:56:37 UTC
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.
Comment 67 Roman Strobl 2005-10-03 14:39:37 UTC
Any news?
Comment 68 Unknown 2005-10-04 01:03:39 UTC
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).
Comment 69 Unknown 2006-05-27 00:20:08 UTC
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?
Comment 70 dmladek 2006-05-28 13:33:23 UTC
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.

Comment 71 rbalada 2006-05-29 09:31:19 UTC
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.
Comment 72 jcatchpoole 2006-06-09 10:26:55 UTC
> 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 ?
Comment 73 Unknown 2006-11-06 10:33:47 UTC
This is still under consideration, following it up internally. 
Comment 74 Unknown 2006-11-30 12:10:16 UTC
to crm
Comment 75 Unknown 2006-11-30 12:10:39 UTC
to crm
Comment 76 jcatchpoole 2007-02-26 09:28:20 UTC
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 ? 
Comment 77 jcatchpoole 2007-02-26 09:28:49 UTC
*** Issue 96514 has been marked as a duplicate of this issue. ***
Comment 78 Unknown 2007-07-31 08:12:00 UTC
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
Comment 79 Unknown 2007-09-19 16:02:41 UTC
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
Comment 80 Lukas Hasik 2007-09-20 12:16:06 UTC
I don't agree with the RESOLVED state. It isn't resolved -> reopening, provide right Target Milestone instead of closing
the issue. Tahnk you.
Comment 81 rbalada 2008-01-25 10:36:11 UTC
*** Issue 125982 has been marked as a duplicate of this issue. ***
Comment 82 Unknown 2008-03-07 11:35:10 UTC
Marking the issue as resolved LATER.
Comment 83 dlipin 2008-03-07 13:16:50 UTC
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.
Comment 84 rbalada 2008-03-07 14:32:50 UTC
Dima it's because of this condition has not been met (((CurrentYear - YearOfIssueCreation) mod (Priority+Int(Random(3)))
== 0)
Comment 85 Unknown 2009-01-13 18:48:39 UTC
.
Comment 86 Unknown 2009-01-13 18:49:52 UTC
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
Comment 87 dmartin01 2009-01-13 19:57:40 UTC
@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.
Comment 88 Sergey Grinev 2009-01-14 14:09:13 UTC
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?
Comment 89 Unknown 2009-01-16 09:55:20 UTC
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
Comment 90 Unknown 2009-01-28 09:44:19 UTC
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

Comment 91 Unknown 2009-02-17 07:25:11 UTC
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
Comment 92 Egor Ushakov 2009-02-26 10:09:17 UTC
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???
Comment 93 Marian Mirilovic 2009-11-08 02:27:53 UTC
We recently moved out from Collabnet's infrastructure