You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 30, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 30, 2026. It is now read-only.
FirestoreOptions.setHost causes PERMISSION_DENIED errors from Firestore Emulator #190
I'm seeing a PERMISSION DENIED message when trying to clean my test data using collection.listDocuments():
io.grpc.StatusRuntimeException: PERMISSION_DENIED: Metadata operations require admin authentication.
com.google.cloud.firestore.FirestoreException: io.grpc.StatusRuntimeException: PERMISSION_DENIED: Metadata operations require admin authentication.
at com.google.cloud.firestore.FirestoreException.apiException(FirestoreException.java:94)
at com.google.cloud.firestore.CollectionReference.listDocuments(CollectionReference.java:141)
at MyTest.deleteCollections(MyTest.java:21)
This error has been reported before as firebase-tools#1363. The workaround that is mentioned in the referenced issue is not working for me. I have tried three variants of the same thing: setCredentials(), setCredentialsProvider() and setHeaderProvider().
It seems that some of these settings are being ignored by com.google.cloud.firestore.spi.v1.GrpcFirestoreRpc when the URL points to localhost.
The expected behavior would be a documented way to get admin permissions on the emulator, preferably through the Options object. Failing that, this workaround should work, and maybe make public static FirestoreOptions.FakeCredentials instead of just public (as is now), so it can be used by others.
I tried to reproduce the PERMISSION_DENIED error you ran into but wasn't able to do so. I tried a number of different methods (set, listCollections, listDocuments, get and delete) all were able to complete successfully when using the version of firebase-admin and gcloud you specified.
When running my program I set the FIRESTORE_EMULATOR_HOST environment variable to the value printed when starting the Firestore emulator via gcloud beta emulators firestore start.
Can you provide any more details about what types of operations you are trying to perform?
Hi @BenWhitehead, thanks for giving this a look. It seems that the exception is triggered when using options.setHost() instead of using FIRESTORE_EMULATOR_HOST. I created a minimal repro case:
Why is gax ignoring my settings when I'm using localhost? Leaving options out should be my responsibility, not the library's.
Using 127.0.0.1 instead of localhost sounds like exploiting a loophole to work around a different bug. Without knowing why these options are ignored for localhost, I don't know if this workaround will break in a future version of the client library.
com.google.cloud.firestore.FirestoreOptions.FakeCredentials should be public static so that it can be used by others (instead of copied & pasted).
The error should not be "PERMISSION DENIED" with this config, as the credentials have been provided.
"Admin permissions" sounds like a common case for any tests planning to clean up the database afterwards. Maybe add a specific flag in FirestoreOptions to gain admin permissions against localhost?
@icoloma Thanks for filling this issue, i think everything is setup in existing firestore client just we need to use FakeCredentials while creating ClientContext so I have already raised PR for that. below is the sample code which tested with localhost by updating current firestore client.
The original code that I assume @icoloma tried by setting the host to localhost:8000 to attempt to use the emulator should not cause the break that it does. There is currently a custom bootstrapping path that specifically replaces credentials with "NoCredentials when the host contains the string localhost This is error prone and what actually needs to change. Additionally, the way emulator connections work into the lifecycle of creating a client should also be cleaned up so that it isn't causing these sorts of errors for users.
The complexity of how the Firestore client is bootstrapped is very high, and is something I am actively looking at seeing if it can be simplified (including other clients as well like Datastore). When using the Firestore emulator, the intention is that the client is functioning as with admin level permissions to allow automatic index creations while developing. Everything @icoloma lists in #190 (comment) is correct, and needs to be accounted for in the fix.
For now, the workaround I recommend is "When using the emulator, only use the environment variable not setHost". I realize it isn't great, but unfortunately it's how the code is written right now.
I hope to have a more straightforward solution in the future, but don't yet have an estimated timeframe.
Activity
BenWhitehead commentedon Apr 21, 2020
Hi @icoloma,
I tried to reproduce the PERMISSION_DENIED error you ran into but wasn't able to do so. I tried a number of different methods (
set,listCollections,listDocuments,getanddelete) all were able to complete successfully when using the version of firebase-admin and gcloud you specified.The code I tested with:
And the output when I ran it:
When running my program I set the
FIRESTORE_EMULATOR_HOSTenvironment variable to the value printed when starting the Firestore emulator viagcloud beta emulators firestore start.Can you provide any more details about what types of operations you are trying to perform?
icoloma commentedon Apr 22, 2020
Hi @BenWhitehead, thanks for giving this a look. It seems that the exception is triggered when using
options.setHost()instead of usingFIRESTORE_EMULATOR_HOST. I created a minimal repro case:When I uncomment the line I get the
PERMISSION_DENIEDexception, even ifFIRESTORE_EMULATOR_HOSTis still set and has the same value.BenWhitehead commentedon Apr 23, 2020
Wow that's subtle, thanks for narrowing down the difference.
I'm going to change the name of this issue to reflect it's a config error in the service builder.
[-]Firestore Emulator with Java Client: PERMISSION_DENIED[/-]1 remaining item
icoloma commentedon Apr 28, 2020
This leaves some questions open:
127.0.0.1instead of localhost sounds like exploiting a loophole to work around a different bug. Without knowing why these options are ignored for localhost, I don't know if this workaround will break in a future version of the client library.com.google.cloud.firestore.FirestoreOptions.FakeCredentialsshould bepublic staticso that it can be used by others (instead of copied & pasted)."Admin permissions" sounds like a common case for any tests planning to clean up the database afterwards. Maybe add a specific flag in
FirestoreOptionsto gain admin permissions against localhost?Thanks for the workaround, I can use this.
athakor commentedon Apr 30, 2020
@icoloma Thanks for filling this issue, i think everything is setup in existing
firestoreclient just we need to use FakeCredentials while creating ClientContext so I have already raised PR for that. below is the sample code which tested withlocalhostby updating currentfirestoreclient.Code :
Output :
BenWhitehead commentedon Apr 30, 2020
The original code that I assume @icoloma tried by setting the host to
localhost:8000to attempt to use the emulator should not cause the break that it does. There is currently a custom bootstrapping path that specifically replaces credentials with "NoCredentials when the host contains the stringlocalhostThis is error prone and what actually needs to change. Additionally, the way emulator connections work into the lifecycle of creating a client should also be cleaned up so that it isn't causing these sorts of errors for users.The complexity of how the Firestore client is bootstrapped is very high, and is something I am actively looking at seeing if it can be simplified (including other clients as well like Datastore). When using the Firestore emulator, the intention is that the client is functioning as with admin level permissions to allow automatic index creations while developing. Everything @icoloma lists in #190 (comment) is correct, and needs to be accounted for in the fix.
For now, the workaround I recommend is "When using the emulator, only use the environment variable not
setHost". I realize it isn't great, but unfortunately it's how the code is written right now.I hope to have a more straightforward solution in the future, but don't yet have an estimated timeframe.
fix: refactor FakeCredentials (#325)
chore: release 2.0.0 (#309)
feat: add method to set emulator host programmatically (#319) (#336)
chore: release 2.1.0 (#345)
crwilcox commentedon Dec 1, 2020
Seems to me #319 will have resolved this.