Storage: Provide credential-free access to public-access buckets

[tseaver]

Per the GCS authentication doc:

Objects are anonymously accessible if the allUsers group has READ permission.

Add support for such access to the storage client. Two strategies seem possible:

• Add a classmethod factory to the Client class which bypasses inferring credentials from the user environment.
• Add a custom AnonymousCredentials singleton which can be passed to the Client constructor.

We don't need to enforce any limits on the access to buckets / objects retrieved from the "anonymous" client: the back-end will return UNAUTHORIZED.

System tests can use the gcp-public-data-landsat bucket, if desired (hopefully CI throttling won't be an issue).

[tseaver]

Notes:

• The core Client class insists that the credentials passed to it be either a) None (in which case it infers a set from the environment), or b) an instance of google.auth.credentials.Credentials (or a subclass).
• We probably have to pass in a custom _http instance, which will otherwise default to a lazily-created google.auth.transport.requests.AuthorizedSession instance.
• OTOH, it looks as though the AuthorizedSession class just wants the credentials object to have a before_request() method, which we could stub out as a no-op for the anonymous case, and a refresh() method, which shouldn't be needed, and could just raise.

[theacodes]

I'm totally open and +1 to the idea of "Null/Anonymous Credentials" in google.auth.

We could then make a nice helper constructor for storage:

storage_client = google.cloud.storage.Client.create_anonymous_client()

[tseaver]

@jonparrott I'm working on the AnonymousCredentials bit right now.

[theacodes]

Sweet.

[tseaver]

@jonparrott Is the classmethod-factory the surface you'd prefer? I had actually talked myself into making it just passing an instance of google.auth.credentials.AnonymousCredentials into Client.__init__.

[theacodes]

passing in anonymouscredentials should work, ofc, but I think if this is a common enough use case we should either (a) explicitly document how to do this and/or (b) provide a helper constructor.

[tseaver]

Awaiting release of (merged) googleapis/google-auth-library-python#206

[tseaver]

@chemelnucfin We don't really need the API name in the issue title for issues which have labels. Non-maintainers cannot assign labels, so we have started asking them to include the API name.

[chemelnucfin]

OK, I just figured it would be easier for everyone to see and use a similar format in the issues page if everything was more standardized.

…

On Mon, Nov 6, 2017 at 8:35 AM, Tres Seaver ***@***.***> wrote: @chemelnucfin <https://github.com/chemelnucfin> We don't really need the API name in the issue title for issues which have labels. Non-maintainers cannot assign labels, so we have started asking them to include the API name. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4279 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADzDDN4B6gi3gw4yqg0eksEISKOdJfkiks5szzU0gaJpZM4QLo5Q> .