VMware Cloud Community
JFCooleCC
Contributor
Contributor

Working with REST, Backslashes, and JSON in VCO?

I am working on automating a REST request with an internal system that uses JSON for all request bodies, but I am having trouble with making sure the content inside the JSON is correct with VCO or if I am just doing it wrong.

I typically develop in Powershell 3.0 because I'm more comfortable with it, but I figured with VCO using Javascript I could use it as an exercise to use it more.

The VCO version is 5.5.1, build 1617127.

I have a couple of RESTOperations defined with some custom scripting for creating an APIKey to use in future requests, and also doing a check on whether said API key is still valid.  They look like this in the scriptable task:

// create custom object to house username/password

authObj = new Object()

authObj.Username = arg_user

authObj.Password = arg_password

// convert that object to a pure JSON variable

authJSON = System.getModule("org.dojotoolkit.dojo.json").serialize(authObj)

I then pass this to the RESTOperation and execute, no problems.

Now I am at the part where I am creating new objects inside the system, which is for SSL Certificate requests (submitting a CSR, CN, etc).

In Powershell, I have no issues with the request using the Invoke-RESTMethod cmdlet so I figured this was an easy conversion.

The API for this PKI system uses backslashes in the path to the folder where the SSL object is stored in the management system.  My variable in Powershell looks like this:

$policybase = "\Root\Policy\Dev Certificates: Issuing CA 2\TEST: Client and Server Auth: 7 days\"

In Powershell I create a hashtable object and populate the values there, and for the request itself I pipeline it to ConvertTo-JSON.  The request goes through, no hitches.

In VCO, I always get a 400 Bad Request.  Here's how I do it in the Scriptable task for the request (with added escape "\" 😞

// define values

var policyDN = "\\Root\\Policy\\Dev Certificates: Issuing CA 2\\TEST: Client and Server Auth: 7 days\\"

// create custom object to house values

var requestObj = new Object()

requestObj.PolicyDN = policyDN

requestJSON = JSON.stringify(requestObj)

When I dump the variable "policyDN" string out to the System.log() I see this:

DEBUG_policyDN: \Root\Policy\Dev Certificates: Issuing CA 2\TEST: Client and Server Auth: 7 days\

So that looks good, or as expected.

When I dump the "requestJSON" variable to the System.log() it shows this:

DEBUG_requestJSON:  {"PolicyDN":"\\Root\\Policy\\Dev Certificates: Issuing CA 2\\TEST: Client and Server Auth: 7 days\\"}

So I'm thinking the problem with bad request is due to the additional backslash being added at somepoint during the Javascript->Java conversion during the workflow execution.

I tried adding a THIRD backslash to escape those as well, but the strings didn't change when I examined the Debug logs.

I added a FOURTH one and tried again, now the JSON string shows 4 backslashes inside the request.

If I remove the extra slash entirely, the debug output shows no "\" at all, thus creating a malformed request and I still get a 400 error.

Anyone have some tips regarding working with backslashes inside a JSON for VCO?  I have searched communities as well as online looking at JSON docs, but I am either looking for the wrong thing, or am missing something obvious.

If you need any info other than the above novel I am happy to provide it.

0 Kudos
2 Replies
cdecanini_
VMware Employee
VMware Employee

It is normal behavior that JSON.stringify() escapes back slashes.

Can you dump the working powershell JSON body to check if the backslashes are escaped as well or if there is another difference ?

If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you! Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator for vCenter Orchestrator tips and tutorials - @vCOTeam on Twitter
JFCooleCC
Contributor
Contributor

I found the issue.  I was one character off with some whitespace in the query which was causing it to throw its hands up in the air and give no useful error messages.

The requests are going through.  Sorry for the wasted thread.  But I do appreciate your reply! Smiley Happy

0 Kudos