Client has recently stopped working with "Failed to get Authorization code" (Failed to create rest session)

[davidbairdala]

I am using the Bullhorn Java SDK to retrieve candidate data. Up until this morning I was able to authenticate and execute filter searches by creating a new StandardBullhornData instance.

Now the creation of the StandardBullHornData class fails with an "Unable to create rest client" exception. Looking at the stack trace I can see that the underlying cause is a null pointer exception in RestApiSession.getAuthCode() because a URI being returned from restTemplate.postForLocation() is null. It appears to me that this method (postForLocation) is always expecting a 302 response with a "Location" header, but when I examine the response for the request (the third request in the authentication sequence) the status code is 200, and there is no Location header, resulting in a null pointer exception

It is entirely possible that an infrastructure issue is causing this, but I have no way of telling what is going wrong.

I am using the following URLs:

REST token URL: https://rest-aus.bullhornstaffing.com/oauth/token
REST Authorize URL: https://rest-aus.bullhornstaffing.com/oauth/authorize
REST Login URL: https://rest-aus.bullhornstaffing.com/rest-services/login

I have tested with versions 1.5.47 and 1.4.49 of the SDK, and I have not changed the credentials, client secret or anything else.

It seems to me that at the very least that the SDK should deal with the 200 response

[davidbairdala]

Some additional information - I can authenticate manually using Postman, so I am fairly confident that there is nothing wrong with the credentials I am using.

Also, it is failing on the first request (https://rest-aus.bullhornstaffing.com/oauth/authorize?client_id={clientId}&response_type={responseType}&action={action}&username={username}&password={password}), but it is repeated 3 times (retry loop)

In postman, the call to authorize returns 200, not 302, and there is likewise no 'Location' header, but the client is definitely expecting a Location header, so either the particular endpoint I am hitting (rest-aus) is doing the wrong thing, or the client is.

Some assistance would be greatly appreciated.

[pbearne]

Are you getting bad rest token or time-out message?

I have seen this as well but found the solution.

[davidbairdala]

No, no timeout message or anything about a bad rest token. Just the message "Failed to get Authorization code", and a stacktrace that indicates that a Null Pointer Exception is the root cause.

[davidbairdala]

Some more additional information. Like I said before, if I use postman to GET the authorize URL I get a 200-OK, and no Location header. If I hit the authorize URL using chrome, however, the server returns 302, and the browser follows the redirect to a bullhorn.com URL with an authorization code as a parameter (it actually follows 3 redirects before it finally gets a 200 response).

If I use "get" or "curl" to do the GET I get the following error(s) (I haven't posted actual URLs because they contain secrets):

wget

Resolving rest-aus.bullhornstaffing.com (rest-aus.bullhornstaffing.com)... 3.105.56.101
Connecting to rest-aus.bullhornstaffing.com (rest-aus.bullhornstaffing.com)|3.105.56.101|:443... connected.
OpenSSL: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
Unable to establish SSL connection.

curl (verbose)

*   Trying 3.105.56.101:443...
* Connected to rest-aus.bullhornstaffing.com (3.105.56.101) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.2 (OUT), TLS alert, handshake failure (552):
* error:0A000152:SSL routines::unsafe legacy renegotiation disabled
* Closing connection 0
curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation disabled

These commands were performed on a fully patched PopOS 22-04 LTS. I think these errors are telling me that the OpenSSL implementation on the client is rejecting the SSL handshake from the server due to a legacy (unsafe) protocol.

[davidbairdala]

Ok, I have had some success. I tried something different. I tried hitting the authorize URL in Chrome, but this time in a new incognito tab. Instead of redirecting to a URL with a code in it, it presented a challenge screen asking to accept or decline the Bullhorn TOS. I clicked accept, and since then my tests have been passing. So it seems the 200 response that the SDK client was getting was actually this TOS acceptance view. I assume it was working in the non-incognito tab because of a cookie or something. In addition, because the SDK was working previously, I assume something happened with the actual account in which the previous acceptance of the TOS was reset maybe?

So I understand that as part of an interactive OAuth flow there would be this Accept/Decline screen in which the user must accept the terms and conditions of the service (once only). I would not expect this response, however, in a non-interactive session, such as when using this SDK - or if it is required, then at least something in the error message that would include:

a) An explanation of why authentication could not be performed ("You have not accepted the terms and conditions...")
a) The URL to the TOS screen so that it can be performed without having someone craft a specific URL, complete with username and password, in order to complete this step.

My other concern is why is it that it was working and then suddenly stopped working, and is this likely to happen again without warning?

[pbearne]

I have seen that problem
it still catches me as well

Paul