#12200 closed enhancement (fixed)
NTLM proxy authentication support (ISA server)
Reported by: | ssandison | Owned by: | dd32 |
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | HTTP API | Keywords: | has-patch |
Focuses: | Cc: |
Description
Hi,
I am currently working on a contract where I am setting up WordPress MU to run an intranet on a Windows 2003 server. HTTP connections are locked down and the only way to connect to the internet is via an ISA proxy server. I used the recommended proxy settings in wp-config.php however this did not work for me. I did a little digging into the WordPress core code (/wp-includes/http.php) and I found that the proxy code doesn't support NTLM authentication. I have patched my version of http.php to support NTLM and this now works great. I have also added an extra constant in wp-config.php to configure this:
define('WP_PROXY_AUTHTYPE', 'NTLM');
I have produced a diff of the changes I made and would like to contribute them as I am sure there are other people who will encounter similar problems. Especially in a corporate network environment.
I have tested that NTLM proxy authentication will work using pecl_http (exthttp) and cURL. However I couldn't get it to work for streams, fopen or fsockopen. I couldn't find any documentation or forum posts of anyone succeding with these methods but the core developers might also want to take a look.
Please let me know what you think.
Cheers,
Steve
Attachments (1)
Change History (12)
#3
@
15 years ago
- Keywords reporter-feedback added; proxy ntlm isa removed
- Milestone changed from Unassigned to 3.0
- Version set to 3.0
#4
@
15 years ago
Apologies I have updated the diff file.
Sorry I did attempt to add NTLM support to streams, fopen and fsockopen but I found any useful information impossible to find to help me acheive this.
I started off with specifying explicitly what authentication type should be used configured by adding a constant to wp-config.php.
However I have now simplified my changes so that a new constant in wp-config.php would no longer be nessecary. The code now just tells curl or pecl_http to use any form of authentication that will work. In my case it will select NTLM as this is all that is available. The PHP extension manages this choice.
Let me know what you think.
Cheers,
Steve
#7
@
15 years ago
I am using a setup of WP MU on a Windows 2008 Server (IIS7) which also goes through an ISA Proxy Server. The difference here is that I am using Microsoft Active Directory to authenticate users, based on the users of the network domain. I am using the WPDirAuth plugin in order to handle the authentication with Microsoft Active Directory.
I have encountered no issues with setting proxy details for the ISA server. It just works! Just though this may be of help.
#8
@
15 years ago
User authentication is a separate issue as far as I am aware. WPDirAuth is handling user sign on to WordPress through the user's web browser (client side) whereas this issue is about PHP/cURL (server side) connecting to the internet via the ISA proxy server. I don't think the logged in users credentials are used when PHP is connecting to the proxy. In my case I am using a seprate domain user account for the proxy settings in wp-config.php.
Do your proxy server settings in wp-config.php use a specific username and password to connect to the proxy server? Your ISA server may be accepting basic authentication whereas on the network I am working on it is very locked down and will only accept NTLM.
#9
@
15 years ago
The only downside to this i can see is that 2 requests are required, One to determine proxy type, another to make the request once it knows the authentication type required.
I'm going to commit this and add a note to the proxy authentication docs that only Basic is supported, unless Curl|HTTP Extension are in use and support it.
Could you create a patch which shows the differences?
You've most likely changed the line endings, and will need to tell your diff'er to ignore whitespace or line endings.
While i'm at it, Do you have any references for the underlying NTLM authentication so someone else can try integrating it with the other transports?