Seeking advice: how to get request Parts request_context_ref populated testing lambda-http with an axum router... #906

justro · 2024-07-05T16:20:12Z

justro
Jul 5, 2024

Hello - new to rust and the lambda-rust-runtime, hoping to get some advice. I am trying to write some tests to verify the configuration of my routes and handlers in a rust lambda that backs an api gateway api. My code works when deployed, but I wanted to just write a basic test to validate that an incoming request gets routed, parsed, and passed through the handlers correctly.

I took the json of a request out of my logs and am trying to use it to run the handler through the router. The problem I'm having is that I'm using an axum extractor to get auth information from the request, but when it gets to the extractor in test, the Parts being passed in do not have the requestcontext_ref. I can verify before I execute the router on the LambdaEvent that the Parts do have the requestcontext info, but it seems to be getting lost in test, on the way to my extractor.

Here are some snippets: first, my test setup. As comments show, after I create the request I can verify that breaking it into parts includes the authorizer in the requestcontext_ref:

      // This creates the axum router with cors. The 'state' in this case has some
      // data access type objects that are ultimately invoked by the handlers, and
      // mocked further up in my test.
      let app = app(cors(), state);

      // this request comes from my lambda logs, seems to parse correctly, includes
      // authorizer information
      let test_data = include_bytes!("./fixtures/test_v1_goals_goal_day_get.json");
      let parsed: ApiGatewayProxyRequest = serde_json::from_slice(test_data).unwrap();
      let req: Request = LambdaRequest::ApiGatewayV1(parsed).into();
      // request looks correct? doesn't show extensions in the print, but I can access
      // them in the next line
      println!("{:?}\n", &req);
      req.extensions().request_context_ref().map(|ctx| {
          // here I can see context does exist, and includes
          // authorizer information
          println!("context: {:?}\n", ctx);
      });
      // let (parts, _) = req.into_parts();
      //// looking at the parts, it DOES include the extensions
      // parts
      //     .extensions
      //     .request_context_ref()
      //     .map(|ctx| println!("{:?}", ctx.authorizer()));

      let response = app.oneshot(req).await.unwrap();
      // this fails with a 401 because my authorization extractor can't get the authorizer info 
      // from request parts, which is where I could use help...
      println!("{:?}", &response);

my router setup looks like this. The tracing layer shows that authorizer info is at least on the request extensions in here, although I can't check parts:

fn app(cors_layer: CorsLayer, shared_state: Arc<AppState>) -> Router {
    Router::new()
        .route(
            "/v1/goals/goal_day/:day_start_utc",
            get(get_goal_day)
                .post(post_goal_day)
                .delete(delete_goal_day),
        )
        .route("/v1/goals/goal_days", get(get_goal_days_page))
        .layer(cors_layer)
        .layer(Extension(shared_state))
        .layer(TraceLayer::new_for_http().on_request(
            |req: &axum::http::Request<Body>, span: &Span| {
                println!("Received request: {:?}\n", req);
                req.extensions().request_context_ref().map(|ctx| {
                    // shows the ApiGatewayRequestAuthorizer here as well...I
                    // can't look at parts directly because req is shared ref here
                    println!("context authorizer: {:?}\n", ctx.authorizer());
                });
            },
        ))
}

here is my authorization extractor. Although this works when deployed, in my test at this point the request_context_ref is None, so I can't get to the authorizer information:

#[async_trait]
impl<S> FromRequestParts<S> for AuthorizationData
where
    S: Send + Sync,
{
    type Rejection = (http::StatusCode, &'static str);

    async fn from_request_parts(req: &mut Parts, _state: &S) -> Result<Self, Self::Rejection> {
        // has method, uri, headers, etc., looks pretty normal to me
        println!("auth parts: {:?}", &req);
        // prints req cont: None
        println!("req cont: {:?}", req.request_context_ref());
        // prints req ext cont: None
        println!("req ext cont: {:?}", req.extensions.request_context_ref());
        get_authorization_data(req.request_context_ref()).ok_or((
            StatusCode::UNAUTHORIZED,
            "Could not extract authorization data from request",
        ))
    }
}

FWIW, here is my handler declaration, where I'm pulling out the auth data using the extractor:

/// Gets a goal day (for the authenticated user) by its start UTC timestamp.
async fn get_goal_day(
    Extension(state): Extension<Arc<AppState>>,
    Path(day_start_utc): Path<String>,
    auth: AuthorizationData,
) -> Result<Json<api::GoalDay>, (StatusCode, &'static str)> {

I'm guessing there is some step in setting up the request that I'm missing, or something that lambda_http::run does to add/preserve the parts that I've skipped?

calavera · 2024-07-05T20:58:05Z

calavera
Jul 5, 2024

Nothing comes to my mind. At first glance, I'd assume that your code worked as expected. lambda_http doesn't do anything else than transforming the JSON payload into the Request object and passing it to the application. If you have a way to minimally reproduce it, I can take a look, but I would probably look into how Axum is running the extractor. The lambda runtime or the http create don't do any modifications to the payloads after the information is in the Request object.

3 replies

justro Jul 5, 2024
Author

Got it, ok thank you very much!

justro Jul 6, 2024
Author

@calavera just FYI, I was able to get my example working by downgrading lambda-http from 0.12.0 to 0.11.1. The test works if I use:

lambda_http = { version = "0.11.1", features = ["apigw_rest"] }

and fails if I use:

lambda_http = { version = "0.12.0", features = ["apigw_rest"] }

making no other changes.

I also found that I was broken in deployment as well, so what I said about working in deployed lambda env but failing in test was not true. I had done the crate version update after the last time I deployed, and didn't realize that the change had broken the code in the lambda env as well.

If you think it'd be useful, I could try doing a minimal repro with a custom extractor when I get some time later next week.

calavera Jul 6, 2024

yes, that'd be very useful. Thanks for diving deep into it.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Seeking advice: how to get request Parts request_context_ref populated testing lambda-http with an axum router... #906

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 3 replies

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Seeking advice: how to get request Parts request_context_ref populated testing lambda-http with an axum router... #906

justro Jul 5, 2024

Replies: 1 comment · 3 replies

calavera Jul 5, 2024

justro Jul 5, 2024 Author

justro Jul 6, 2024 Author

calavera Jul 6, 2024

justro
Jul 5, 2024

Replies: 1 comment 3 replies

calavera
Jul 5, 2024

justro Jul 5, 2024
Author

justro Jul 6, 2024
Author