[
https://issues.apache.org/jira/browse/AXIS2-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477353
]
jeff ling commented on AXIS2-2274:
----------------------------------
Hi Oleg,
Let me try to clarify it:
1. Https:
In AbstractHttpSender, agent.getState().setCredentials(new AuthScope(host,
port, realm), creds);
When it's https, the port value here is 80, for example, contentvm2, 80,
null. But because it's https, the Httpclient actually tries to connect to
443. So the response comes back as contentvm2, 443, null. That caused the
getCredentials() to return null.
2. >>I personally see no problem with the credential handling code as far as
HttpClient is concerned. NTCredentials is a subclass of
UsernamePasswordCredentials. Therefore it can be used with Basic and Digest
auth schemes. The domain and host attributes will simply have no effect.
Actually it's not exactly true. In Windows, if a domain user tries to
authentication using Basic Auth, the domain name is required:
The auth for basic auth response is: username:password and then base64
encoded. However, if it's domain account, the IIS expects:
domain\username:password and then base64 encoded. If you try to connect to
an IIS based web site using a browser, and then use tcpTrace to monitor it,
you will see what I mean.
Jeff
--
Jeff Ling
Product Solutions Engineer
GOOGLE
Office: (650) 253-3095
Fax: (650) 618-1835
Email: [EMAIL PROTECTED]
> Axis 2 as a client, access https:// doesn't work
> ------------------------------------------------
>
> Key: AXIS2-2274
> URL: https://issues.apache.org/jira/browse/AXIS2-2274
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: transports
> Affects Versions: 1.1
> Reporter: jeff ling
> Assigned To: Saminda Wishwajith Abeyruwan
> Priority: Critical
>
> When the server is IIS, https doesn't work. https itself is supported through
> Httpclient.
> The credential is put in to "state" as:
> agent.getState().setCredentials(new AuthScope(host,
> port, realm), creds);
> The problem is that if it's https, real port is implied,
> and the "port" here is the default "80". However, when the response comes
> back, the actually port (usually 433) is returned. That caused the credential
> (provider) not found.
> This is only one of the issues. The credential handling code below is really
> wrong:
> if (host != null) {
> if (domain != null) {
> /*Credentials for NTLM Authentication*/
> creds = new NTCredentials(username, password, host,
> domain);
> } else {
> /*Credentials for Digest and Basic Authentication*/
> creds = new UsernamePasswordCredentials(username,
> password);
> }
> agent.getState().setCredentials(new AuthScope(host, port,
> realm), creds);
> } else {
> /*Credentials only for Digest and Basic Authentication*/
> creds = new UsernamePasswordCredentials(username,
> password);
> agent.getState().setCredentials(new
> AuthScope(AuthScope.ANY), creds);
> }
> First, whether it's basic or Digest is not decided by whether domain name
> exists, and realm applies to basic and digest, not integrated. If you look at
> the IIS web server config screen, you will see.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
