Typed Error Catchers, Fairings

[mmrath]

What I want is to inspect every request and if it is anything but POST to /api/auth/register or /api/auth/login then check for for auth header. If header is not present, then reply 401. I looked at Fairing - but Fairing cant respond to requests. I looked at request guard, it looks like for them I need to add a param to every route handler.

Questions

Any questions must include:

1. The version of Rocket this question is based on, if any.
   master

2. What steps you've taken to answer the question yourself.
   Looked at Fairing and request guard docs

3. What documentation you believe should include an answer to this question.
   not sure

[jebrosen]

The pain point you are encountering is that request Fairings cannot alter the request handling flow by responding or by returning some kind of error type. This is a known issue that can and should be available in Rocket's API eventually but I don't see an open issue for it.

Adding a request guard to every route handler is annoying, but does make it more obvious which routes need authentication and which don't. If you do add a request guard to every route indicating its privilege level, you can require instances of those request guards in database or API code as a compile-time assurance that the necessary security properties are enforced, as well.

But if "every" route requires authentication, it can be annoying to do that. You can work around the fairing response situation by altering the request uri in the fairing, thereby changing which route it ends up going to. rocket_cors does this (https://github.com/lawliet89/rocket_cors/blob/master/src/fairing.rs#L61), for example. It is a hack and I'm hesitant to even bring it up, but it might be worth exploring its suitability for your problem.

[mmrath]

From what I hear from you this issue should be a feature request than a question. I pretty much need everything except login screen to be authenticated. I think this is very common scenario.

[SergioBenitez]

@mmrath I'm with you. We have a feature in mind that would resolve this problem, but alas, it is as of now unimplementable due to lacking features in Rust.

[NoUsername]

@SergioBenitez would be interesting to know what features Rust would need so this could be implemented.
Keep up the good work 👍

[mmrath]

@SergioBenitez Would you be able to give a bit more information on how the solution might look like?

[SergioBenitez]

@NoUsername We'd need non_static_type_id, blocked in rust-lang/rust#41875.

@mmrath The gist, from my design doc, is:

Design

As the name implies, the guiding principle behind type-based catchers is that
catchers should operated type-dependently. Instead of invoking catchers based
purely on an error's status code, a catcher will be invoked based on the type
of an error, if any. This requires a full revamp of the catch attribute,
including its syntax and semantics, a semantic change to the [Fairing] trait,
as well as minor changes to guard traits.

Second, and equally important, the default semantics of error catchers will be
changed so that if the type of an error value implements Responder, a
Response will be created directly from the error value.

Fairings

Fairings gain the ability to respond early to requests. The primary changes to
the Fairing trait are: the addition of a new associated type, Response, and
a modification of the on_request method:

type Result<R> = Result<Data, (Status, R)>;

pub trait Fairing: Send + Sync + 'static {
+   type Response: Error = !;

    ...
-   fn on_request(&self, request: &mut Request, data: &Data) { .. }
+   fn on_request(&self, request: &mut Request, data: Data) -> Result<Self::Response> {
+       Ok(data)
+   }
    ...
}

Note that this is a departure from the previous (explicitly designed) rule that
fairings cannot terminate or respond to an incoming request directly. The
justification is two-fold:

• Rocket will properly and explicitly log how, when, and which fairing
  caused an early termination.
• The user can always catch the fairing's value. As such, the user always
  maintains full control.

[mmrath]

@SergioBenitez Thanks for the insight. I am not sure I understood fully, but is there no alternate design to implement this with current Rust? non_static_type_id does not appear to be available soon.

[SergioBenitez]

@mmrath No, I don't believe so. I'm not sure what you mean by "does not appear to be available soon". It seems that all relevant parties are interested in having the feature be implemented. What's missing is a bit of elbow grease to fix a compiler bug that's preventing the implementation.