biscuit-auth / biscuit-actix-middleware Goto Github PK

Currently, the following behaviours are hardcoded:

• token extraction (bearer auth scheme)
• token parsing (base64, static public key)
• error handling

Ideally, users should be able to:

1. provide a way to extract a token from the request (Request -> Result<Vec<u8>, E>);
2. provide a way to parse the extracted token (&[u8] -> Result<Biscuit, E>)
3. Generate HTTP responses from parsing/extraction errors (and more generally: react to them, eg logging, etc)

Notes:

• 1. and 2. could be provided as a single step. The question is what's most convenient (ie do we expect people to only override extraction logic, but not parsing logic?)
• what's suggested in 2. works if the provided function closes over a PublicKey, or an Option<u32> -> PublicKey. That might not be the simplest way to do things;
• should 3. also allow error recovery?
• we need to find a balance between flexibility and purpose. It is not too hard to create a middleware, so we should not bend over backwards to support uncommon use-cases;
• For reference, here is what I came up with for a Haskell middleware: https://hackage.haskell.org/package/biscuit-wai-0.1.0.0/candidate/docs/Network-Wai-Middleware-Biscuit.html#t:ExtractionConfig .

This crate provides optional integration with tracing we should document how to set things up and show how it integrates with the wider actix ecosystem.

The exposed middleware only handles token parsing (and verification), not authorization.

This is done on purpose: authorization is usually specific to each endpoint, while a middleware is called before routing and does not have access to endpoint-specific data.

In some cases, however, authorization can be expressed in a common way across all endpoints.
In that case, being able to do it in a middleware is a good thing:

• once the middleware is set up, it's impossible to forget to protect an endpoint
• it strongly separates authorization logic from actual endpoint logic
• it helps remove boilerplate

This use case is quite different from the one already covered, so i think it should be a different middleware, not a knob on the existing one (even though the actual implementation could be shared between the two middlewares).

Same as for #5, it will be important to strike a good balance between configurability and purpose. For reference, here is what I came up with for the same use case in Haskell https://hackage.haskell.org/package/biscuit-wai-0.1.0.0/candidate/docs/Network-Wai-Middleware-Biscuit.html#t:AuthorizationConfig