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

Stubbing out authentication #936

Closed
brainsiq opened this issue Nov 10, 2015 · 11 comments
Closed

Stubbing out authentication #936

brainsiq opened this issue Nov 10, 2015 · 11 comments
Assignees
Labels
api: datastore Issues related to the Datastore API.

Comments

@brainsiq
Copy link

I have the gcloud module talking to a local cloud datastore using the gcd tool for automated testing but am finding that it only works if I provide real credentials from my google console. Is there a way to stub out the authentication process so I can use test credentials?

@stephenplusplus
Copy link
Contributor

This should definitely be possible. Can you show me how you're getting the Dataset instance and the errors/signs that it's not working that you are getting?

@stephenplusplus
Copy link
Contributor

I put together a test branch, please give it a shot and let me know how it goes!

$ npm install --save stephenplusplus/gcloud-node#spp--gcd-no-auth

@stephenplusplus stephenplusplus added the api: datastore Issues related to the Datastore API. label Nov 10, 2015
@brainsiq
Copy link
Author

Thanks for the response. I'll give that branch a go tomorrow. So far I've just set the DATASTORE_HOST environment variable to my gcd server as I haven't come across any specific instructions for stubbing out the oAuth call that is made with the credentials.

@brainsiq
Copy link
Author

I get an invalid_grant response out of the gcloud lib when calling dataset.save

@stephenplusplus
Copy link
Contributor

So far I've just set the DATASTORE_HOST environment variable

That's mainly what I was wondering. Our code currently isn't seeing that and turning off the auth step. Hopefully that branch resolves that.

@brainsiq
Copy link
Author

Looks like this may now be turning off the auth step but breaking something else further down the line as when it comes to doing the save I get [Error: Invalid URI "undefined/datastore/v1beta2/datasets/suppliers/commit"]

I found that this.apiEndpoint from the Dataset constructor needs to be set for the API calls. Seems fairly easy to fix but can't quite see, at the moment, how to write tests to ensure that both this.apiEndpoint and customEndpoint both get set correctly.

@stephenplusplus
Copy link
Contributor

Oops, good catch. I just pushed a fix (hopefully).

If this works, I'll probably re-think how this is written before sending a PR. It's getting a wee bit messy.

@brainsiq
Copy link
Author

Yep that change seems to have done the trick.

These are my thoughts on the tests/implementation (slightly naive perhaps given I don't know any of the rest of the code base), hope they're welcome 😄 ...

I thought that with the current implementation the tests would be better just asserting that ds.apiEndpoint is set to the correct URL depending on the options/env, rather than testing the implementation of that private determineApiEndpoint_ function. And if determineApiEndpoint_ became just getCustomEndpoint then you shouldn't need to mutate the options parameter as a side effect. I did feel it also needs a test that when a custom endpoint is provided then it sets up the auth correctly as presumably that's why this slipped through the net. That was the main thing I couldn't work out how to do given the current state of things, so I guess you may want to tweak things further.

Anyway. Thanks for your help! Can live with it making the live auth calls for the time being until you figure something out.

@stephenplusplus
Copy link
Contributor

Of course, all thoughts are welcome. I will ping you when it's in the PR
stage for more :)

On Wednesday, November 11, 2015, Chris Impey notifications@github.com
wrote:

Yep that change seems to have done the trick.

These are my thoughts on the tests/implementation (slightly naive perhaps
given I don't know any of the rest of the code base), hope they're welcome [image:
😄] ...

I thought that with the current implementation the tests would be better
just asserting that ds.apiEndpoint is set to the correct URL depending on
the options/env, rather than testing the implementation of that private
determineApiEndpoint_ function. And if determineApiEndpoint_ became just
getCustomEndpoint then you shouldn't need to mutate the options parameter
as a side effect. I did feel it also needs a test that when a custom
endpoint is provided then it sets up the auth correctly as presumably
that's why this slipped through the net. That was the main thing I couldn't
work out how to do given the current state of things, so I guess you may
want to tweak things further.

Anyway. Thanks for your help! Can live with it making the live auth calls
for the time being until you figure something out.


Reply to this email directly or view it on GitHub
#936 (comment)
.

@brainsiq
Copy link
Author

Good work 👍

When might this make it to npm?

@stephenplusplus
Copy link
Contributor

I'll shoot for Wednesday/Thursday next week. Our code is in a bit of a transition state right now, we have a few more PRs to squeeze in. Will ping you when it's out!

sofisl pushed a commit that referenced this issue Nov 11, 2022
- [ ] Regenerate this pull request now.

Committer: @summer-ji-eng
PiperOrigin-RevId: 434859890

Source-Link: googleapis/googleapis@bc2432d

Source-Link: googleapis/googleapis-gen@930b673
Copy-Tag: eyJwIjoiLmdpdGh1Yi8uT3dsQm90LnlhbWwiLCJoIjoiOTMwYjY3MzEwM2U5MjUyM2Y4Y2ZlZDM4ZGVjZDdkM2FmYWU4ZWJlNyJ9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: datastore Issues related to the Datastore API.
Projects
None yet
Development

No branches or pull requests

2 participants