-
Notifications
You must be signed in to change notification settings - Fork 62
update to std::future::Future #140
Comments
Most of the async code is due to surfacing of hyper calls as you correctly pointed out. I would prefer to hold out changing the code until |
Are you planning to support it once it drops in 1.39? I've been writing a prototype using |
Yes that's the plan. I do not have a clear timeline at the moment however. I was wondering, however, why you are getting errors with |
I'm using |
I wrote the auth using std futures and the technique that the official node kms library uses for auth without a tenant_id/tenant_domain. Haven't checked yet if it works the same way on other resources. This is very prototype. #[derive(Deserialize, Serialize)]
pub struct AuthResponse {
pub access_token: String,
}
pub async fn authorize(client: Arc<reqwest::Client>, client_id: &str, client_secret: &str, vault_base_url: &str, key_name: &str) -> Result<AuthResponse, reqwest::Error> {
// bytes for the kms to wrap
let empty_request = AzureWrapRequest {alg: super::AZURE_KEY_ENCRYPTION_METHOD.to_owned(), value: "".to_owned()};
// we just fire off our request with no authorization intending to get back
// a 401 that tells us where to point to authorize. If this works for other resources
// then the authorize function could take an endpoint + empty request to make
let wrap_url = format!(
"{}/keys/{}//wrapkey?api-version=7.0",
vault_base_url, key_name
);
let expected_401_response = client
.post(&wrap_url)
.json(&empty_request)
.send()
.await?;
// parse out the `authorization` and `resource` from the bearer header
// that came back on the 401
let (authorization_url, resource) = parse_azure_bearer_header(
expected_401_response
.headers()
.get("www-authenticate")
.unwrap()
.to_str()
.unwrap(),
)
.unwrap();
// post our credentials to the derived authorization url so we can get a token
let params = [
("grant_type", "client_credentials"),
("client_id", client_id),
("client_secret", client_secret),
("resource", resource),
];
let auth_url = format!("{}/oauth2/token", authorization_url);
let auth_response = client
.post(&auth_url)
.form(¶ms)
.send()
.await?
.json::<AuthResponse>()
.await;
auth_response
}
// pull out the authorization url we should hit, as well as the necessary resource.
fn parse_azure_bearer_header(bearer: &str) -> Option<(&str, &str)> {
let re = regex::Regex::new(r#"authorization="([^"]+)".*resource="([^"]+)""#).unwrap();
let captures = re.captures(bearer).unwrap();
Some((
captures.get(1).unwrap().as_str(),
captures.get(2).unwrap().as_str(),
))
} |
I have created a PR that makes the AAD crate fully async (#162). Can you give it a try and tell me what do you think? Thank you! |
It does work! Can't use it in my project yet because of a ring conflict with |
https://seanmonstar.com/post/187493499882/hyper-alpha-supports-asyncawait
hyperium/hyper#1805
I'd love to be able to use the async/await syntax available. It will be in the stable release is
1.39 release which will be on November 7th. I'd like to be able to use it before then. std::future::Future is available in stable.
The text was updated successfully, but these errors were encountered: