Bearer vs bearer

Just a little niggle…

When you obtain an access token, you get this back as one of the lines;

“token_type”:“bearer”,

Now, the word “bearer” in the Authorization header is actually case
sensitive and needs to be “Bearer”.

So if you don’t like hard-coded strings and do something like “AddHeader…
token.token_type…” then you will get
{“errors”:{“error”:{“message”:“Malformed Authorization HTTP header. Should
be of form “Authorization: Bearer TOKEN””}}}

It’s easy enough to work around, just feels a bit inconsistent and odd.

Hi,

I understand the compatibility, might just be worth clarifying in the doc.
I haven’t read RFC6750 but from what you are saying, it sounds like you should accept bearer, and Bearer and BEARER in the header? At the moment you only accept Bearer. I don’t think it would break anything if you were more relaxed about what you accept?

In any case, it’s just a minor niggle and probably not worth spending time on :slight_smile:

Frans

Hi Frans,

We probably should be returning “token_type”:“Bearer” to conform with
RFC6750 and if I was reimplementing OAuth that’s what I’d return. We’re
not alone in returning a lower case token_type field (for example, Github
and Harvest do the same) and RFC6749 says that the token_type field is case
insensitive so we’re not completely incorrect here. Unfortunately I can’t
risk breaking apps by changing the case.

Kind regards,

GraemeOn 13 January 2013 21:45, Frans Lytzen franslytzen@gmail.com wrote:

Just a little niggle…

When you obtain an access token, you get this back as one of the lines;

“token_type”:“bearer”,

Now, the word “bearer” in the Authorization header is actually case
sensitive and needs to be “Bearer”.

So if you don’t like hard-coded strings and do something like “AddHeader…
token.token_type…” then you will get
{“errors”:{“error”:{“message”:“Malformed Authorization HTTP header.
Should be of form “Authorization: Bearer TOKEN””}}}

It’s easy enough to work around, just feels a bit inconsistent and odd.


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/-/VwDdLE-CF00J.
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. freeagent.com/blog
Twitter. @freeagent https://twitter.com/#!/freeagent Facebook.
facebook.com/freeagentapp

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