To: @dhermes

I am currently using class SignedJwtAssertionCredentials, and as of 2 days ago, it was removed.

oauth2client/client.py

https://github.com/google/oauth2client/commit/dcd20c9375308979e45ae280ec102a28d2ca60d1#diff-d8b1525b7f161cbce2f6438636be9c38

What am I to use instead now?

Signed JWT is expected for Google Cloud API Authentication.

See SignedJwtAssertionCredentials._generate_assertion()

If this is a duplicate I apologize.

ISTM this requires

• [x] Move all uses of httplib2 into a module (call it transport probably) (#554, #559, #561, #577)
• [ ] Determine what assumed interface of httplib2.Http is needed
• [ ] Optional. Try to reduce the interface needed
• [x] Factor out the hard dependencies on httplib2 and just use these interfaces
• [ ] Document the interface and allow credentials constructors to optionally take a custom Http object from any old library, e.g. twisted or requests.
• [ ] Revisit all changes and ensure consistency
• [ ] Revisit query string update hackery in #622

Reported here: https://github.com/burnash/gspread/issues/239 for details, but in -----BEGIN PRIVATE KEY-----\n_**\n-----END PRIVATE KEY-----\n", it seems *_* must not contain \u003d

This seems to be a problem only for python 2.7 (although possibly python 3 too as I am blocked by https://github.com/google/oauth2client/issues/106 so I might not have got that far with python 3).

Initial self signed jwt credential support #252. Here is my thinking with this initial API:

-SelfSignedJWTCredentials class should not be on the OAuth2Client inheritance hierarchy, there are many oauth2 specific methods (like refresh) that don't apply to self signed credentials. -SelfSignedJWTCredentials can be placed in the service_account module, SelfSignedJWTCredentials are highly coupled with service account credentials, self signed jwts can only be signed using service account credentials -get_access_token() can be the external interface for generating tokens, it is consistent with the GoogleCredentials API, and there is nothing OAuth2 specific about the naming. -The fields contained in the JWT are Google specific as far as I can tell, so this should be considered a Google specific class

This should fix #224 once merged.

Currently rough and looking for feedback. This intentionally deviates from the appengine/webapp2 decorator to be more idiomatic for flask users.

1. The credentials are currently only stored on the session. I'd like some feedback on how to allow the user to specify storage, and how the session storage should fix into that (should it store both in the session and within the user provided storage?)
2. I'm aware that it doesn't quite fit with the style of the rest of the codebase, I'll adjust to 2 spaces etc before merge.
3. The scopes default to 'email' and 'profile', and there's a mechanism to fetch the user's full profile from google+. I can remove this if we feel it's bloated (users can easily add it back via authorize_callback).

Tests will be added once I validate this approach.

I am using gspread 0.2.5 and oauth2client 1.4.11. On a Mac with Python 2.7.5 I can authenticate to Google and retrieve data using this code:

from oauth2client.client import SignedJwtAssertionCredentials
scopes = ['https://spreadsheets.google.com/feeds/', 'https://docs.google.com/feeds']
credentials = SignedJwtAssertionCredentials(client_email, private_key, scopes)
gc = gspread.authorize(credentials)

On Ubuntu 14.04 Linux with Python 2.7.6 and identical credentials, I see this error:

Traceback (most recent call last):
  File "scripts/website-people-update.py", line 76, in <module>
    sheets = load_sheets(gdocs_client_email, gdocs_private_key)
  File "scripts/website-people-update.py", line 25, in load_sheets
    gc = gspread.authorize(credentials)
  File "/usr/local/lib/python2.7/dist-packages/gspread/client.py", line 335, in authorize
    client.login()
  File "/usr/local/lib/python2.7/dist-packages/gspread/client.py", line 98, in login
    self.auth.refresh(http)
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 598, in refresh
    self._refresh(http.request)
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 769, in _refresh
    self._do_refresh_request(http_request)
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 834, in _do_refresh_request
    raise AccessTokenRefreshError(error_msg)
AccessTokenRefreshError: invalid_grant

I’m at a bit of a loss. Searches for invalid_grant come up with solutions that address incorrect configuration, rather than platform-specific failure.

This Django extension adds the views, decorators, and signals to oauth2client.

This is heavily based on the work @jonparrott did for oauth2client/flask_util.

Currently the only storage offered uses Django sessions. Based on issue #319 more storage options are planned along with integration to the existing CredentialsField in django_orm.

This adds an environment variable to the tox script. This might not be strictly necessary, but it did simplify the tests a lot, since Django settings get looked up at import time and cached so it's easiest if they have an environment variable pointing to an existing settings module when the tests are started.

This could have been squeezed into a single file, but I spilt it into separate files based on existing Django extension conventions.

Towards #470

This is not ready for merge, this is an initial sketch of what this would look like. Please note:

1. Instead of outright replacing multistore_file, I am introducing a new module to cover the same functionality named multiprocess_file_storage. We can do a release to deprecate multistore_file in favor of multiprocess_file_storage and then another release to remove it.
2. The interface has changed. Instead of a bunch of get_storage_{} functions, there is now just MultiprocesFileStorage(filename, key). The key argument can be used to emulate how the previous helper methods worked, eg. key = '{}-{}-{}'.format(client_id, user_agent, scope).
3. Tests are not done, want to sanity check this first.

@thobrla, while writing this, I came across some interesting behavioral cases:

1. The storage only holds the lock as long as needed to read/write the credentials file during put or get, but if at any point in time it fails to acquire the lock it will switch to read only mode and will never try locking again.
2. The storage only reads the credentials file once, but writes to it constantly. This means if multiple processes access the store and write, they are probably erasing the other's stuff despite the locking.

It seems that multistore_file never lived up to its promises, and neither will this class. As I mentioned before, a sqlite-based storage would be a true solution but it would require the cloud sdk and gsutil to take on a third-party binary dependency, which may be untenable for you. What are your thoughts?

With 3.0.0 out and 4.0.0 on the way, we've finally addressed most of the "cruft" in this library without making huge, sweeping, breaking changes. However, some huge obstacles remain - such as the twisted class hierarchy and the strange naming of some of the credentials classes.

I'd like to start a discussion on refactoring this library post-4.0.0. I'm not one to throw out well-tested and proven code, but the code that is here needs to be better organized to suit our downstream clients and our users.

I want to put forth the idea of this package slowly migrating to two new packages: google.auth and google.oauth2. During the initial phases we'll retain code inside of and continue to publish the oauth2client package, but once complete the oauth2client package will be permanently deprecated.

The google.auth package will focus solely on server-to-server authentication. A rough idea of what this package will look like is:

• google.auth.default() returns the application default credentials.
• google.auth.service_account.Credentials credentials using a service account key to obtain an access token.
• google.auth.jwt.Credentials credentials using a service account key to directly assert credentials.
• google.auth.gae.Credentials credentials using App Engine identity credentials.
• google.auth.gce.Credentials credentials using the Compute Engine metadata server.
• google.auth.access_token.Credentials credential using a bare access token.

This package won't contain anything related to storage or end-user based credentials.

The google.oauth2 package will contain the remainder of the current library and focus solely on oauth2 user-specific stuff, better organized:

• google.oauth2.flow - generic flow that can be easily used with web frameworks.
• google.oauth2.credentials - user credentials with access and refresh tokens.
• google.oauth2.storage - a wrapper that allows credentials to be stored. etc.

What are you initial thoughts @nathanielmanistaatgoogle @dhermes @waprin @thobrla @anthmgoogle @elibixby @pferate & any others.

DictionaryStorage - implements an optionally-locked storage over a dictionary-like object.

Additionally:

• Storage now includes optional locking logic. Previously this was implemented in subclasses.
• Remove flask_util.FlaskSessionStorage and replaced it with DictionaryStorage.

This provides several much needed updates to GCE App Assertion Credentials

1. Properly populates token expiry
2. Retrieves credentials scopes from the metadata server
3. Allows credentials to use custom service accounts by providing an optional email field
4. Implements serialization/deserialization for this email field
5. Provides a project_id property using metadata server in preparation for a pull request addressing #471

Note: oauth2client is now deprecated. As such, it is unlikely that we will address or respond to your issue. We recommend you use google-auth and oauthlib.

So reading that message above, I think it's time to archive the repo. Any thoughts?

@broady @busunkim96 @crwilcox @tswast

Bumps django from 1.10.0 to 1.11.23.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.