I have run base64 encoding on various scenarios for a few years and have never had any issues with base64 encoding. There are no invalid characters as the error messages indicate. Any thoughts, please?
Thank you in advance
I have run base64 encoding on various scenarios for a few years and have never had any issues with base64 encoding. There are no invalid characters as the error messages indicate. Any thoughts, please?
Thank you in advance
can you show the error message. Try to encode the string with an online base64 encoder and see if it encodes out there.
You could try to put the string in notepad++ or some text editor that could see hidden chars and see if it has any hidden chars are int he string.
Is this affecting all the strings you are trying to encode or is it only this string that is affected ?
Thanks for that suggestion - I did that and found no hidden characters.
Some strings are being encoded correctly and some are not. Ive compared them side by side & don’t see any material differences (apart from different data of course) but both the successful & the failed strings contain the same characters. Ive spent a lot of hours on this. I have to resolve this asap - Thanks for assiting
Could you put on here a successful string and the string that failed?
We have the same issues.
Our temporary workaround is to use an already base64 encoded string (we encode it somewhere else), then our scenario works fine.
But this is far from ideal.
An example of a character that is failing in the encoding is : ≥ .
Thanks for taking a look at this!
You will need to use the function encodeURL first, then do the base64 encoding.
Example:
{{base64(encodeURL("≥y6tyrt"))}}
I’m in the exactly same situation.
I’m trying to get a App connector to behave well. We are using at key for basic auth like this:
Basic auth username: [Key]
In our case we use this key: 4ed.737f3541.pf2bRjQ_faEe5Y1gF-wn8Lw3-r8uVC8ploQKaY0DSYA
when I test in Postman, the [key] are converted to: NGVkLjczN2YzNTQxLnBmMmJSalFfZmFFZTVZMWdGLXduOEx3My1yOHVWQzhwbG9RS2FZMERTWUE6
but, when I process it through Make, the last character is set as = …
NGVkLjczN2YzNTQxLnBmMmJSalFfZmFFZTVZMWdGLXduOEx3My1yOHVWQzhwbG9RS2FZMERTWUE=
I tried an online base64 converter which actually gave me the same result. Then I turned to add the encodeURL to the equation, but the result are the same. What I did in the connector looks like this:
"authorization": "Basic {{base64(encodeURL(connection.key))}}"
For the fun of it, here’s what I tried:
Our test key: 4ed.737f3541.pf2bRjQ_faEe5Y1gF-wn8Lw3-r8uVC8ploQKaY0DSYA
base64:
{{base64(“4ed.737f3541.pf2bRjQ_faEe5Y1gF-wn8Lw3-r8uVC8ploQKaY0DSYA”)}}
The key:
base64 and encodeURL:
{{base64(encodeURL(“4ed.737f3541.pf2bRjQ_faEe5Y1gF-wn8Lw3-r8uVC8ploQKaY0DSYA”))}}
and the result:
*
So, the solution adding the encodeURL don’t make any different in my scenario…
Any suggestions ?
unless you add the authorization to the header (which is an un-secure option)
you can’t add any functions within the authorization flow.
I would advise you to both encodeurl() and base64() in an encoder outside Make and then paste the results in the auth key within Make.
(or, you could set it inside make, within a variable and copy to results to the auth flow)
That’s how I did it and it works.