FromRequestParts implementation that can both fail and be optional

[sazzer]

For my service, I've got an Authentication type that represents how a request is authenticated. I've then implemented FromRequestParts for this so that it can be wired directly into my handlers.

For the most part, this works great. However, what I'd like is for some handlers to be able to take an Option<Authentication> so that they can be called whether the request is authenticated or not. On doing that, I've discovered that authentication errors - e.g. providing an invalid bearer token - come through a None when they should fail. Is there a way to achieve this?

In other words, what I would like to have is:

• Handler takes an Authentication
  • Valid request - handler is called.
  • Missing auth details - handler is not called, HTTP 401 is returned.
  • Invalid auth details - handler is not called, HTTP 401 is returned.
• Handler takes an Option<Authentication>
  • Valid request - handler is called, parameter value isSome(...).
  • Missing auth details - handler is called, parameter value is None.
  • Invalid auth details - handler is not called, HTTP 401 is returned.

Unfortunately, I can't implement FromRequestParts for Option<Authentication> because both FromRequestParts and Option are foreign types. The best I can think of is to have a local version of Option<Authentication> that's used instead, but that feels like a bit of a crude hack.

Cheers

[davidpdrsn]

I’d use something like struct Authentication(Option<ActualAuth>) and make that an extractor. Using Option<Authentication> doesn’t feel right for the reasons you state.

[sazzer]

Hmm - so the FromRequestParts returns one of:

• Err(...)
• Ok(Authentication(None)
• Ok(Authentication(Some(ActualAuth))

That feels basically the same as I was thinking of "a local version of Option that's used instead", but is there some way that I can go from that to having handler parameters that are Option<Authentication> or just straight Authentication?

[davidpdrsn]

I would not use Option<Authentication>. I’d only do that if the error type is Infallible.

[sazzer]

Ok - I've got something working :) (Yay dog walking for getting your mind off things!)

To start with, I've got these:

#[derive(Debug, PartialEq)]
pub enum AuthenticationDetails {
    User(String),
}

#[derive(Debug, PartialEq)]
pub struct Authentication(Option<AuthenticationDetails>);

I've then got an impl<S> FromRequestParts<S> for Authentication that returns either:

• Err() if the authentication outright fails.
• Authentication(None) if the request wasn't authenticated.
• Authentication(Some(...)) if the request was successfully authenticated.

And secondly I've got an impl<S> FromRequestParts<S> for AuthenticationDetails which basically does:

        let Authentication(authentication) = Authentication::from_request_parts(req, state).await?;

        authentication.ok_or_else(|| problemdetails::new(StatusCode::UNAUTHORIZED))

So now:

• If the handler takes an Authentication then it can be called whether the request was authenticated or not.
• If the handler takes an AuthenticationDetails then the request must be authenticated.

[jplatte]

@davidpdrsn This and all the previous confusion around Option<Path<_>> is making me wonder if Option<Extractor> being the same as Result<Extractor, ExtractorError> with the error discarded is really the right choice. We could also have separate traits OptionalFromRequest and OptionalFromRequestParts and implement them only for a handful of types where it actually makes sense to discard the error. We could also implement different behavior, such as making Option<Path<_>> equivalent to the current OptionalPath from axum-extra. If you feel like this is worth exploring, I can open an issue.

[davidpdrsn]

I agree it’s worth exploring 👍