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

Spanner ignores provided credentials when executing a query. #3718

Closed
lukesneeringer opened this issue Aug 2, 2017 · 9 comments
Closed

Spanner ignores provided credentials when executing a query. #3718

lukesneeringer opened this issue Aug 2, 2017 · 9 comments
Assignees
Labels
api: spanner Issues related to the Spanner API. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release.

Comments

@lukesneeringer
Copy link
Contributor

(This bug is re-posted from an e-mail I received yesterday.)


We are using python spanner client libraries, and I have a credentials issue in executing a sql query. Seems like executing a sql ignores the provided credentials to the client and just try to use the default credentials.

The code looks like:

spanner_client = spanner.Client(credentials=credentials, project=project_id)
instance = spanner_client.instance(instance_id)
database = instance.database(database_id)
database.execute_sql(stmt)

Debugging the code for a bit, I found out that eventually the code will try to create a session and it will try to get the spanner API client. When this object created, credentials is not passed and hence it's None, and hence the SpannerClient is trying to get the default credentials and fails in my case because I do not have default creds.

@lukesneeringer lukesneeringer added api: spanner Issues related to the Spanner API. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. status: acknowledged labels Aug 2, 2017
@tseaver
Copy link
Contributor

tseaver commented Aug 2, 2017

Parallels #3070, but in the database module.

@tseaver
Copy link
Contributor

tseaver commented Aug 2, 2017

Hmm, weird. The following patch passes through credentials from the client to the SpannerClientt constructor:

diff --git a/spanner/google/cloud/spanner/database.py b/spanner/google/cloud/spanner/database.py
index 9b838bf..82d8a52 100644
--- a/spanner/google/cloud/spanner/database.py
+++ b/spanner/google/cloud/spanner/database.py
@@ -155,7 +155,10 @@ class Database(object):
         """Helper for session-related API calls."""
         if self._spanner_api is None:
             self._spanner_api = SpannerClient(
-                lib_name='gccl', lib_version=__version__)
+                lib_name='gccl',
+                lib_version=__version__,
+                credentials=self._instance._client.credentials,
+            )
         return self._spanner_api
 
     def __eq__(self, other):

but when I run the system tests with that patch, they fail with:

n to_call(*args)
  File "/home/tseaver/projects/agendaless/Google/src/google-cloud-python/spanner/.nox/sys-3-6/lib/python3.6/site-packages/google/gax/retry.py", line 68, in inner
    return a_func(*updated_args, **kwargs)
  File "/home/tseaver/projects/agendaless/Google/src/google-cloud-python/spanner/.nox/sys-3-6/lib/python3.6/site-packages/grpc/_channel.py", line 507, in __call__
    return _end_unary_response_blocking(state, call, False, deadline)
  File "/home/tseaver/projects/agendaless/Google/src/google-cloud-python/spanner/.nox/sys-3-6/lib/python3.6/site-packages/grpc/_channel.py", line 455, in _end_unary_response_blocking
    raise _Rendezvous(state, None, None, deadline)
grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with (StatusCode.PERMISSION_DENIED, Request had insufficient authentication scopes.)>

I've checked, and the scopes on the credentials should work (arguably they are too broad):

(Pdb) pp self._instance._client.credentials._scopes
('https://www.googleapis.com/auth/spanner.admin',)

@dhermes, @jonparrott Does that ring any bell?

@theacodes
Copy link
Contributor

Yeah that doesn't seem right. @vkedia, do you know why the spanner.admin scope wouldn't work?

@mbassiouny
Copy link

I guess this has to be https://www.googleapis.com/auth/spanner.data. Admin is for administrative actions (Create instance/database).

tseaver added a commit that referenced this issue Aug 3, 2017
- Preserves "custom" credentials (existing code worked only with
  implicit credentials from the environment).

- Add tests ensuring scopes are set for correctly for all GAX apis
  (client uses admin scope, which do not grant data access, while
  database uses data scope, which does not grant admin access).

Closes #3718.
tseaver added a commit that referenced this issue Aug 3, 2017
- Preserves "custom" credentials (existing code worked only with
  implicit credentials from the environment).

- Add tests ensuring scopes are set for correctly for all GAX apis
  (client uses admin scope, which do not grant data access, while
  database uses data scope, which does not grant admin access).

Closes #3718.
@mbassiouny
Copy link

Thanks for the quick fix. In what version this will be in, and also what is the timeline for the release?

@lukesneeringer
Copy link
Contributor Author

@mbassiouny Our intent is to do a release today. No reason we can not get this in.

@mbassiouny
Copy link

@lukesneeringer Thanks!

@dhermes
Copy link
Contributor

dhermes commented Aug 4, 2017

@lukesneeringer It must be merged first 😀

@lukesneeringer
Copy link
Contributor Author

Yeah, I figured that last issue would be fixed sooner than it was. Most likely this will not make it into today's release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: spanner Issues related to the Spanner API. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release.
Projects
None yet
Development

No branches or pull requests

5 participants