-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Scheme extractor #2507
Add Scheme extractor #2507
Conversation
The test for extracting the scheme from the URI is missing as I haven't groked how to pass a URI with a scheme to the test server. |
@davidpdrsn Is this ready for merge, or do I need to add more tests? |
May I suggest additionally supporting |
It also seems to me that the extraction from |
Thanks for your comments @Wiezzel. |
@Wiezzel Thanks for taking the time to review the PR.
Turns out this was a typo;
I have added a manual test that calls |
@bengsparks Please check out this minimal example:
[package]
name = "scheme-extractor"
version = "0.1.0"
edition = "2021"
[dependencies]
axum = "0.7.3"
tokio = { version = "1.36.0", features = ["full"] }
[patch.crates-io]
axum = { git = "https://github.com/bengsparks/axum.git" }
async fn test(scheme: axum::extract::Scheme) -> String {
scheme.0
}
#[tokio::main]
async fn main() {
let app = axum::Router::new()
.route("/", axum::routing::get(test));
let listener = tokio::net::TcpListener::bind("0.0.0.0:8000").await.unwrap();
axum::serve(listener, app).await.unwrap();
} Then run:
|
I think we've made a point to not handle any conventional, or even standard headers for "original" request data from proxies in |
@jplatte Could you concretise what this means for the PR? Does this mean |
I could suggest a fallback to HTTP in case the scheme cannot be extract neither from headers, nor from path. This sounds like a reasonable default to me, but it could be optional in case some application needs stricter check. |
Yes, that is what I meant. I didn't know we even had a |
@jplatte I will put this PR on pause then until the matter is resolved; Having a |
In my tests, the
If you wanted to walk that path to the end, you'd have to remove the But as a user, the extractors came across to me as an implementation of common practices. Which is why I would expect them to check those extra headers. Because if they didn't, they'd boil down to a one-liner like I would not expect them to be subject to security-based mitigations. |
2ea51dd
to
59168e7
Compare
To reiterate:
The final bullet point requires that Should the naming of |
Why is that? Regardless of the HTTP version, something in the stack has to initiate the TLS connection, and therefore knows what scheme is in use. |
Ah, I think I've mixed something up. |
I accidentally closed this Pull Request when updating my fork of axum. |
It seems you've accidentally pushed the already merged branch removing the We've moved the Sorry for the delays. |
@mladedav thanks for the quick reply. I've restored the state of the branch |
I also share this concern. |
The Additionally, adding a separate method to indicate "danger" goes against the spirit of extractors, whose intended usage is documented as "reading via destructuring" i.e. |
That's a good point. I'd like that we make users aware of the risks of using those extractors somehow, but I don't have better idea for now. Having them in axum-extra does not feel good enough. It's still very easy to import them and use them without being conscious of the possible security implications. I'll wait for the point of view of @jplatte here. |
@yanns yeah I agree, it would be nice to do more than just exclude these from the main crate. But also I think it wouldn't be great to hold up this PR again because of that. Let's merge it but make an issue to revisit both |
Agree with this plan! |
Oh, CI failing is my fault.. I'll look into it 🫠 |
I've added an issue about spoofable extractors: #2998 |
Motivation
Closes #2504.
Solution
Detect the scheme in the following order:
proto
within theForwarded
headerX-Forwarded-Proto