Malformed Authorization HTTP Header

1

Hi Arron,

The “Malformed Authorization HTTP Header” message is only sent if there is
an Authorization header set but it’s format doesn’t match Bearer TOKEN or
OAuth TOKEN. A different message is sent if the Authorization header is
blank or if TOKEN has been extracted from the header but isn’t found in the
database.

Your code above looks fine - I don’t think you would see the Malformed
Authorization HTTP Header message even if self.accessToken was null. Could
it be that something else is modifying the header before it’s sent? Any
extra spaces added before or after the Bearer part would cause the
Malformed message to be sent.

I would suggest pointing your code at http://httpbin.org/ and see what
headers it’s actually sending.

Kind regards,

GraemeOn 14 November 2012 16:54, ArronKing arron.king@arrowdesign.co.uk wrote:

Hi

I’m having a few intermittent problems with a widget I’m building. It’s
using v2 of the API and the initial refresh token is generated by a web
application. However, I’ve hit a stumbling block and have tried everything
I can think of. The widget uses the refresh token to generate an access
token (which works ok), but then it calls v2/users/me - this is where I am
returned the error.

I keep getting ‘Malformed Authorization HTTP Header’ errors back; it’s
worked a few times but I’ve not changed any code (hence the intermittence!).

The token is fine as I am able to use the same one within CURL. I’m also
looking at the headers in generates and they seem to be fine;
‘Authorization: Bearer TOKEN’. As a debugging tool I’ve managed to run the
widget in several browsers and Google Chrome works fine - the request comes
back fine. But in Safari I get the ‘Malformed Authorization HTTP Header’;
which makes sense as the widgets run in Safari. But also adds to the
confusion as I would expect the browser to display the same behaviour.

Here’s the ajax call exactly as it is in the widget (it’s using the
sandbox API and sendType = ‘GET’, sDataType = ‘json’):

    var ajaxSettings = {
        url: this.getApiUrl() + path,
        type: sendType,
        dataType: sDataType,
        success: onSuccess,
        error: onFail,
        headers: {
            'Authorization': 'Bearer ' + self.accessToken,
            'Content-Type': 'application/json',
            'Accept': 'application/json'
        }
    };

    $.ajax(ajaxSettings);

I guess my question is; is there anything obvious I’m doing wrong? Also
are you able to shed some light on the problem (perhaps from your end why
the error is being returned?)

If you need any further information please let me know.

Thanks in advance

Arron

–
You received this message because you are subscribed to the Google Groups
“FreeAgent API” group.
To view this discussion on the web visit
https://groups.google.com/d/msg/freeagent_api/-/R-0Z1HNCulUJ.
To post to this group, send email to freeagent_api@googlegroups.com.
To unsubscribe from this group, send email to
freeagent_api+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/freeagent_api?hl=en.

Graeme Boyd
Senior Software Engineer

Web. freeagent.com http://www.freeagent.com/ Blog. The FreeAgent Blog - FreeAgent
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
FreeAgent | Edinburgh

40 Torphichen Street, Edinburgh, EH3 8JB
FreeAgent Central Ltd. Registered in sunny Scotland SC316774

2

Just an update on this; I couldn’t find a way to get this working in Safari
(I couldn’t find where it issue was being caused).

Because the code runs as a Widget it’s granted some higher permissions -
such as executing system calls. I created a class that wraps around a curl
call; which did resolve the problems.

However, if you need to use Safari then the only other solution I managed
to get working was to send the requests via another server (i.e. the server
makes the request to FreeAgent and then sends the response to jQuery).

Hope this helps someone.On Monday, November 19, 2012 9:59:38 PM UTC, ArronKing wrote:

Hi Graeme

Thanks for your reply - I appreciate you taking time to point me in the
right direction!

Unfortunately, I’ve spent a few more days trying to get to the bottom of
the issue and I cannot resolve it. I tried the httpbin.org trick and the
headers looked ok; so I went further and wrote a basic PHP script to dump
the headers out exactly as they are (I guess they still get processed by
the web server however); this is the output I get from Safari vs. Chrome:

Safari:

array(9) {

[“Host”]=>

string(15) “sigma.localhost”

[“User-Agent”]=>

string(119) “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2)
AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17”

[“Accept”]=>

string(16) “application/json”

[“Accept-Encoding”]=>

string(17) “gzip,deflate,sdch”

[“Accept-Language”]=>

string(14) “en-US,en;q=0.8”

[“Authorization”]=>

string(48) “Bearer 1_cpNUO6OpHGczdz2IG4BN2u9wcpzrfAwhbePW7ac”

[“Accept-Charset”]=>

string(30) “ISO-8859-1,utf-8;q=0.7,*;q=0.3”

[“Content-Type”]=>

string(16) “application/json”

[“Connection”]=>

string(10) “keep-alive”

}

Chrome:

array(9) {

[“Host”]=>

string(15) “sigma.localhost”

[“Connection”]=>

string(10) “keep-alive”

[“Accept-Encoding”]=>

string(17) “gzip,deflate,sdch”

[“Accept-Language”]=>

string(14) “en-US,en;q=0.8”

[“Authorization”]=>

string(48) “Bearer 11vs6n3PuH4GaToAcGNYLAb3fsoq20SizCR6N7FCM”

[“Accept-Charset”]=>

string(30) “ISO-8859-1,utf-8;q=0.7,*;q=0.3”

[“User-Agent”]=>

string(119) “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2)
AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11”

[“Content-Type”]=>

string(16) “application/json”

[“Accept”]=>

string(16) “application/json”
}

(I changed swapped a letter in the token so they are no longer valid)

I noticed that Safari was sending a few additional headers to Chrome
additionally so set those headers manually in jQuery so both browsers sent
exactly the same headers - but Safari is still getting the malformed
Authorization header (and therefore the widget). As mentioned before, I’m
guessing the web server does some additional processing on the headers - so
I’m going to set up an Nginx server and rails script to output the headers
(I think this is what you guys use?) and see if there is any difference
that way.

I was wondering is there any logging at your end; could I give you a token
either the refresh token or access token it’s attempting to use to help
identify anything?

Thanks again.

Arron

On Friday, November 16, 2012 11:32:42 AM UTC, Graeme Boyd wrote:

Hi Arron,

The “Malformed Authorization HTTP Header” message is only sent if there
is an Authorization header set but it’s format doesn’t match Bearer TOKEN
or OAuth TOKEN. A different message is sent if the Authorization header is
blank or if TOKEN has been extracted from the header but isn’t found in the
database.

Your code above looks fine - I don’t think you would see the Malformed
Authorization HTTP Header message even if self.accessToken was null. Could
it be that something else is modifying the header before it’s sent? Any
extra spaces added before or after the Bearer part would cause the
Malformed message to be sent.

I would suggest pointing your code at http://httpbin.org/ and see what
headers it’s actually sending.

Kind regards,

Graeme

On 14 November 2012 16:54, ArronKing arron...@arrowdesign.co.uk wrote:

Hi

I’m having a few intermittent problems with a widget I’m building. It’s
using v2 of the API and the initial refresh token is generated by a web
application. However, I’ve hit a stumbling block and have tried everything
I can think of. The widget uses the refresh token to generate an access
token (which works ok), but then it calls v2/users/me - this is where I am
returned the error.

I keep getting ‘Malformed Authorization HTTP Header’ errors back; it’s
worked a few times but I’ve not changed any code (hence the intermittence!).

The token is fine as I am able to use the same one within CURL. I’m also
looking at the headers in generates and they seem to be fine;
‘Authorization: Bearer TOKEN’. As a debugging tool I’ve managed to run the
widget in several browsers and Google Chrome works fine - the request comes
back fine. But in Safari I get the ‘Malformed Authorization HTTP Header’;
which makes sense as the widgets run in Safari. But also adds to the
confusion as I would expect the browser to display the same behaviour.

Here’s the ajax call exactly as it is in the widget (it’s using the
sandbox API and sendType = ‘GET’, sDataType = ‘json’):

    var ajaxSettings = {
        url: this.getApiUrl() + path,
        type: sendType,
        dataType: sDataType,
        success: onSuccess,
        error: onFail,
        headers: {
            'Authorization': 'Bearer ' + self.accessToken,
            'Content-Type': 'application/json',
            'Accept': 'application/json'
        }
    };
    
    $.ajax(ajaxSettings);

I guess my question is; is there anything obvious I’m doing wrong? Also
are you able to shed some light on the problem (perhaps from your end why
the error is being returned?)

If you need any further information please let me know.

Thanks in advance

Arron

–
You received this message because you are subscribed to the Google
Groups “FreeAgent API” group.
To view this discussion on the web visit
https://groups.google.com/d/msg/freeagent_api/-/R-0Z1HNCulUJ.
To post to this group, send email to freeag...@googlegroups.com.
To unsubscribe from this group, send email to
freeagent_ap...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/freeagent_api?hl=en.

–
Graeme Boyd
Senior Software Engineer

Web. freeagent.com http://www.freeagent.com/ Blog. The FreeAgent Blog - FreeAgent
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
FreeAgent | Edinburgh

40 Torphichen Street, Edinburgh, EH3 8JB
FreeAgent Central Ltd. Registered in sunny Scotland SC316774

3

Hi Arron,

It sounds like you could be hitting a Same Origin or browser security
problem Google Code Archive - Long-term storage for Google Code Project Hosting..
Did you try running your code with security disabled?

open -a ‘/Applications/Safari.app’ --args --disable-web-security

or

C:\Program Files\Safari\Safari.exe --disable-web-security

Kind regards,

GraemeOn 27 November 2012 14:48, ArronKing arron.king@arrowdesign.co.uk wrote:

Just an update on this; I couldn’t find a way to get this working in
Safari (I couldn’t find where it issue was being caused).

Because the code runs as a Widget it’s granted some higher permissions -
such as executing system calls. I created a class that wraps around a curl
call; which did resolve the problems.

However, if you need to use Safari then the only other solution I managed
to get working was to send the requests via another server (i.e. the server
makes the request to FreeAgent and then sends the response to jQuery).

Hope this helps someone.

On Monday, November 19, 2012 9:59:38 PM UTC, ArronKing wrote:

Hi Graeme

Thanks for your reply - I appreciate you taking time to point me in the
right direction!

Unfortunately, I’ve spent a few more days trying to get to the bottom of
the issue and I cannot resolve it. I tried the httpbin.org trick and the
headers looked ok; so I went further and wrote a basic PHP script to dump
the headers out exactly as they are (I guess they still get processed by
the web server however); this is the output I get from Safari vs. Chrome:

Safari:

array(9) {

[“Host”]=>

string(15) “sigma.localhost”

[“User-Agent”]=>

string(119) “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2)
AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17”

[“Accept”]=>

string(16) “application/json”

[“Accept-Encoding”]=>

string(17) “gzip,deflate,sdch”

[“Accept-Language”]=>

string(14) “en-US,en;q=0.8”

[“Authorization”]=>

string(48) “Bearer 1_cpNUO6OpHGczdz2IG4BN2u9wcpzrfAwhbePW7ac”

[“Accept-Charset”]=>

string(30) “ISO-8859-1,utf-8;q=0.7,*;q=0.**3”

[“Content-Type”]=>

string(16) “application/json”

[“Connection”]=>

string(10) “keep-alive”

}

Chrome:

array(9) {

[“Host”]=>

string(15) “sigma.localhost”

[“Connection”]=>

string(10) “keep-alive”

[“Accept-Encoding”]=>

string(17) “gzip,deflate,sdch”

[“Accept-Language”]=>

string(14) “en-US,en;q=0.8”

[“Authorization”]=>

string(48) “Bearer 11vs6n3PuH4GaToAcGNYLAb3fsoq20**SizCR6N7FCM”

[“Accept-Charset”]=>

string(30) “ISO-8859-1,utf-8;q=0.7,*;q=0.**3”

[“User-Agent”]=>

string(119) “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2)
AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11”

[“Content-Type”]=>

string(16) “application/json”

[“Accept”]=>

string(16) “application/json”
}

(I changed swapped a letter in the token so they are no longer valid)

I noticed that Safari was sending a few additional headers to Chrome
additionally so set those headers manually in jQuery so both browsers sent
exactly the same headers - but Safari is still getting the malformed
Authorization header (and therefore the widget). As mentioned before, I’m
guessing the web server does some additional processing on the headers - so
I’m going to set up an Nginx server and rails script to output the headers
(I think this is what you guys use?) and see if there is any difference
that way.

I was wondering is there any logging at your end; could I give you a
token either the refresh token or access token it’s attempting to use to
help identify anything?

Thanks again.

Arron

On Friday, November 16, 2012 11:32:42 AM UTC, Graeme Boyd wrote:

Hi Arron,

The “Malformed Authorization HTTP Header” message is only sent if there
is an Authorization header set but it’s format doesn’t match Bearer TOKEN
or OAuth TOKEN. A different message is sent if the Authorization header is
blank or if TOKEN has been extracted from the header but isn’t found in the
database.

Your code above looks fine - I don’t think you would see the Malformed
Authorization HTTP Header message even if self.accessToken was null. Could
it be that something else is modifying the header before it’s sent? Any
extra spaces added before or after the Bearer part would cause the
Malformed message to be sent.

I would suggest pointing your code at http://httpbin.org/ and see what
headers it’s actually sending.

Kind regards,

Graeme

On 14 November 2012 16:54, ArronKing arron...@arrowdesign.co.uk wrote:

Hi

I’m having a few intermittent problems with a widget I’m building. It’s
using v2 of the API and the initial refresh token is generated by a web
application. However, I’ve hit a stumbling block and have tried everything
I can think of. The widget uses the refresh token to generate an access
token (which works ok), but then it calls v2/users/me - this is where I am
returned the error.

I keep getting ‘Malformed Authorization HTTP Header’ errors back; it’s
worked a few times but I’ve not changed any code (hence the intermittence!).

The token is fine as I am able to use the same one within CURL. I’m
also looking at the headers in generates and they seem to be fine;
‘Authorization: Bearer TOKEN’. As a debugging tool I’ve managed to run the
widget in several browsers and Google Chrome works fine - the request comes
back fine. But in Safari I get the ‘Malformed Authorization HTTP Header’;
which makes sense as the widgets run in Safari. But also adds to the
confusion as I would expect the browser to display the same behaviour.

Here’s the ajax call exactly as it is in the widget (it’s using the
sandbox API and sendType = ‘GET’, sDataType = ‘json’):

    var ajaxSettings = {
        url: this.getApiUrl() + path,
        type: sendType,
        dataType: sDataType,
        success: onSuccess,
        error: onFail,
        headers: {
            'Authorization': 'Bearer ' + self.accessToken,
            'Content-Type': 'application/json',
            'Accept': 'application/json'
        }
    };

    $.ajax(ajaxSettings);

I guess my question is; is there anything obvious I’m doing wrong? Also
are you able to shed some light on the problem (perhaps from your end why
the error is being returned?)

If you need any further information please let me know.

Thanks in advance

Arron

–
You received this message because you are subscribed to the Google
Groups “FreeAgent API” group.
To view this discussion on the web visit https://groups.google.com/d/**
msg/freeagent_api/-/R-**0Z1HNCulUJhttps://groups.google.com/d/msg/freeagent_api/-/R-0Z1HNCulUJ
.
To post to this group, send email to freeag...@googlegroups.com.
To unsubscribe from this group, send email to
freeagent_ap…@googlegroups.com.
For more options, visit this group at http://groups.google.com/
group/freeagent_api?hl=enhttp://groups.google.com/group/freeagent_api?hl=en
.

–
Graeme Boyd
Senior Software Engineer

Web. freeagent.com http://www.freeagent.com/ Blog.
The FreeAgent Blog - FreeAgent
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
Facebook http://facebook.com/freeagentapp

40 Torphichen Street, Edinburgh, EH3 8JB
FreeAgent Central Ltd. Registered in sunny Scotland SC316774

–
You received this message because you are subscribed to the Google Groups
“FreeAgent API” group.
To view this discussion on the web visit
https://groups.google.com/d/msg/freeagent_api/-/Bc6slgV-B2wJ.

To post to this group, send email to freeagent_api@googlegroups.com.
To unsubscribe from this group, send email to
freeagent_api+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/freeagent_api?hl=en.

Graeme Boyd
Senior Software Engineer

Web. freeagent.com http://www.freeagent.com/ Blog. The FreeAgent Blog - FreeAgent
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
FreeAgent | Edinburgh

40 Torphichen Street, Edinburgh, EH3 8JB
FreeAgent Central Ltd. Registered in sunny Scotland SC316774