Problem with authorization header

After boiling down a problem to it’s simplest form I used the example from the docs and run my requests through ngrok to prove my theory.

When using the encodeBase64 on the sbId and sbkey the
request fails to reach ngrok and I get a 400 Bad request … (not sure where that comes from)
if I remove the encoding and send just sbId + “:” + sbKey the request displays in ngrok

[code]dim sbId As String =“ZABejjVi5nGv60shPI4oEAStnjGsCvziIFCquP8KsP2On8J6V4z”
dim sbKey As String=“ZbmJAXkMiUjszfyvdBvbbw4A13Dqu0Rh8XQxN4MGM”
dim authString As String =EncodeBase64(sbId + “:” + sbKey)

Dim form As Dictionary
Dim socket1 As New SecureSock
// create and populate the form object
form = New Dictionary
form.Value(“firstname”) = “Jim”
form.Value(“lastname”) = “Brown”
socket1.SetRequestHeader(“Authorization”, "Basic " + authString) // (sbId + “:” + sbKey))//+
// setup the socket to POST the form
socket1.SetFormData(form)
dim url as String
url=“https://7d757d0cd.ngrok.io
dim results as string= socket1.post(url,10)[/code]

Any help would be greatly appreciated.

TIA
TK

EncodeBase64 wraps long lines by inserting an end-of-line character, but HTTP headers cannot contain an end-of-line (hence 400 Bad Request). Try:

dim authString As String =EncodeBase64(sbId + ":" + sbKey) authString = ReplaceLineEndings(authString, "")

I suppose the above is a simple typo here…

Xojo has a second parameter to EncodeBase64 for the number of characters per ‘line’. Use 0 for no breaks.

dim authString As String = EncodeBase64(sbId, 0) + ":" + EncodeBase64(sbKey, 0)

Basic ‘Auth’ also won’t work if you encode the ‘:’

This is incorrect. RequestHeader(“Authorization”) = “Basic” + EncodeBase64(Username + “:” + Password, 0) is the correct implementation.

Thanks!

Looks like this should at least get passed that roadblock.

Just curious about where the 400 comes from, (Is that a server or httpsock generated error?)

That is the server. 400 means “bad request” but it really could mean anything. 400 is often used for “general error caused by the client” and 500 is usually “general error caused by the server.”

I realized this could be misleading when I said it’s the server, then that 400 is a client error. So just to clarify, 400 is the server saying “I’d like to fulfill this request, but I can’t because what you requested doesn’t make sense.”

WHY it doesn’t make sense is the mystery.

Apologies, I shouldn’t post from memory when I’m dead tired :slight_smile:
It’s been a couple of years since I had to implement that.

Unexpected line breaks in the header probably make an unusable request.

You’re likely correct, but my description was meant as more of a general meaning of a 400 status.