Hello,
I am trying to use the btoa function in vCO 8.1 to encode a string. I see the btoa function listed as available in the editor, but I'm not actually sure how to use it.
I would assume I could use it like btoa('your_string_here') and it would then return a base64 value? I get an error saying btoa is not defined. I'm sure I just the syntax wrong. Anyone familiar with this?
Thanks!
Hi,
I don't think btoa is available for vRO scripting.
Maybe try something like this: Javascript base64 - Javascript tutorial with example source code
Hope this helps!
Hi,
This is not supported with the native vRO javascript. But you can use the node js 12 script runner and achieve this. You can either create an action (or use a scripting task in the workflow) and use for example the following code which would base64 encrypt a string.
let b64Encoded = Buffer.from('1234').toString('base64');
console.log(b64Encoded);
callback(undefined, b64Encoded);
}
You can make the decoding similarly.
Thanks for the replies!
I know it's possible to do in other languages. I have a python example but since it's a bit of a pain currently to import non-standard libraries I was hoping just to use JavaScript. But now that I think of it I may just create an action to do the encoding in whatever language makes it the easiest and return the value, then reference this action in a main JavaScript action. After testing this, it appears you can't call actions that are written in a different language. It's possible to do this in a workflow, but not an action.
The root of my question really came from the btoa function that populates in the Orchestrator intellisense. It appears to be available, but maybe not usable. See image below:
The Javascript engine used by vRO Web client UI (including intellisense functionality) is not the same engine that vRO server backend uses (Mozilla's Rhino). There are some minor differences between the two engines, so I believe that's the reason why you see stuff like btoa available in the UI but not really available server-side.
In addition to suggestions in previous posts, you also have the following options:
Thanks. That make sense, but it's confusing for sure.
I'll probably copy one of the examples posted.
thanks everyone!
Now that most API calls are REST based btoa and atob (or similar) should be provided without "going through hoops". Having each customer fix this on their side is not providing value. Customers should focus on differation and not implemeting base64 encoding.
Just my two cents.