Question

Workflow Web Request Generates 401 in IIS Logs not reported in WF

Workflow Version 10 Integrations

Updated March 28, 2019

asked on March 27, 2019 • Show version history

We've encountered an issue we're having a hard time figuring out. We have an external web application running its API on Tomcat, and we use PUT requests from Workflow to update data.

The Web Service is configured with "use the following credentials" and everything seems to work fine from the Workflow side.

However, on the receiving application side we are finding that every request from Workflow generates a 401 error followed immediately by a 200 with the same parameters in the Tomcat logs.

EDIT: I incorrectly assumed the application was running on IIS because it is a Windows server and the logs looked extremely similar, but it is actually on Tomcat.

It looks as if Workflow is actually sending two requests, the first failing, and the second succeeding, but Workflow is only tracking the second successful request in the instance details.

When I manually configure an Authorization header in the Request Header settings using the one Postman generates with the same credentials, the problem goes away completely.

Has anyone seen this before? Is there any setting we can change to correct the issue?

It almost seems like a quirk of the authentication used by Workflow since I cannot reproduce it when making PUT requests from other applications.

To provide some additional information, the issue does not seem to occur with GET requests. I don't know about any other methods because we are only using GET and PUT with that particular API.

We are currently running Workflow 10.2

1 0

Answer

SELECTED ANSWER

replied on March 28, 2019

That's because it doesn't need it.

The general workflow is something like this;
Client makes a request to the server
The server asks for the client to identify itself, along with authentication methods it accepts, (401 response)
The client tries again, with an appropriate authentication header
The server replies (200 response)

By manually adding the authentication headers, you're cutting steps 3 and 4 out of the sequence.

2 0

Replies

replied on March 27, 2019

Which authentication methods do you have enabled on the "workflow" site in IIS?

0 0

View 2 previous replies

replied on March 27, 2019

I was mistaken, the site/application is actually on Tomcat on a Windows server. It is using Basic authentication.

0 0

replied on March 28, 2019

I don't know specifically about Workflow, but it's common for HTTP calls to include one or more 401 messages as the two endpoints negotiate how to authenticate. If you were to examine the specific messages, you'd likely see a WWW-Authenticate header field.

From Wikipedia:

Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.

1 0

replied on March 28, 2019

That makes sense, but I feel like there's more to it because the 401 errors did go away after I added the authorization header to the request instead of relying on the built-in authentication.

1 0

SELECTED ANSWER

replied on March 28, 2019

That's because it doesn't need it.

The general workflow is something like this;
Client makes a request to the server
The server asks for the client to identify itself, along with authentication methods it accepts, (401 response)
The client tries again, with an appropriate authentication header
The server replies (200 response)

By manually adding the authentication headers, you're cutting steps 3 and 4 out of the sequence.

2 0

replied on March 28, 2019

Now that makes sense, thank you.

0 0

You are not allowed to follow up in this post.

Question

Question

Workflow Web Request Generates 401 in IIS Logs not reported in WF

Answer

Replies

Sign in to reply to this post.