Comments (11)
I'd like to understand this better.
The main http-oauth2 assembly does not have a hard dependency on this. It makes a late bound call to the SDK method that tells you definitively if you are running in a GAE process. Only if true does it make a second late-bound call to the appengine-specific auth component. That in turn has a hard dependency on the appengine-api-i1.0-SDK. So this should avoid needing to take any app-engine related .jar file along for non GAE scenarios, either the SDK or the auth component.
For the case where you are running in GAE, the app-engine specific component does have a hard depedency. But any app-engine app will also have this dependency. Is there a case on App engine where you want to dependent on the app-engine specific auth component, but not the app-engine SDK?
from google-auth-library-java.
The gcloud-java
library supports users running on App Engine, but it can also be used from outside of App Engine. As a result, gcloud-java
has to take the appengine module as a dependency (and thus pull in the SDK jar), even if a user happens to not be running on App Engine.
from google-auth-library-java.
It is also the case that the Http-OAuth2 component is used inside and outside app engine. In both cases there is a late bound call for good reasons. The OAuth2 libraries also don't take a direct dependency on the App-engine SDK. Only the App-Egine-specific component does and that is itself already invoked late bound by the Oauth2 component.
from google-auth-library-java.
@anthmgoogle gcloud-java
has one artifact for all platforms.
As I see it, in the current state, that means we have 2 options:
-
Add to our pom a dependency on
google-auth-library-appengine
and pay the price of depending and pulling 17Mb even when not needed. -
Direct people that use
gcloud-java
on AE to also add a dependency ongoogle-auth-library-appengine
I would like to avoid (2) in all cost. I think we can also avoid (1) by using the suggestions mentioned above.
Do you think we can avoid pulling appengine-api-1.0-sdk
without requiring gcloud-java
users on AE to add the dependency themselves?
from google-auth-library-java.
Having gcloud-java dependend on google-auth-library-appengine seems wrong, because this will also pull that binary around for non GAE scenarios. It is currently small, but when 3LO logic is added, it will be bigger and have more of its own dependencies.
I'll follow up on the tradeoffs related to (2) shortly.
from google-auth-library-java.
Any updates on your take on this issue @anthmgoogle?
from google-auth-library-java.
Thoughts on the tradeoffs of using reflection for the GAE identity.
Without reflection a GAE app needs to know about this indirect dependency. Without it, they will fail when they try to get the application working for the first time. It would be better if this "just worked".
The GAE credential could be implemented completely in reflection to address the getting started dependency above. The biggest cost I can see is that this will add a per-request reflection call to get the access token. In common synchronous cases, this is probably dwarfed by the network round-trip. But in async or CPU-bound cases you may want to avoid it. A secondary cost is that reflection code is more costly to write and maintain.
For the code in gcloud-java this has the additional benefit of saving a whole compilation unit. This is not the case for the auth libraries, because App-Engine specific surface is needed for explicit use of App Identity and 3LO.
One way to solve both the performance and getting started issues is to implement a second fall back component in reflection and only use it if the app-engine auth library is not present. Cost is in duplicated logic. A performance-sensitive customer may prefer initial failure to silently falling back to a slower mode of operation.
It may be worth understanding ways of mitigating the the getting started problem:
- Ensuring all GAE samples have this dependency.
- Adding this dependency by default to GAE templates.
- Ensuring the error message when the assembly is missing is very specific. (It already should be, but we can test whether people are getting confused by it).
- Documentation in appropriate locations.
I think there is a nuanced tradeoff. I can see the appeal of eliminating one more piece of getting started friction. However, steps that have very clear failure modes don't cause much friction, and there is long term benefit in having a single, fast implementation.
from google-auth-library-java.
To be clear, as of today we are only talking about this simple class.
Therefore, I don't think changing this class to use reflection is a big deal (maintenance wise).
Reflection should happen only when calling appIdentityService.getAccessToken(scopes)
, which
is using an RPC call, therefore the cost of the reflection part should be negligible.
If you insist of not using reflection, did you consider the maven proivded
scope option?
One of the nice things about gcloud-java is the easy setup and get started. I would really want to avoid
this extra documentation and setup step. Therefore, if you choose to keep it as is, we will keep our existing reflection based AE credentials (though we can clean it up to match AppEngineCredentials.java
) and use it as a fallback.
from google-auth-library-java.
Going through the steps of setting up reflection is slow, but calling invoke()
isn't all that slow if on a hot-path.
I'd find it hard to believe that calling invoke()
each getAccessToken()
call could be prohibitive.
from google-auth-library-java.
OK. If the method can be cached this feature should be OK.
from google-auth-library-java.
This was fixed in #71
from google-auth-library-java.
Related Issues (20)
- Add reactor Bindings HOT 3
- The horror of chain reaction (GoogleCredentials) HOT 1
- Allow usage of ExternalAccountCredentials custom implementation HOT 2
- unchecked casts are bad practice, but allowed globally in pom.xml
- Add native image support for credentials and appengine modules
- impersonated_service_account not recognized HOT 1
- ExternalAccountCredentials serialization is broken HOT 1
- com.google.firebase.messaging.FirebaseMessagingException: Unknown error while making a remote service call: Error getting access token for service account: Unable to tunnel through proxy. Proxy returns "HTTP/1.1 405 Method Not Allowed", HOT 2
- [kms]: Missing credentials leads to misleading exception and pointless retry loop HOT 4
- DefaultPKCEProvider challenge rejected HOT 4
- Method implementation and logic isOnGAEStandard7() is incorrect for java21 jetty which does not define the old jetty logging class. HOT 2
- External documentation is outdated - latest published version is 1.20.0 HOT 1
- AppEngineCredential depends on legacy bundled service HOT 4
- Failing while building google-auth-library-java version v1.6.0 using mvn clean install HOT 6
- Migrating old GoogleCredential object to new GoogleCredentials object for OAuth HOT 4
- ComputeEngineCredentials.createScoped copies existing AccessToken HOT 4
- Previously, I use google-cloud-vertexai 0.3. I can't use service account json in 1.3. HOT 1
- Workload identity federation doesn't support full aws credential sources. HOT 2
- ComputeEngineCredentials does not handle error response from the metadata server correctly HOT 1
- Google Play Publisher with Proxy Authentication
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from google-auth-library-java.