Solved

Firebase: what is the lifecycle of a custom claim?

  • 12 June 2022
  • 2 replies
  • 289 views

Badge +1

I’m tinkering around with RevenueCat for an app my company is releasing Q4 this year. We use Firebase as a simple backend.

Context:

One of our features is the submission of images for server-side processing. The submission of a job is done via a Firebase cloud function, and the abilities of the user to submit these jobs can be different depending on the user’s current subscription/entitlements. As such, it is important that the custom claims on the Firebase auth token are up-to-date when the backend function is called. Otherwise, the user might make a purchase to attain some feature, and not be able to access it immediately because the Function will reject their request.

 

Question:

When are the custom claims set, and can I expect them to be available immediately in my Firebase functions after a purchase?

More specifically, if I await any calls into RevenueCat when a purchase is made, will all Firebase functions called from that point onwards have the custom claim set in the request? Or is there some delay/asynchrony expected?

 

We’ll use the React Native purchases API if that is relevant.

icon

Best answer by Jens 12 June 2022, 12:36

View original

2 replies

Userlevel 5
Badge +7

Network requests are involved, so some delays may occur. The way it works is while you are awaiting RevenueCat purchases, a call is made to the RevenueCat backend, which updates the subscription status in our backend. That subscription status change then asynchronously triggers a request being made to Firebase, which gets processed in a Firebase Cloud Function which updates the custom claim. Your await does not wait for this request from RevenueCat to Firebase. The likelihood is relatively high that the request that updates the custom claims happens before a following request from your app reaches the Firebase backend, but it definitely isn’t guaranteed.

Hope this helps!

EDIT: One way around this would be that instead of relying on custom claims you call the RevenueCat REST API from your Firebase backend to confirm the entitlement of a customer, this would always work.

Badge +1

Thanks for your quick response, Jens. I guess I’ll just call out to the REST API from my server.

I did some reading and it turns out claims are only updated after manually refreshing the ID token and don’t propagate automatically. The Firebase docs have an example where the backend Function that sets a new claim also uses a RTDB field to tell the client to refresh its ID token, which would then be populated with that new claim.

It would be nice to have a feature: when I make a purchase, I want to wait for the claim to be added before proceeding. Maybe a flag to set on a purchase that makes RevenueCat wait for the the Firebase function to set the claim and respond, before then responding to the client? Though we’d still have to refresh the ID token once that purchase request comes back.

My use case doesn’t seem uncommon, and this interaction might otherwise limit the utility of custom claims for entitlements. Even for client-only claim checks the issue would crop up.

At the very least it seems like a bit of a gotcha and might be worth a note in your own docs :)

Edit: I’ve submitted a feature request for the above.

Reply