Trying to use httpClient to connect to a SOAP endpoint with a username/password and running into a "403: Access Denied" error.
Tried passing them it in the header as an Authorization field base64 encoded with the format of 'Basic {username}:{password}' with the u:p portion encoded as I saw on general Java httpClient requests, putting username and password as fields in the header, and also passing it in as username and password parameters to the httpClient function call itself.
Everything works with SoapUI setting the username/password fields in the request properties so there isn't an issue with the credentials or endpoint access from this machine. Based on that fact I think the issue is getting the username/password sent across properly through the httpClient call.
Also tried using the Web Services module, it doesn't let us pick between the HTTP and HTTPS endpoint and times out by defaulting to the HTTPS. It also seems to me like "Spend $5K on the Web Services module to access a SOAP endpoint" is an unreasonable expectation, hence trying to use httpClient instead.
What am I missing for adding these in for authorization with httpClient?
system.net.httpClient can handle basic authorization for you, might be useful to rule out any problem with your own encodeAuth implementation.
Breaking into the WebServices module and comparing the output of both encodings they are identical (excepting mapping the value in the header in my code vs. returning what they are adding to the request in their code within the module.)
I assume by basic authentication you mean passing in the username/password as parameters in the client.post() call?
If I do that and then grab the request headers from the response I see the same thing as from the base64 encoding, so that would appear to be the way to go, although it still errors out.
I also see a User Agent value in the request headers, could that be causing an issue?
Yes.
Maybe "SoapUI" isn't doing basic auth then? Don't know what else to tell you...
Looking at a Wireshark dump of both SoapUI doesn't appear to be passing in the credentials as part of the header so there must be something else going on.
Edited the post above, I also see a User-Agent field added from the httpClient call, I wonder if that could be causing a problem on the endpoint side?
It shouldn't... but nobody knows anything about this endpoint but you.
Have you opened a support ticket and provided Wireshark captures to compare?
Is there a way to prevent httpClient from upgrading to HTTP2? That is the only thing I am seeing different between the SoapUI request and the Ignition one.
As of 8.1.16 it takes a "version" parameter you can set to "HTTP_1_1" or "HTTP_2".
Doesn't seem to be well represented in the manual's initial presentation of the syntax:
system.net.httpClient([timeout], [bypass_cert_validation], [username], [password], [proxy], [cookie_policy], [redirect_policy], [customizer])
@Paul.Scott
1 Like
That appears to have fixed the problem by setting it to HTTP_1_1. Thanks for the help and sounding board Kevin!
Reading the manual explains the tools.
For anyone else searching, if you need to connect to an SAP endpoint using SOAP and an Ignition httpClient, make sure you instantiate your httpClient object with the version="HTTP_1_1" value, otherwise you may get a status of 403 "Access Denied" on your response.
You can pass in your username and password as part of the post() or get() call as needed, you don't need to deal with any base64encoding, the httpClient will handle that for you on the backend.
2 Likes
Every once in a while HTTP/2 vs HTTP/1.1 causes strange problems that need debugging...
... and never once have I seen a 505 HTTP Version Not Supported returned 
3 Likes
I had the exact same issue and this fixed it for me too!
1 Like
