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.
Even if it reports a successfull login, the netbeans.org site asks me to log in again when I want to report a bug, change my preferences, etc.
This happens when I set my preference privacy settings to "only accept cookies from originating site". This is a very common setting by expert users, since it avoids tracking by web page advertisers using cookies.
This sounds like the same problems reported in issue 10478 and issue 16973. The explanation from Taska in 16973 says "This is occuring becuase our system is set up to be stretchable across several servers... for example, a seperate file server and webserver (or multiple webservers). The cookie, which is given to you by the webserver, needs to go back to the fileserver. In some cases, these are the same machine; in other cases, not." Collab, since this issue keeps coming up, is there any other soloution possible ?
The short answer is, no, not with the question as stated. The long answer is, you're welcome to submit a seperate defect saying that cookies are sent back to servers other than the originating server, which causes high-security clients to have issues. I'm not sure what the engineers will have to say about that, but it can't hurt to ask.
Reopening, and changing summary as Taska suggested. The fact that cookies are potentially returned to a non- originating server means clients who have these kind of cookies disabled in browsers cannot use nb.org reliably - logins, sessions, downloads all fail or act strangely. When this happens it is doubly confusing as the cause is not apparent - login will work first time for eg, but if you happen to submit a bug on another module website you need to login again. I personally use this cookie setting, and from other bug reports I think there are quite a few others who do so also. Is there an alternative ?
I think that if the server is set up correctly, it should catch the cookie not being set, and use URL rewriting. There might be a hack made so that the server doesn't correctly pick up the cookie not being set.
Okay, we'll pass this on.
I've submitted this request to the engineering group (PCN8938).
Our engineering folks have set a target of SC1.3 for this.
Administrative Change; SC1.3 has been renamed SC2.0.
Correcting typo.
The target for this issue has been moved to Truckee.
*** Issue 16973 has been marked as a duplicate of this issue. ***
*** Issue 19693 has been marked as a duplicate of this issue. ***
Not sure if this is useful, but it certainly illustrates the problem. I just logged in on www.nb.org/. I go to this page : http://contrib.netbeans.org/servlets/ProjectDownloadList I'm trying to check the links of the most recent contributions. I can download this file - http://contrib.netbeans.org/servlets/ProjectDownloadList? action=download&dlID=176 but when I click on the very next file in the list - http://contrib.netbeans.org/servlets/ProjectDownloadList? action=download&dlID=148 I simply get another copy of the ProjectDownloadList html page. Browser is IE5.5/Win2k, "medium" security settings (cookies enabled, per-session cookies enabled). Hmm, I just checked in N4.7, where I have "accept only cookies sent back to originating server" - regardless of where I log in (www or contrib.nb.org), all downlaods links work. That is not what I expected. How far out is "Truckee" ? This issue is increasingly becoming a problem ...
The Truckee release is expected for early next year. I will add your comments to the internal issue.
I get the same thing, it just returns a copy of the download list, only my internet security setting are set to low and accept all cookies.
*** Issue 25359 has been marked as a duplicate of this issue. ***
More and more becoming a problem. Upping priority. I recently browsed all cookies on my machine; of all of them, netbeans.org was the only one to have host-specific cookies (ie valid only on eg www.netbeans.org) instead of domain wide (eg .netbeans.org). As I understand it, that is the root problem here ?
That does seem to be the issue, I have contacted engineering for any updates on this.
*** Issue 25565 has been marked as a duplicate of this issue. ***
This fix has been assigned to the Truckee1 release of SourceCast. During the upgrade to that release we can verify this issue or reopen if necessary.
Updating whiteboard..
oops..reopening to keep this in the same status as before..
again...
Changing Target Milestone to CEE 2.6.2
This is apparently not fixed. Trying to download a file from http://3rd-party.netbeans.org/ results in the same looping problem described here. Yet another issue supposedly fixed in our current release of SC, but apparently not, because it was closed and hidden from sight ?
*** Issue 71662 has been marked as a duplicate of this issue. ***
Downloads are now through a separate download server and the CEE is placed behind cache servers; please confirm if this behavior is still seen.
All downloads discussed here are from SourceCast's Documents & Files servlet, which are served from www, not the new downloads server. Yes, this is still a problem, and is still occurring.
Cleaning up the milestones.
Not clear if this is just got worse or not, I just got a few reports of the looping problem. I'll attach the output of Firfox's Live HTTP Headers when I try to download this file http://www.netbeans.org/files/documents/4/589/CopyClass.zip
Created attachment 31507 [details] looping http headers
Looks like something changed, perhaps due to recent outages/patches etc, as none of the files in the ProjectDocumentList appear to be working right now - all of them give the looping error. We're getting a lot of reports from users hitting this problem right now.
Hi Jack, I have updated the engineers about the issue and will get back to you as soon as this gets resolved. Regards, Jeeva Support Operations
Updating status whiteboard. Regards, Jeeva Support Operations
Ping ... we are getting a constant stream of complaints from users unable to download files .... this really is a P1 for us.
Hi Jack, Collab would require a downtime of around 20 to 30 minutes to fix this issue. Please let us know your convenient timing (we would prefer to do it asap). P.S: tried to reach you in your mobile, but was just fortunate enough to reach the voice mail. Regards, Jeeva Support Operations
You got voicemail bcs I am calling internal ppl trying to arrange a downtime. While this is a P1, the site going down in the middle of the day (even for just 20min) is a bigger P1, so we would prefer to schedule at some less busy time. Current suggestion is 10pm PST. Earlier than this will disrupt milestone build currently running; later than this will (probably) disrupt significan CVS work planned for this weekend (see extranet issue 51). I'm still trying to confirm 10pm is suitable; will call back when I find out.
Confirmed, 10pm Pacific time would be best for us for this outage. I will notify the community of the issue also. Pls verify.
Jack The issue related to looping has been resolved we are able to download the files available in the link given below http://www.netbeans.org/servlets/ProjectDocumentList Please confirm the same .
Downgrading the priority. Back to the original issue.
I am able to download the files that were previously looping for me. I assume the most recent issue is indeed fixed. Do we know if the fix will also have addressed the original problem (which only seemed to affect a small set of users) ?
Jack, I am not able to reproduce the original issue. True, some redirects on the Docs & Files area are handled better now, so there is a possibility that it might fix the original issue as well. Unless the users can provide some liveHTTPheaders when they encounter this, I am inclined to close this.
Well if you look at the history of this issue (and its duplicates), it was never easy to reproduce. However, agreed, without move detail (eg livehttp headers) not much to can do here. Will reopen with details if I hear of it again.
x
Marking as verified Thanks, Kavitha Support Operations
We recently moved out from Collabnet's infrastructure