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
feature: Enable fetching of OAuth credentials from the GCE metadata service #44
Comments
Unfortunately I cannot comment on this, as I don't know exactly how this would be useful with oauth just because I am not aware of everything the protocol offers. |
This is what I wrote for this use case, seems to work: header! { (MetadataFlavor, "Metadata-Flavor") => [String] }
struct MetadataServerProvider {
client: HyperClient,
token: Token,
}
impl GetToken for MetadataServerProvider {
fn api_key(&mut self) -> Option<String> {
None
}
fn token<'b, I, T>(&mut self, _scopes: I) -> Result<Token, Box<StdError>>
where T: AsRef<str> + Ord + 'b,
I: IntoIterator<Item = &'b T>
{
if !self.token.access_token.is_empty() && !self.token.expired() {
return Ok(self.token.clone());
}
let client = HyperClient::new();
debug!("DefaultApplicationCredentials: checking metadata server...");
let mut error;
for _ in 0..3 {
let response = client.get("http://metadata.google.\
internal/computeMetadata/v1/instance/service-accounts/default/token")
.header(MetadataFlavor("Google".to_owned()))
.send();
match response {
Ok(response) => {
self.token = serde_json::from_reader(response)?;
return Ok(self.token.clone());
}
Err(new_error) => error = new_error,
}
}
Err(error.into())
}
}
`` |
Internally we have a hacked together "DefaultApplicationCredentials" thing (as per https://developers.google.com/identity/protocols/application-default-credentials). We'd be happy to open source it, but it needs a bit of cleaning up. Could do this over Christmas if there's interest. |
@cristicbz I sure find it interesting, even though I wouldn't have a use for it myself. What does @dermesser think about it? |
Hey @cristicbz! Thanks for your proposal, I've been meaning to do it but am not a user of GCE myself (so it's down my priority list). The way you implemented it is definitely similar to how I would've done it. I'd be happy to accept it as addition to this project. (that is, if @Byron is ok with such vendor-specific code in what is originally his work; although I'm definitely not innocent with regards to that either...) |
I am totally fine with that, as I believe we should implement what people need. Given that yup-oauth2 is primarily used by the google-apis-rs project, I think it's alright to cater to google more than to others. |
ping, @cristicbz -- are you still interested in implementing this? |
I have created a small bare bones impl of this and would requests comments/contributions on it before creating an pull request: https://github.com/braincow/yup-oauth2/tree/gcp_instance_metadata |
@braincow thank you, this looks interesting! I'd encourage you to directly create a PR anyway, it's easier to see and evaluate the diff that way :) |
@dermesser #156 here you go. Its a draft for now since I did not have time currently to properly go through the projects guidelines on opening pull requests. I hope you dont mind my haste :) |
nice work @ingwinlu! and thanks for updating/rebasing the code since I have been busy with other things to follow up on this. still would love to see this merged into yup-oauth2 |
@dermesser i think this and the original pr can be closed now. |
I concur. The PR draft and subsequent updated PR by @ingwinlu are now merged so this feature is implemented. |
This is highly optional, but also isn't really complicated (just calling an HTTP endpoint without much more authentication/authorization fuss): https://cloud.google.com/compute/docs/storing-retrieving-metadata.
I'm glad about feedback on this, as it's vendor-proprietary; on the other hand, it doesn't restrict the other functionality.
The text was updated successfully, but these errors were encountered: