Is it possible to use ApplicationDefaultCredentials for SignUrlOption?

Currently Storage.SignUrlOption receives com.google.gcloud.AuthCredentials.ServiceAccountAuthCredentials, but how to use ApplicationDefaultAuthCredentials with that method? I think we should allow using ApplicationDefaultAuthCredentials if possible.

I think there should be an interface for Credentials and use it as the argument, just my 2 cents

Indeed as of now you can only explicitly set com.google.gcloud.AuthCredentials.ServiceAccountAuthCredentials.

However if you don't specify it signUrl may still work based on your service auth config (if it is configured with AuthCredentials.ServiceAccountAuthCredentials or using ApplicationDefaultAuthCredentials AND the default auth config is associated with a service account.

ApplicationDefaultAuthCredentials is not required to be associated with a service account (and provide private-key).

Ok, thanks! I didn't know that you can not use the GCE service account for signing URL. However, isn't it appropriate for that method to receive an interface? Especially if there is a possibility that GCE service account can be used for signing in the future (I'm not sure though).

Related:
http://googlecloudplatform.github.io/gcloud-python/stable/storage-blobs.html#gcloud.storage.blob.Blob.generate_signed_url
googleapis/google-cloud-python#922

@ajkannan

Yes, we could do something similar to gcloud-python and accept AuthCredentials instead of the specific ServiceAccountAuthCredentials but similar to the Python API this class does not expose
in its API a service-account or private key.

We could still get it and then reject any instances that are not known to us to support the signing.
I don't like that such enforcement is a run-time failure but maybe that is not too bad as a runtime
failure is already possible when not providing anything.
Also, I don't like that this way a user could not implement its own AuthCrendentials to work
with the signing as the signature does not specify it.

We could define a Signing interface and make some of our AuthCrendentials credentials implement it.
I am +1 for it. Is that what you are suggesting?

@ajkannan is it something that you will be interested in and have time for it?

@aozarov

@aozarov Yeah, that seems a right approach!

Sure, I can take this issue.

For the record the proposed change will allow us to support signing on App Engine (and we plan to do so). However, it is still not supported via the default compute engine credentials.