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 269362 - Plugins and IDE Updates not working when behind company proxy
Summary: Plugins and IDE Updates not working when behind company proxy
Status: NEW
Alias: None
Product: ide
Classification: Unclassified
Component: Code (show other bugs)
Version: 8.2
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: issues@ide
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-15 22:14 UTC by poptop
Modified: 2016-12-15 22:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description poptop 2016-12-15 22:14:29 UTC
Company proxy settings are set and most things are working fine. However, when I try to update my IDE or add a new Plugin via Tools -> Plugins, the UI displays no results. In my messages.log I see some errors related to not being able to process the GZIP'd catalog.xml.gz or updates.xml.

The files here (D:\Users\<USERID>\AppData\Local\NetBeans\Cache\8.2\catalogcache) are where I found the actual responses. These files show the HTML of our company's Websense block page. So I logged into our Websense servers to view the real time logs and see a difference between when I hit the URL (http://plugins.netbeans.org/nbpluginportal/updates/8.2/catalog.xml.gz) from my browser and when the IDE tries to make the same request.

When attempting from my browser, I have no issues retrieving the file:
<WORKSTATION_IP> - <USER_ID> [15/Dec/2016:10:55:09 -0500] "GET <URL_HERE>" 200 57999 200 57999 0 0 4220 298 703 224 0
* There is a username captured in the logs

And when the IDE tries, I see a slightly different request:
<WORKSTATION_IP> - - [15/Dec/2016:10:55:09 -0500] "GET <URL_HERE>" 200 57999 200 57999 0 0 4220 298 703 224 0
* The same field is empty from the IDE request

From the results, it looks as though when executed its not actually running as the logged in user on the workstation. Since this URL is in our companies AUTH list you must be logged in to get to this URL. When the request comes from a workstation, instead of a user (like the second request), then the request gets blocked.