http-signature authorization is impossible via ajax request

[geebee]

Hello There,

I am using restify to implement an API layer. The client portion of the code that will consume this API is written in javascript as well (mostly), although not using node.

I am attempting to work through an implementation of Joyent's "HTTP Signature" Authorization header (and if this issue belongs there, my apologies, and please just let me know) and am unable to have restify succeed in parsing the authorization header without the Date header being present as well. I know from reading the docs, that the Date header is pretty much the only thing you actually need, so here comes my problem...

You cannot send a date header in an XMLHttpRequest from the client side (ie: in the browser)... Chrome says "Refused to set unsafe header 'Date'", and any attempts at working around this (for example by still including a UTC date format string that is sha-256 hashed and base64 encoded results in the following exception being returned as a response by restify:

{"code":"InvalidHeader","message":"Authorization header invalid: date was not in the request"}

My further research (http://www.w3.org/TR/XMLHttpRequest2/#the-setrequestheader-method) indicates that you cannot in fact expect to be able to set the Date header via an XMLHttpRequest.

With that said, my request would be to remove the limitation on requiring a date header, or provide some other sort of work around.

Thanks very much for your time

** Migrated from: restify/node-restify#204 **

[mcavage]

Hi,

Sorry for the lag, but carrying over from the restify board, I will make an amendment to the spec and client library next week that allows an x-date header to be used instead of date (i.e., it will be an either/or - as we'll need to deal with conflicts).

[geebee]

No problem at all.

My thinking was also that if x-date was set, Date would be ignored (exactly as the amazon rest authentication does with the x-amz-date header. Seems like we're on the same page.

You're updating both the client library and the parser? I could throw something together and make a pull request too if you'd like.

[mcavage]

Yes, I was going to update the parser and construction libraries. I was
probably going to enforce that the skew between x-date and date is some
reasonable size, and make sure x-date is within the configured clock skew
for delay. I'm more than happy to take a PR ;)

On Fri, Sep 7, 2012 at 2:15 PM, geebee notifications@github.com wrote:

No problem at all.

My thinking was also that if x-date was set, Date would be ignored
(exactly as the amazon rest authentication does with the x-amz-date header.
Seems like we're on the same page.

You're updating both the client library and the parser? I could throw
something together and make a pull request top if you'd like.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-8379193.

[geebee]

Issued a pull request with my solution (#6).

The idea was to allow x-date to be used in place of date in situations where date is not a header the client can set.

This was accomplished by checking for the existence of the x-date header, and if it does exist, replacing the value of the date header with the value from the x-date header.

In this way, no additional changes are required to the parsing library, and the requirements of enforcing the same clock skew as normal, and having x-date take priority over date if both are set are both met.

If you like the PR I sent, once merged, I'll close the issue. If you'd prefer another solution, just let me know.

[mcavage]

I haven't looked at the code yet, but I saw your comment, and yes, I agree
that sending x-date but saying you sent date (client) is kind of janky-
is the PR setup such that the client still has to do that, or did you fix
it?

What I think we probably want is the client to always send what it needs to
send, and not fudge it (so say x-date). Server-side, with the required
validation headers, we either need to special case date and say "that
also means you can send x-date", or preferably, allow the required
headers to be slightly more complex such that you can pass in "sets" that
are logical OR. I.e., currently everything is an AND, but this would be an
extra dimension.

Thoughts?

On Sat, Sep 8, 2012 at 8:48 AM, geebee notifications@github.com wrote:

Issued a pull request with my solution (
#5).

The idea was to allow x-date to be used in place of date in situations
where date is not a header the client can set.

This was accomplished by checking for the existence of the x-date header,
and if it does exist, replacing the value of the date header with the
value from the x-date header.

In this way, no additional changes are required to the parsing library,
and the requirements of enforcing the same clock skew as normal, and having
x-date take priority over date if both are set are both met.

If you like the PR I sent, once merged, I'll close the issue. If you'd
prefer another solution, just let me know.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-8388851.

[geebee]

So, currently the PR just does an if in the few places where it used to specifically say date that says if x-date is present, ignore date (as opposed to 'overloading' date with the value of x-date). This makes the client reasonable again in that:

• if you send date only, date is used
• if you send date and x-date, x-date is used
• if you send x-date only, x-date is used.
  All 3 scenarios work as expected from the client side (the PR only covers the parser though).

I really like the idea of expanding it to be a logical OR, but that is certainly a larger scope than this original bug. I think based on the fact that this whole standard is designed to be flexible, allowing slightly more complicated logical 'required header' definitions would be useful.

I'd be happy to take a stab at something, although if you do get a chance to take a look at this interim solution until one of us has time to make the larger change, I think it's probably still worth it.

[mcavage]

Yeah that sounds right. I looked at the code, simple enough. I'll take it and put the more sophisticated thing on the backburner for now.

[geebee]

Apologies for the delay, thanks for accepting, figured simpler was better for now. Thanks a lot for your time!