Opened 3 years ago

Closed 3 years ago

# need of proxy-access setup plugin

Reported by: Owned by: falkb osimons normal EstimationToolsPlugin normal coderanger, falkb 0.11

### Description

Our intranet needs a proxy with authentification to get access to internet sites. Because of this serverside charts of the http://trac-hacks.org/wiki/EstimationToolsPlugin#Install do not work.

As dirty hack I changed deep down the urllib2's function urlopen from

...
_opener = build_opener()
...


to

...
...


and now those fancy google charts work for my EstimationToolsPlugin. :-P

I wish I could do that configuration via Trac's web interface (Admin menu -> ...) and therefore I request a new plugin for proxy configuration that other plugins may use.

### comment:1 Changed 3 years ago by anonymous

I think such plugin would also be useful to fix some other tickets of IncludeMacro: #6879, #2278 and likely some more. That's why I added coderanger to CC.

### Changed 3 years ago by osimons

Proxy support for server-side charts.

### comment:2 Changed 3 years ago by osimons

It can't be a general plugin, as there is no general service it can provide to plugins without plugins specifically building support for it anyway - and thereby also making this other 'proxy plugin' a new dependency.

I've attached a patch that adds proxy support for server-side charts. It supports trac.ini setting like this to accomplish the same as the example shown in ticket description:

[estimation-tools]


### comment:3 follow-up: ↓ 4 Changed 3 years ago by falkb

Thanks a lot. Your patch works pretty well. Now I've removed my urllib2 hack again, and EstimationToolsPlugin still works well, IncludeMacro does not - as expected.

### comment:4 in reply to: ↑ 3 Changed 3 years ago by anonymous

... IncludeMacro does not...

I mean does not any longer. When my hack to urllib2 was active, IncludeMacro had no proxy problems either.

### comment:5 follow-up: ↓ 7 Changed 3 years ago by osimons

Hmm. Seems Python should support generally configured network proxies by default, and if so that would be the general solution. A quick scan mentions HTTP_PROXY environment variable as well as Windows registry key Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer.

Better research this before applying any patch, and also if the system proxy support authentication if needed. Putting patch on hold for now.

### comment:6 Changed 3 years ago by falkb

I searched through the internet but that registry settings doesn't seem to support authentication via username and password, anyway I haven't find a hint.

I tried a new key "ProxyServer" with value

http=myname:mypassword@123.456.789.123:0815


but I haven't managed it to get the IncludeMacro working again, even after an Apache/Python restart. That's why I think it has no effect.

### comment:7 in reply to: ↑ 5 ; follow-up: ↓ 8 Changed 3 years ago by anonymous

A quick scan mentions HTTP_PROXY environment variable as well as Windows registry key

I played around with both approaches, and I've found out the Windows registry thingy has no influence, but it works if one sets HTTP_PROXY as system env var of the user which is used for the SVN/Trac Windows service to the following:

 env var name value HTTP_PROXY 123.456.789.123:0815

Note: It is not necessary to explicitely set username and password in the value, but setting it works also.

After that I restarted the SVN/Trac Windows service and the IncludeMacro, which was not patched, suddenly works pretty well. So you could even close #6879, #2278 and some more related...

So you are right, the Python base libraries (Python 2.5 here) properly detect the settings from the underlying Windows.

Although IMHO the attached patch attachment/ticket/8569/t8569-serverside_proxy-r9694.diff makes sense if a proxy should be available for Trac and its plugins only, because of security reasons. I think that is the same reason why Firefox or IE offer to set their own local proxy settings. So maybe add the patch for the case if an Administrator says: For Trac only, please''.

### comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 3 years ago by anonymous

So you could even close #6879

Sorry, this conclusion was wrong. That problem is another one, it still exists.

### comment:9 in reply to: ↑ 8 Changed 3 years ago by anonymous

So you could even close #6879

Sorry, this conclusion was wrong. That problem is another one, it still exists.

I mean after setting HTTP_PROXY including of internet pages, e.g. [[Include(https://www.google.com)]] , work well now, but https access to itself via its intranet IP does not.

### comment:10 follow-up: ↓ 11 Changed 3 years ago by osimons

• Resolution set to worksforme
• Status changed from new to closed

OK, using HTTP_PROXY seems the best solution then. No need to patch the plugin.

### comment:11 in reply to: ↑ 10 ; follow-up: ↓ 12 Changed 3 years ago by anonymous

OK, using HTTP_PROXY seems the best solution then. No need to patch the plugin.

Any comment to my previous idea, I mean this?:

... attached patch ... makes sense if a proxy should be available for Trac and its plugins only

### comment:12 in reply to: ↑ 11 Changed 3 years ago by osimons

Any comment to my previous idea, I mean this?:

Sure:

1. The patch will only work for the single use-case of this particular request for this particular plugin.
2. To be general, a setting would somehow need to inject the HTTP_PROXY setting into os.environ to allow any plugin to reuse it.
3. Then that becomes a really round-about way of just setting the value in the first place, typically in the .wsgi script that sets environment variables for the project anyway.

Hackish and uneccessary when a perfectly fine general solution already exists.

### Modify Ticket

Change Properties