How to mazimize custom claims storage in Firebase?

user_11132658 0
Viewed 54

I'm currently using custom claims to store project-based permissions in my firebase app. However, I have quickly hit the 1000b limit due to lots of projects. The nature of the app means a user will be creating hundreds, if not thousands of projects.

Does anyone have any idea how to get around this size limit without resorting to storing permissions in rtdb (this would mean permissions aren't accessible throughout the Google ecosystem e.g storage).

I found this answer which implied I can somehow store single byte keys. Whilst my values are already a single character, my keys are UUIDs. How would I go about achieving condensing these keys? - somehow map a single byte to a UUID? I'm currently using claims on the client, cloud functions, and in db rules.

An alternative I was contemplating was to use custom JWT tokens as, as far as I can tell, these might not have the same size limit for claims.

Any help would be appreciated!

firebase-security google-cloud-functions firebase-authentication firebase-realtime-database firebase
1 Answers

The custom claims are sent from the client to the server with every request. I'd seriously reconsider trying to add more than the default limit of ~1K to each request, and in fact would typically look for another approach well before that.

Instead of storing individual project IDs, consider if there is a way to turn those into a more limited set of roles. This may be a lossy operation, where you lose some nuances of the existing model. For those differences, you can consider accepting them, or them encoding the exceptions into the token again as (a much smaller set of) custom claims.

If neither of these is feasible, the idiomatic approach is to store the ACL into a secondary system (such as Realtime Database you mention) and look it up there. You can't do such a lookup from within the Storage security rules though (as you mention), so you will have to wrap (read) access to Storage in a custom API. In the case of write operations, you can consider allowing them to a more broad set of users, and having a Cloud Function (or periodic process) perform a cleanup of uploads by rogue users.

user_2091030
Related