introduce Authorization::bearer helper method #121
Conversation
miraclx
force-pushed
the
miraclx/add-authorization-header-helper
branch
from
a05b002
to
2d73544
Compare
| /// | ||
| /// See the [`auth`](self) module documentation for more information. | ||
| pub fn bearer<T: AsRef<str>>(token: T) -> Result<Self, InvalidHeaderValue> { | ||
| HeaderValue::from_bytes(&[b"Bearer ", token.as_ref().as_bytes()].concat()).map( |
There was a problem hiding this comment.
how come we're concatenating with bytes here? Also, from_bytes allow ASCII characters outside the standard visible characters which might not be what we want from authorization. from_str would only allow the visible ASCII characters
| HeaderValue::from_bytes(&[b"Bearer ", token.as_ref().as_bytes()].concat()).map( | |
| HeaderValue::from_str(&["Bearer ", token.as_ref()].concat()).map( |
There was a problem hiding this comment.
The signature T: AsRef<str> already enforces this guarantee at the caller level. So both of these are pretty much equivalent, but we avoid constructing an owned String when concat-ing.
PS: the logic of from_str doesn't use any str-specific logic. It literally just casts it back to a slice.
There was a problem hiding this comment.
The signature T: AsRef already enforces this guarantee at the caller level. So both of these are pretty much equivalent, but we avoid constructing an owned String when concat-ing.
ahh, ignore my suggestion then
PS: the logic of from_str doesn't use any str-specific logic. It literally just casts it back to a slice.
interesting and weird how the docs say that it accepts visible ASCII octets only?
There was a problem hiding this comment.
interesting and weird how the docs say that it accepts visible ASCII octets only?
Yeah, it does validation at a later point, but by then it doesn't matter what the input was, it validates a byte slice eventually. https://github.com/hyperium/http/blob/34a9d6bdab027948d6dea3b36d994f9cbaf96f75/src/header/value.rs#L226
There was a problem hiding this comment.
PS: thanks for looking through
Resolves #118.
Introduces the
Authorization::bearermethod that adds an equivalentAuthorization: Bearer ...entry into the request headers.This function does no input validation beyond that it's a header value, not that it's a valid JWT.
We offload the guarantee of it being a valid utf-8 string to the caller.