Skip to content
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

question: authorization, typed headers and hyper types #1150

Closed
sclasen opened this issue Sep 30, 2019 · 5 comments
Closed

question: authorization, typed headers and hyper types #1150

sclasen opened this issue Sep 30, 2019 · 5 comments
Labels
deficiency Something doesn't work as well as it could question A question (converts to discussion)

Comments

@sclasen
Copy link

sclasen commented Sep 30, 2019

Most everything seems pretty strongly typed in rocket, but I found myself having to write a lot more string related code than I was expecting to do something as simple request guard for http basic-auth.

Is there a plan for something like being able to get typed header data out of the request/put it into the response? something like:

let a: Result<Authorization,Error> = request.header::<Authorization>()

as part of going from request.headers().get_one("Authorization") to something typed that I can use in a guard, I also dipped into the 'vendored' hyper classes since that does have the notion of typed headers including Authorization with Basic and Bearer schemes. Some of the docs seem to warn against using the hyper types, is there an alternative Ive missed?

Questions

Any questions must include:

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

0.4.2

  1. What steps you've taken to answer the question yourself.

Reading Docs and Code and Issues

  1. What documentation you believe should include an answer to this question.

some docs on how to implement authn/z in rocket.

@jebrosen
Copy link
Collaborator

jebrosen commented Oct 1, 2019

The response side is pretty easy to deal with - all of the reexported header types implement Into<rocket::http::Header> and can therefore be used in Response::set_header.

On the request side, I unfortunately don't see an obvious way to parse headers aside from hyper's parse_header function which would require you to copy the header data a time or two.

It's worth mentioning that typed headers might be removed or replaced with a different implementation in 0.5 (see #1067), in which case you will need to do manual parsing or adapt to a different typed header library.

@jebrosen jebrosen added deficiency Something doesn't work as well as it could question A question (converts to discussion) labels Oct 1, 2019
@sclasen
Copy link
Author

sclasen commented Oct 1, 2019

Thanks @jebrosen

@sclasen sclasen closed this as completed Oct 1, 2019
@sclasen sclasen reopened this Oct 1, 2019
@sclasen
Copy link
Author

sclasen commented Oct 1, 2019

@jebrosen reopening, as Im having trouble actually using that parse_header thing.

the Header trait that defines parse_header doesnt seem to be publicly re-exported

error[E0603]: struct `Header` is private
 --> src/api.rs:6:34
  |
6 | use rocket::http::hyper::header::Header;


.map(|auth| Authorization::<BasicAuth>::parse_header(auth));
    |                                                     ^^^^^^^^^^^^ function or associated item not found in `rocket::http::hyper::header::Authorization<rocket::http::hyper::header::Basic>`
    |
    = help: items from traits can only be used if the trait is in scope
    = note: the following trait is implemented but not in scope, perhaps add a `use` for it:
            `use hyper::header::Header;`

Would adding Header here work? https://github.com/SergioBenitez/Rocket/blob/master/core/http/src/hyper.rs#L52

@jebrosen
Copy link
Collaborator

jebrosen commented Oct 1, 2019

That would re-export it, but I'm not too happy about the idea of reexporting even more from hyper.

You can add hyper (0.10) as a dependency of your own crate and you will be able to import it from there.

@sclasen
Copy link
Author

sclasen commented Oct 1, 2019

Will do, thanks!

@sclasen sclasen closed this as completed Oct 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deficiency Something doesn't work as well as it could question A question (converts to discussion)
Projects
None yet
Development

No branches or pull requests

2 participants