Directly converting String to Base 64

Good day Outsystems Community,

I have a REST API that requires basic authentication however, we cannot pass the user and password dynamically since the fields provided by Outsystems are static in nature:We searched for answers in this forum and we found this https://www.outsystems.com/forums/discussion/22162/set-rest-api-basic-authentication/. The solution seems fine however, I am a bit worried about the accuracy of the conversion because we have to convert the String to Binary first and then afterwards convert it to Base 64. Is there a way to directly convert the String to Base64 without converting it to Binary first?

Additionally, the already existing Basic Authentication on Outsystems works even without manually converting the String to Base64, the only issue that i have is that the values passed are static. Is there any other way to pass values dynamically so we can avoid converting manually?


Regards,

Eyre Sapuay

Hi Eyre Sapuay,

The solution in that post is correct.

If you can guarantee your password only contains characters within the US-ASCII character set, you don't need to encode it in any way, it is already in an acceptable format, as HTTP field contents can only be US-ASCII. If you want to represent other character sets (like Unicode) you will need to use MIME-supported encoding mechanisms: either Quoted-Printable or Base64.

Base64 is an encoding mechanism for binary data, that transforms each 6-bits of data into an ASCII printable character, but in order to guarantee this binary data can be understood from both the client (consuming the REST API) and the server (exposing the REST API), they need to agree on a specific character encoding (like ISO-8859-2 or UTF-8, for instance) and that is what TextToBinaryData allows you to do: the same L character would be represented as two bytes in UTF-8 (C5 81) and one byte in ISO-8859-2 (A3).

OutSystems has to do the same sort of thing behind the scenes when you provide it directly with Basic Authentication credentials, as that is part of the HTTP protocol being used.


Jorge Martins wrote:

Hi Eyre Sapuay,

The solution in that post is correct.

If you can guarantee your password only contains characters within the US-ASCII character set, you don't need to encode it in any way, it is already in an acceptable format, as HTTP field contents can only be US-ASCII. If you want to represent other character sets (like Unicode) you will need to use MIME-supported encoding mechanisms: either Quoted-Printable or Base64.

Base64 is an encoding mechanism for binary data, that transforms each 6-bits of data into an ASCII printable character, but in order to guarantee this binary data can be understood from both the client (consuming the REST API) and the server (exposing the REST API), they need to agree on a specific character encoding (like ISO-8859-2 or UTF-8, for instance) and that is what TextToBinaryData allows you to do: the same L character would be represented as two bytes in UTF-8 (C5 81) and one byte in ISO-8859-2 (A3).

OutSystems has to do the same sort of thing behind the scenes when you provide it directly with Basic Authentication credentials, as that is part of the HTTP protocol being used.


Hello Jorge,

Thank you so much for the explanation. I understand it now why on Outsystems we have to convert it into Binary data then Base 64. 

So does this mean the only way to pass a dynamic username and password is by following the solution on the other post? 


Also, I would like to ask why this part here is static: 

Is there any particular reason why?



Eyrejean Liezle Sapuay wrote:

So does this mean the only way to pass a dynamic username and password is by following the solution on the other post? 

As far as I know, yes.

Also, I would like to ask why this part here is static: 

Is there any particular reason why?

I don't know, but you can vote for this idea.


Jorge Martins wrote:

Eyrejean Liezle Sapuay wrote:

So does this mean the only way to pass a dynamic username and password is by following the solution on the other post? 

As far as I know, yes.

Also, I would like to ask why this part here is static: 

Is there any particular reason why?

I don't know, but you can vote for this idea.


Okay thanks! I'll be sure to vote for that idea but for the meantime, my team will use the javascript method.