add ability to pass a custom header name

[kilianc]

I will be happy to update the README given some direction from the maintainers 👍

[arekinath]

Would you mind explaining what this feature is for? The spec doesn't really make allowances for the use of other headers, and it seems kinda silly to keep the format that's needed for Authorization (with the leading Signature scheme name) for a custom header to me. If it's exactly the same, is there a reason you can't just use Authorization in your app? Is it because you're trying to combine it with some other form of Authorization use and having trouble using multiple-value headers? (sorry, just guessing here)

[kilianc]

@arekinath

Is it because you're trying to combine it with some other form of Authorization use and having trouble using multiple-value headers?

Indeed, bearer token + http signature see #64

[arekinath]

That makes sense. We pretty regularly use requests with two Authorization headers in our apps -- one for the Bearer token, and another for the Signature. I'm a little hesitant to suggest following suit, as after some reading, I'm pretty sure this is not technically compliant to the HTTP/1.1 RFC (since Authorization is not meant to be a multi-valued/comma-separated header like that, and Signature's use of the auth-param syntax which contains commas also complicates parsing it)... but it does appear to work fine with the node.js HTTP framework and a few others we've tested.

I guess setting the header name like this is the easiest way forward without promoting that. Though, maybe it would be worthwhile to add API for parsing just the auth-params part of a header out (i.e. the key=value section after the Signature scheme), too. I'll file that as a separate bug.

I've made some small changes to satisfy the linter (which is run using make check btw, for future reference) and fix up old node versions (this repo still targets compatibility back to 0.10.x, so Object.assign can't be used). Merged now as 38c1ae7

Thanks!

[kilianc]

@arekinath thanks!

I researched a long ago about this with the same findings about Authorization not allowing multiple values. We adopted signature for our clients to validate events and private data coming in from the wire but only recently we had this problem.

I wrote wrappers to swap x-client-authorization with authorization when checking the signature but one of our clients today wanted to also sign the authorization header which contained a bearer token.

This resulted in failing signature checks and raised the issue.

I agree that the cleaner approach here would be adding parsing logic for multiple values, but I am not particularly excited to diverge from the specs :/

Thanks again for using my commit.

P.S. I published my fork as private module and it's already live working in production so I confirm it works :)

🍻