The SUPPORTED_METHODS array does not include the PATCH method and gives the following error when trying to sign a request that uses PATCH method:

The method must be "GET" or "POST" or "PUT" or "DELETE" or "HEAD" or "OPTIONS" or "CUSTOM". "PATCH" is not supported.

PATCH is widely used in JSON:API specification. Can you provide support for this method?

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L19

Why is the nonce filled in here? A nonce is always randomly generated, so it's not really configurable. It's to make sure that the same request in the same second can still be uniquely identified.

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L22
Default content type? Why is this necessary? This has nothing to do with the signing library. The implementation should set this for each request, not as a global config. And the library should actually take this from the headers, not from the config.

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L17
client_id is not the right word here, it's plain id or public_key. Client id is application specific. The application implementing this library can choose to add a client_id query param but that's completely up to the implementation.

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L30
Any reason why we would support CUSTOM? Also, all methods should be supported. There is nothing in the specification that limits any HTTP Verb. The only difference is if there is a body to be submitted or not.

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L116
additional headers should only be added to the signature when they exist.

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L118
content_type should only be added when there is a body in the request

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L119
x_authorization_content_sha256 when there is a body in the request

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L123
signed headers should not be added to the authorization string when they do not exist.

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L106
We do not care about the method here. Only the body length. This way someone can't fool the algorithm by sending a GET with a body. It should not happen, but we should also not expect it won't happen.

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L107
The secret key needs to be decoded from base64 encoding first before using it.

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L146
The secret key needs to be decoded from base64 encoding first before using it.

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L111
method has to be uppercase, I don't see you checking this.

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L112
hostname needs to be lowercase

https://github.com/acquia/http-hmac-javascript/blob/LEX-88/src/hmac.js#L115
I don't see it being urlencoded. Most likely that doesn't matter much but it is in the specification.

That's it for now. Keep me updated on the changes! Ping @ynx and @lkhaas
I think that's it for now :)

See title :)

There's a V1 as well, and it should be clear that this code does not have support for V1

The check for encoding added in version 2.0 appears to be invalid
https://github.com/acquia/http-hmac-javascript/blob/master/src/hmac.js#L268

Any encoded variables end up double-encoded
For example: passing in:
http://localhost:5050/rules?account_id=D8DEMO&site_id=DFSITEDEV&status=-archived&visible_on_page=http%3A%2F%2Flocalhost%3A4200%2Ftests%3Fmodule%3DAcceptance%2520%257C%2520authentication&sort=asc&sort_field=weight

Produces the following when run through encodeURI(decodeURI(path))
Note that the % is being encoded in the visible_on_page parameter.
http://localhost:5050/rules?account_id=D8DEMO&site_id=DFSITEDEV&status=-archived&visible_on_page=http%253A%252F%252Flocalhost%253A4200%252Ftests%253Fmodule%253DAcceptance%2520%257C%2520authentication&sort=asc&sort_field=weight