Functions v2 authType is 'unknown' when using emulator

[Bindslev]

Related issues

[REQUIRED] Version info

node:

v18.8.0

firebase-functions: firebase function: v2

firebase-tools:

firebase version: 13.12.0

firebase-admin:

[REQUIRED] Test case

1. Sign up to firebase auth / firestore / functions
2. Create a login page
3. Create a function that is triggered on a firestore collection write/update/delete
4. Use "onDocumentUpdatedWithAuthContext" or any of the other methods with the AuthContext
5. Notice that event.authType is unknown when developing locally using the firebase emulator after the use is logged in and authenticated

[REQUIRED] Steps to reproduce

I haven't found any documentation about this not working in the emulator, so I suppose it happens for everybody?

[REQUIRED] Expected behavior

I was expecting for the authType to not be unknown, and be able to retrieve the authenticated users ID using event.authId

[REQUIRED] Actual behavior

I get this:

authType: 'unknown', authId: '[email protected]'

Were you able to successfully deploy your functions?

Yes

[Bindslev]

To anyone stumbling upon this issue, authType and authId actually works using emulators. Remember to use emulators for all firebase services for them to connect. I did it like this:

await FirebaseAuth.instance.useAuthEmulator('192.168.0.153', 9099);
FirebaseFirestore.instance.useFirestoreEmulator('192.168.0.153', 8080);
await FirebaseStorage.instance.useStorageEmulator('192.168.0.153', 9199);
FirebaseFunctions.instance.useFunctionsEmulator('192.168.0.153', 5001);

[Bindslev]

Seems like it wasn't working anyway. I thought I authorized using the emulator but even after adding these lines of code it still somehow authorized without emulator and now after getting the emulator to work with all of these firebase products, the auth doesn't produce the userId I was expecting

[aendel]

+1

[JU-2094]

This is WAI (the change was adding the types & payload template but not the dependency getting the values ). I'd change the type to FR.

Notes for impl: As an initial option , the emulator context has the jwt token - we can check if it has the information.

[google-oss-bot]

Hey @Bindslev. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[blikblum]

@JU-2094 @harshyyy21 what kind of feedback do you need?

Just tested with latest firebase-tools v13.15.3 and is always returning :"authType": "unknown" | "authId": "[email protected]"

This is limiting us to use functionality since we can not test locally

[IIlllII]

We have the same issue. Makes it very hard to test some features locally.

[meteorainer]

Same issue here. I can log in and sign up from within my app locally, but can't test responsive code with auth context because const { authType, authId } = event; always returns authType: unknown, authId: [email protected]

[peterlauri]

Same issue here. I can log in and sign up from within my app locally, but can't test responsive code with auth context because const { authType, authId } = event; always returns authType: unknown, authId: [email protected]

Thumbs up on the issue to get traction. Same for @IIlllII and @aendel

[google-oss-bot]

Hey @Bindslev. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[IIlllII]

Hey @Bindslev. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

oss-bot aka spam-bot ☝️☝️☝️☝️

[meteorainer]

Posting for recent activity. +1 for attention

[robbymarston]

+1 also experiencing.

[meteorainer]

Updating to respond to the type being changed. This is not a feature request. The expectation of getting actual FirestoreAuthEvent info from the emulator seems reasonable.

[BrunoAMSilva]

This is stopping me from testing new user flow. This is definitely a bug and not a feature request. We should get uid in authId in the emulator.

While this isn't fixed is there any way to work around this limitation? I mean other than going through the pain of setting up a secondary firebase project for testing.

[danielc1771]

+1 experiencing this as well

[aaronseaton12]

Have the same issue as well. Is there any other way to get the uuid of the user that changed the document?

[BoveFabio]

I also want to stress that the emulator providing the correct auth information is actually a prerequisite to using triggers with auth context in production (for my team).

Triggers with auth context seem like a great addition and would likely benefit our projects significantly but we need to make it work locally.

[treighmawaka]

+1

[adesmet]

I am relying heavily on event-based flows, and I love that firebase enables this so effortlessly. However, without this specific feature, things are hard to test locally.

When testing with a single user, I have a pretty solid workaround by creating a user in the emulator and manually assigning it the id "[email protected]".

Now I'm at a stage where I need several users logged in simultaneously to test some more complicated flows, and then this stops working sadly. Looking forward to having the emulator earn its title and actually emulate the cloud behaviour. I certainly don't agree with @harshyyy21 when he labeled this a feature request. This is a bug - and judging from the comments, one with quite significant impact.

[LuukvE]

@harshyyy21 This is a bug, not a feature.

[momo3334]

+1 Plz fix this, it prevents us from doing local development.

[adelespinasse]

The actual behavior in production doesn't seem to be well documented. This page says "For information about the data available in the authentication context, see Auth Context." But the page it links to is not Firebase-specific, and doesn't make clear what the values of authType and authId would be for e.g. Firestore triggers.

This is the behavior I've observed in production for Firestore document creation triggers:

• When the document is created from the front end of a web app using the normal firebase package, authId is the ID of the logged in user, and authType is (IIRC) "api_key".
• When the document is created through the firebase-admin Node.js package using a service account (as typically happens from a Firebase Cloud Function), authId is the service account ID, and authType is (IIRC) "unknown".

Those are definitely not the values I would have predicted for authType, but I guess changing them might break existing apps. I don't know, maybe it would be reasonable to change it to "service_account" for service accounts, since "unknown" could mean "I don't currently have a way of knowing how this type of change is made, but I might in the future."

Whatever the behavior is in production, it would be good to make the emulator do the same thing, and to clarify the documentation.

[adelespinasse]

Oh, also the Auth Context doc page mentions an authclaims attribute, but that doesn't seem to be defined in the corresponding TypeScript type in the firebase-functions package. I'm not sure whether that's an oversight, or if there was a design decision to leave that out for Firebase. I don't have an opinion on this, except that it seems to be a disagreement between the documentation and the code.

[omarbrrr]

Any updates on this? I need to check whether an update was made by an user or a service account to prevent loop updates, and this bug in emulator mode makes me rely on a staging environment for testing, which defeats the purpose of having emulators running locally

This is definitely not a feature request, since on production it's able to identify correctly the authType, and the emulator should replicate the same behavior

[alan-insam]

Any workaround?

[MoaidAlrazhy]

unfortunately, the issue still open after more than a year !

[jakehockey10]

Keeping this fresh with another report of: I'm running into this as well. This breaks entire features that otherwise work in an a dedicated environment (activity tracking, for example).

Still not quite sure why this is marked as a feature request. Seems like that's probably why this isn't getting much attention. But did I miss the explanation as to why this isn't being considered a bug?

[iSuslov]

The behavior is not documented anywhere, values seem to be counterintuitive even in production environment. This requires attention.

[IIlllII]

That this issue is not a priority is very concerning. Especially that it is ignored and labeled a «feature request».