oxidecomputer / oxidecomputer/dropshot

Unable to implement an extractor the references my app-specific server context

Open
#972 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1.2k
Forks
104
Avg merge
1d 19h
Merged PRs (30d)
22

Description

I was looking to implement an ExclusiveExtractor that references data in my server context, and at first glance I thought I was going to be able to, but now I'm not seeing how I can specify my concrete type to be able to do so.
I want to do something like:

#[async_trait]
impl<T> ExclusiveExtractor for VerifiedGithubBody<T>
where
    T: Sync + Send,
{
    async fn from_request(
        rqctx: &RequestContext<MyContext>,
        request: hyper::Request<hyper::Body>,
    ) -> Result<Self, HttpError> {
        let context = rqctx.context();
        let hmac_secret = context.github_hmac_secret;

        ...
    }
...
}

where MyContext is:

pub(crate) struct MyContext{
    pub(crate) github_hmac_secret: secrecy::SecretString,
}

but that doesn't work.

I can do all the work of this in the endpoint handler, which is fine, but it would be my preference to do this kind of thing in an extractor. Alternatively, I could pass that access that data via other means, such as environment variables, but it is also my preference to not use that for secrets. The server context seems like an appropriate place to store that.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the ExclusiveExtractor and RequestContext definitions, then trace how MyContext is created and made available to request handling. Compare the desired VerifiedGithubBody usage with the current extractor contract; done means the supported approach for accessing app-specific context is clear, or the required API change is precisely scoped.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
api, backend-api-design
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.