Search code examples
restauthenticationcookiesversionone

Authentication not working with VersionOne REST API

Ok, I have a technical question here. We've developed an integration component in XStudio so that we can pick VersionOne's "Stories" (as "Requirements" in XStudio) and "Defects" (as "Bugs" in XStudio). This way you can execute your tests and manage the results, metrics etc. from XStudio but also manage the complete traceability matrix (Products -> Requirements -> Tests -> Test campaigns -> Bugs) in XStudio using VersionOne's items. We handle the links our side.

To do this, we implemented the connector using VersionOne's REST API. Everything works great! very fast etc.

We tested it using a free server from VersionOne with no problem. Our Java code manage cookies so that it authenticates using "Basic Authentication" protocol, we retrieve the cookie from VersionOne, store it in the local CookieStore and provide that cookie in the next requests so that we do not have to authenticate again and again. All this worked fine from our side.

The content looks like this:
{X-Instart-Request-ID=[7405870175418545839:SEN01-NPPRY09:1396448658:44], 
null=[HTTP/1.1 200 OK], 
Date=[Wed, 02 Apr 2014 14:24:17 GMT], 
Content-Length=[16063], 
Expires=[-1], 
VersionOne=[Ultimate/14.0.7.6706; Scrum], 
Set-Cookie=[.V1.Ticket.ncnuaaa=HFZlcnNpb25PbmUuV2ViLkF1dGhlbnRpY2F0b3LqgwAAB1hTdHVkaW+CjqLWdBzRCP8/N/R1KMorEByFu31RuGY+eqVCi1FHvTE=; path=/; HttpOnly], 
Connection=[keep-alive], 
Content-Type=[text/xml; charset=utf-8], 
Server=[Microsoft-IIS/8.0], 
Pragma=[no-cache], 
Cache-Control=[no-cache]}

BUT... when we run our code on our client's environment, we don't get the original cookie for any reason !?

{cache-control=[no-cache], 
content-type=[text/xml; charset=utf-8], 
null=[HTTP/1.1 200 OK], expires=[-1], 
content-length=[16063], 
server=[Microsoft-IIS/8.0], 
date=[Wed, 02 Apr 2014 12:34:08 GMT], 
pragma=[no-cache]}

When our code get the header fields from the connection and we try to get the "Set-Cookie" field it can't find it and a popup is automatically display.

Map<String, List<String>> headerFields = connection.getHeaderFields();
List<String> cookiesHeader = headerFields.get("Set-Cookie");

The popup is asking to authenticate (by the way on "www6.v1host.com/192.33.31.50" while it was more expected "www6.v1host.com/abcded" - maybe ther's a clue here?).

If we authenticate on your server here everything continues normally and everything works ok. But we shouldn't have to authenticate again as we do it in the connection before:

String plainAuth = username + ":" + password;
encodedAuth = ("Basic " + new String(Base64.encode(plainAuth.getBytes()))).replaceAll("\n", "");
connection.setRequestMethod("GET");
connection.setRequestProperty("Authorization", encodedAuth);
connection.setRequestProperty("Connection", "keep-alive");

So, not sure if this is because the authentication is not working (it would explain why the cookie is not returned and the popup ask the user to explicitly authenticate) or there is something specific in terms of cookie management...

Do you have any idea what could be going on here?

This code is working well on many different other REST APIs using Basic Auth. and Cookies. Thanks in advance,

Solution

  • It sounds like you work for XQual, the developers of XStudio. If so, please reach out to me. We are always happy to list another integration.

    Assuming this is intended to work for more than just 1 customer, I have a couple pieces of advice:

    • Provide a meaningful user agent header. This helps us be pro-active with your integration. The header is useful even for custom, one-off products, but is even more important when other vendors are involved.
    • Use OAuth2 for authentication. There are plenty of good libraries for OAuth2 in Java. We have an upcoming blog post where we show how it can be done with Apache Oltu.

    To your specific question, I have some hunches:

    • You might be expecting too much about how VersionOne is deployed. VersionOne is offered both on-premise and on-demand. Your customer may be putting "192.33.31.50" into the configuration to represent on-premise, while you are expecting an instance name for on-demand. Also beware that not all on-demand instances are on "www6".
    • If on-premise, VersionOne also offers an installation option for Windows Integrated Authentication. In which case, you may not be getting the headers you were expecting. This is one reason I recommended OAuth2 above. OAuth2 is always available for API calls, regardless of the user authentication mechanism.

    To better diagnose, could you share some code that shows how you construct the request URL?