bblfish / httpsig Goto Github PK

Currently there are a lot of dependencies with implicits, such as can be seen in implementations of the VerifySignatureTests . This has to be reviewed carefully, by grouping implicits together like other libraries do, so that the right ones are autimatically downloaded. (Reorganisation of some of the apis to further this should not be out of the question).

Ideas welcome.

There are tests, but I think there may be official tests that could be used to hunt down all the corner cases.

There was not time in #12 to add support for trailer fields.

Please vote on this issue if you need these.

The problem with Try is that it does not make explicit the type of errors that should be expected from a function. All the code in httpSig has an upper set of exceptions to be expected, and this should be made visible. It would also work better with other cats libs.
Try was a way to get things done quickly.

The current implementation of "Signing HTTP Messages" can compile to Java Byte Code and Java Script.

It could potentially also compile to native. I have never used the Scala Native compiler yet.

Perhaps this could be useful to folks like @TallTed or @kidehen as they have implementations of stores that are written in C or similar languages?
@ekrich is working on the Scala-Native compiler. Could it make sense to produce DLLs for software like that?
I guess that is still a bit of a stretch.

§5 Requesting Signatures starts with the following text:

While a signer is free to attach a signature to a request or response without prompting, it is often desirable for a potential verifier to signal that it expects a signature from a potential signer using the Accept-Signature field.

that is clearly essential for the HttpSig authentication protocol.

The current implementation works with cats.effect.IO which is clean and pure. But it has the disadvantage of being a bit heavy for projects that rely on scala's Future and may just want to add an signing layer without buying into the full cats.effect stack.
See my longer comment in the discussion on custom IO Runtimes.

For expediency I used IO in commit co-operating-systems/Reactive-SoLiD#20 .

If people would like to use this library but feel this is a blocker please contact me to help me change the priority of this issue.

Currently tests are run in Akka on hand built versions of the example code, and we have something a bit more programmatic with http4s. This is useful to get the framework going.

The problem is that those tests don't tell us how headers are rally parsed by the underlying systems, and that is quite important if we want to know if our signatures are going to work correctly when deployed.

For example does the request

POST /path?param=value&foo=bar&baz=bat%2Dman HTTP/1.1
Host: www.example.com

create a modelled object where the %2D has been decoded or not? Depending
on that the result of using @query may be different. Other examples are bound to exist.

Akka has tests suites that allow one to do this (but don't use munit).
Http4s may be more complicated as it abstracts over a number of underlying components.

I am a bit in a hurry, so I just want to document that the ;sf annotation discussed
in 2.1.1. Canonicalized Structured HTTP Fields needs to be implemented.

"x-dictionary": a=1,    b=2;x=1;y=2,   c=(a   b   c)
"x-dictionary";sf: a=1, b=2;x=1;y=2, c=(a b c)

(see also discussion in issue 1885)

Most of the tools needed for response signing came with #12 .
So this is not a huge amount of work. The same header parsers and @parsers can be re-used. They just need to be packaged. And tests need to be written.

I won't need them immediately, which is why I need to postpone this implementation.

Please vote on this, leave a note, or ping me if you need them.