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

Unable to use provider with no access to /me api endpoint #27

Closed
goblain opened this issue May 11, 2018 · 5 comments
Closed

Unable to use provider with no access to /me api endpoint #27

goblain opened this issue May 11, 2018 · 5 comments

Comments

@goblain
Copy link
Contributor

goblain commented May 11, 2018

Expected Behavior

Having OVH Api application credentials I should be able to manage resources I have been granted access to.

Actual Behavior

If access to API on /me URI was not granted the provider fails to run with

* provider.ovh: OVH client seems to be misconfigured: "Error 403: \"This call has not been granted\""    

Suggested solution

For verification of client connection switch from /me to /auth/time which returns unix timestamp and does not require explicit access rights granted.
While no authentication is required to access this endpoint, if provided and invalid it will still fail.

goblain added a commit to goblain/terraform-provider-ovh that referenced this issue May 11, 2018
@yanndegat
Copy link
Collaborator

hi @goblain
this is a good point

yet, fact is /auth/me requires not auth at all
i think we should prefer auth/currentCredential

what do you think?

@goblain
Copy link
Contributor Author

goblain commented May 11, 2018

as far as I can see on https://api.ovh.com/console/#/auth /auth/currentCredential is an authenticated endpoint, meaning it will result in more or less the same issue as with /me (will require explicitly granted permissions to read).

I bumped into this while working with a restricted client I was provided for OVH account that I'm supposed to use. One way would be to ask for a token that does allow access to the "test" endpoint, but I think that by using unauthenticated endpoint for client testing it is clearer that you only need to have access to the API endpoints for the resources that will actualy be managed.

@yanndegat
Copy link
Collaborator

then maybe we shall instead remove the "test" in the provider config and let the API return errors or not.?

@goblain
Copy link
Contributor Author

goblain commented May 11, 2018

looks like my assumption was wrong, just done some testing and it seems that using /auth/currentCredentials is ok

@goblain
Copy link
Contributor Author

goblain commented May 11, 2018

yanndegat added a commit that referenced this issue May 11, 2018
fixes #27 by switching to /auth/currentCredential for client validation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants