HTTPS REST Plug in encoding special characters VRO 7.3

[timosteppa]

I am running VRO 7.3 with HTTPS-REST Plug-in 2.2.2. Apparently this issue was/is fixed in the latest VRO.

This is what the release note says:

The REST API client does not encode and decode space characters correctly.

• When querying scripting actions by their fully qualified names with the REST API client, the space characters are incorrecly encoded as %2B or a plus (+) character. As a result, the request fails with an Script module not found error message.

But I am still having this issue.

I have two workflows.

1. Authenticating the user so that I get a token to make my REST API calls

2. Using my token to perform other API calls like search for a IP address.

Here is the log that contains my current issue from the 2nd workflow:

This is what the original token looks like:

Here is the javascript. I am pretty sure that the attribute fullUrl is encoding my token to that "%253D%253D" which obviously invalidates the token.

-The only workaround I've found was to hardcode it to the restOperation template, but that defeats the purpose since tokens expire.

Do you guys happen to have a workaround or something?

Any help will be greatly appreciated!

[iiliev]

It seems highly unlikely to me that any authentication service will return authentication tokens looking like XXXXXX%3D%3D

Most probably, the tokens look like XXXXXX== (Base64-encoded data, ending with '=' character(s) if padding is needed). BTW, %3D is encoded '=' character.

So it seems the problem is starting earlier, when you acquire the token.

[timosteppa]

But if I use like the Base64 encoded data, I mean that will change the token which will make it invalid? I mean I'm also using Postman just to make sure that what I have on VRO corresponds with Postman and the API I have.

I did find out that I can just use the replace function and replace the '%3D' with just '=' which works on the first workflow and on Postman with no problem. So I suppose I can just take that variable that is holding my correct token and pass it to my other workflows?

Although, it would be great if fullUrl was not a read-only attribute coz then I can do the replace method before the createRequest method and it would handle it correctly when it spits out the whole thing.

Let me know your thoughts. Much thanks again!

[iiliev]

Using hacks like textual replacement via replace() function is totally wrong approach.

The proper approach is to ensure that the value on line 22 in workflow 'Request Token2' is correct; that is, the value of response.contentAsString should be the plain token value, without any encodings like '=' encoded as %3D (the same value you receive if you execute the login API call using REST client like cURL or Postman). Everything else is problematic.

fullUrl should not be editable, it is plug-in responsibility to construct the proper request URL based on the base URL and request parameters, and the user should not care about lower-level stuff like how the URL query parameters should be encoded.

[timosteppa]

Thanks for your responses. I guess the problem that I have is the fact that even when i get the token from like Postman, it does have those encoding, specifically the "%3D" at the end.

So obviously when i pass it the plain token value in line 22, as soon as request.fullUrl calls it, it breaks.

Or should I contact the API provider about the token issue? That they just have a "real" plain token?

What would you deem as an acceptable solution/workaround?

[iiliev]

First, I would test also with cURL to be absolutely sure that the returned token indeed ends with %3D.

If cURL call also returns encoded token, I would recommend to contact the API provider about it. It looks like a bug in the API, I don't see a use case where you would want a login API to return URL-encoded tokens.

If the provider confirms this is by design, a followup question to them would be why their other API don't work directly with this encoded token. In any case, I would assume that tokens or other data, returned from a given API, can be used in other API by the same provider without requiring additional processing by the user (eg. decoding).

Until the provider fix their API, and assuming the returned token is URL-encoded, an acceptable temporary workaround would be for you to decode it in the scripting, but not using functions like replace() which do a pure textual processing. A better approach is to use specialized URL decoding functions like decodeURIComponent()

[timosteppa]

Thanks for the useful information. I get the same result even with cURL call. The thing is even though the token ends with %3D, all the other API calls do work on Postman and such. Just not VRO when I make a specific call that has the token as a URL parameter.

I did try with the decodeURIComponent() but it wouldn't work on like my 2nd workflow- that's why I brought up the fullUrl comment, because it does the encoding, which is the right thing-but in my case, it breaks it due to the nature of that token as it gets encoded twice, first time as %3D (which is ok, since that's what the API has initally, but then it encodes it again to be able to "read" the "%", that is how it ends up as "%253D", at least that is my interpration as to how it's being read by VRO.

But I do knowthat if they just have a "clean" token from the get-go, no extra "%3D", then the workflows will work perfectly on VRO.

Anyhow-last question. When I get the token from the 1st workflow and I retrieve it as an out parameter, on the 2nd WF, I recieve it as a in parameter variable  from the 1st WF, but as a in-parameter (which makes sense, because the WF has ip address, and token as its parameters). Is it even possible to just get the token from the 1st WF into the 2nd WF without me having to copy and paste that token into the 2nd WF? So like have it be more of an attribute per se. Pretty much automate the 2 workflows, and only have some things that are static like user and pass..

let me know your thoughts and approach! Thanks again!!!

PS: Sorry for the long message.

[iiliev · Accepted solution]

Sure, you can combine the existing workflows 'Request Token2' and 'Test IP' by creating a new workflow (let's say 'Request Token and Test IP'), and inside it add two workflow elements that will invoke the original workflows. After that, in the combined workflow create an attribute of type string to hold the token value, then bind the output parameter myToken from the workflow element 'Request Token2' to this attribute, and also bind this attribute to the input parameter token of the workflow element 'Test IP'.

[timosteppa]

This worked perfectly like a champ!

Long shot here:

I have workflow to add DNS record on our system, its a API POST Request, Some of the fields that the API call needs are the following: “ip”, “dnsView”, “comment”, and “fqdn”. Is it possible to get this values from another WF? We have a WF that spins up a VM and has all of that info.

Logically speaking, from a VRO standpoint, I'm not even sure how to start on that because, it's not like they are URL Parameters, they are just content in the body of the API call...

The WF will work if I input the values manually-but...if it can be automated, why not!

Let me know your thoughts. Thanks again very much!

[iiliev]

You can get the values of dnsView, comment and fqdn as plain strings from the other workflow and then create the request body for the POST request via some Javascript code, using the values of the parameters. Not sure how your workflow to add DNS record is implemented, but there are some methods like RESTHost#createRequest() or RESTHost#executeRequestWithCredentials() that allow you to specify the request body as a string.