History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: XFIRE-1100
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Dan Diephouse
Reporter: Steven Upton
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
XFire

Windows Authentication using NTLM sets the wrong state object in CommonsHttpMessageSender

Created: 24/Oct/07 04:34 AM   Updated: 24/Oct/07 04:39 AM
Component/s: Core
Affects Version/s: 1.2.6
Fix Version/s: 1.2.6

Time Tracking:
Not Specified

Environment: Windows Environment using windows NT authentication with IIS Server 6 or 7


 Description  « Hide
When I enable IIS NT Authentication I am setting :

//client is XFire Client
client.setProperty(Channel.USERNAME, "username");
client.setProperty(Channel.PASSWORD, "mypass");

This works for IIS Basic Authentication, but when I try NT Authentication I use the same method as above, but also add the domain name:

//client is XFire Client
client.setProperty(Channel.USERNAME, "mydomain\username");
client.setProperty(Channel.PASSWORD, "mypass");

On both cases, using this method to set the Username/Password sets the State object in CommonsHttpMessageSender.state object, but not in the CommonsHttpMessageSender.client.state object. NTLM Authentication appears to fail because of this. When testing a web service call by using HttpClient directly, NTLM works fine as the state object is correct.

Maybe I am doing something wrong?

I have had to get round this by overriding



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Steven Upton - 24/Oct/07 04:39 AM
continued.... (I pressed wrong key and submitted bug without finishing):

HttpClientParams params = (HttpClientParams) HttpClientParams.getDefaultParams();
params.setAuthenticationPreemptive(true);
params.setParameter(CredentialsProvider.PROVIDER, new WSCredentialsProvider(wss.getHttpUsername(), wss.getHttpPassword()));
client.setProperty(CommonsHttpMessageSender.HTTP_CLIENT_PARAMS, params);

By invoking my WSCredentialsProvider which does exactly the same as the getCredentials() method in CommonsHttpMessageSender seems to resolve this issue.

Steve