Repository navigation
FirestoreOptions not loading projectid from credentials correctly #3535
Description
I recently migrated from an older version (0.45) where I configured firestore using the FirebaseOptions, e.g.
GoogleCredentials credentials = GoogleCredentials.fromStream(new FileInputStream(_firebaseCredentialsPath));
FirebaseOptions options = new FirebaseOptions.Builder()
.setCredentials(credentials)
.build();
FirebaseApp.initializeApp(options);
_database = FirestoreClient.getFirestore();This works. I migrated to the new way of doing things with FirestoreOptions (0.56.0). I got warnings to change the configuration. So the resulting code is now:
GoogleCredentials credentials = GoogleCredentials.fromStream(new FileInputStream(_firebaseCredentialsPath));
FirestoreOptions fireStoreOptions =
FirestoreOptions.newBuilder().setTimestampsInSnapshotsEnabled(true)
.setCredentials(credentials)
.build();
_database = fireStoreOptions.getService();However, this code fails. It requires that the projectId field be set using .setProjectId("..."). In my case it defaulted to another project in cloud that did not have firestore enabled. Perhaps the default project in cloud? It's unclear. This seems like a bug. The project id is not available from the credentials API, even though it is there. Why is the projectid being ignored / not set from credentials correctly?
Reacted by Max Dudzinski
Activity
yihanzhen commentedon Aug 6, 2018
This should have been solved by #3472 and should have been included in 0.56.0. Can you double check the version you are using?
cc/ @schmidt-sebastian
marshallpierce commentedon Aug 7, 2018
I can confirm this, and that #3458 still is a problem. I'm using 0.56.0-beta.
For context:
val credentials = ServiceAccountCredentials.fromStream(stream)loads credentials from a service account json file that is an owner in a project set aside for running tests.setCredentialsProvider(FixedCredentialsProvider.create(credentials)), nosetProjectId:In other words, it's looking in the wrong place.
setCredentialsProviderwith aFixedCredentialsProvider.create(credentials), withsetProjectId: everything works.setCredentials(credentials), nosetProjectId:setCredentials(credentials), withsetProjectId:Which, I'm guessing, is it trying to use the default credentials on the test project's Firestore, which of course won't work. In other words, #3458. (Have I mentioned how much I dislike the concept of silent default credentials?)
For comparison, with 0.51.0-beta,
setCredentials(credentials), withsetProjectIdworks fine.daltonj commentedon Aug 8, 2018
Thanks for confirming.
+1 for (evil) default silent credentials
schmidt-sebastian commentedon Aug 9, 2018
I started looking into this, but I am not able to reproduce this exact behavior. In my tests:
Note the issue in
setCredentialwas addressed recently in #3413. Can you confirm that both your version of Firestore and of google-cloud-core is up to date (you should be at1.38.0)?marshallpierce commentedon Aug 16, 2018
I just replicated my results again to be sure. You can try it yourself: https://bitbucket.org/marshallpierce/ktor-session-gcp-firestore/src. Fiddle with the
withFirestorehelper in the test class to try the different scenarios.Here's the dependency graph for the google bits:
schmidt-sebastian commentedon Aug 16, 2018
@marshallpierce We have released the PR that should address this issue yesterday as part of 0.57.0. Do you mind upgrading and reporting back?
marshallpierce commentedon Aug 16, 2018
With 0.57.0-beta:
setCredentialsProvider, nosetProjectId: same as before (broken)setCredentialsProvider, withsetProjectId: same as before (works)setCredentials, nosetProjectId: same as before (broken)setCredentials, withsetProjectId:now workssame as before (broken)One down, I guess...Edit: in my first
setCredentialswithsetProjectId, I hadn't commented outsetCredentialsProvider, so it worked. WithoutsetCredentialsProvider, it's still broken. In other words, 0.57-beta is behaving the same as 56.charlesliqlogic commentedon Dec 28, 2018
@daltonj Does your credential file has {"type": "service_account",
"project_id": "project_id,} ?
sduskis commentedon Feb 21, 2019
If I read this issue correctly, this seems like "working as intended". The user / service account used by the application needs to have access to the project resources being accessed. In this case, it sounds like the permissions of the user being used didn't align properly with the code.
There is an effort to move away from the implicit permissions, but that's going to take some time. I don't see anything actionable on this issue, at this point, so I'm closing it. Please feel free to open a different issue to address documentation related issues around credentials.
chore(deps): update dependency com.google.cloud:google-cloud-bigtable…
test: enable more tests on the Emulator (#3535)
chore: support for UUID type (#3572)