NSManagedHuman / google-api-python-client

Automatically exported from code.google.com/p/google-api-python-client
Other
0 stars 0 forks source link

oauth2client: Bad handling of multiple scopes #217

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Instantiate OAuth2Decorator with a tuple of scopes.
2. Watch it cause invalid_scopes from the auth server.
3. Instantiate AppAssertionCredentials with a list of scopes.
4. Watch it fail trying to refresh.

What is the expected output? What do you see instead?

In short, everything that accepts multiple scopes should accept tuples, lists 
and perhaps even space-delimited strings.

SignedJwtAssertionCredentials and OAuth2WebServerFlow explicitly check whether 
the scopes parameter is a list and if passed a tuple, will silently convert it 
to an incorrectly-formatted string which breaks the auth requests. They work 
fine when passed a list or a space-delimited string.

AppAssertionCredentials also checks the scopes for being a list, and joins them 
into a space-delimited string. However, when it tries to refresh, it calls 
app_identity.get_access_token(), which accepts lists and tuples, but not 
space-delimited strings. For now I can work around this by initializing 
AppAssertionCredentials with a tuple, but it's clearly a bug.

Original issue reported on code.google.com by ma...@google.com on 9 Nov 2012 at 10:54

GoogleCodeExporter commented 8 years ago
Fixed in 
http://code.google.com/p/google-api-python-client/source/detail?r=8a626c442248c8
3a4c4c489aad79786a5f8750d7

Original comment by jcgregorio@google.com on 16 Nov 2012 at 10:03