1
votes

We are using Firebase custom authentication and want to define read/write access rules based on the "auth" payload data. However, for security reasons, we do not want to store the value of auth.uid anywhere in Firebase data. That is, since the user id for example is not part of the data, I cannot use the rule: auth.uid == newData.child("userId").val()

Is there a way to just pass data to Firebase only for checking in the security rule, but not actually persist the data in Firebase db?

1
What is the check that you're trying to do? As it stands this reads like a XY problem: meta.stackexchange.com/questions/66377/what-is-the-xy-problemFrank van Puffelen
Let me try to explain again. As per my understanding, the following variables are available when defining the Firebase security rule: auth, data, newData and $ variables... But my question is: can I define a rule that uses just the data passed to Firebase URL, but not actually stored as part of the data.user1790625
No you can't. Please explain your use-case, instead of explaining your solution.Frank van Puffelen
Thanks. Use case is: We are using custom authentication with Firebase. So our server would generate a session token for the user, which we would set in the auth as auth.uid... Then when a user posts a chat message to Firebase, our client app would send this user's session token to Firebase. We want to allow this message to be posted only if the user's session token passed by the client app matches with auth.uid for that user. Our concern is that we store this session token in Firebase as data, anybody who gets access to our Firebase data can see this user token and can post on user's behalf.user1790625
If you are generating a custom (JWT) token, you determine exactly what goes into the auth variable that is available to the security rules. So auth.uid will be exactly whatever uid you came up with for that user.Frank van Puffelen

1 Answers

1
votes

There are three possible sources of data for security rules: Hard coded strings, the database data, or the authentication token (i.e. auth).

You can generate your own authentication tokens, allowing you to specify any information you would like, without storing it in Firebase. Note that the contents of the security token cannot be forged by the user, but they can be read by the user; if your goal is to store some secret info users should not know, this isn't an option.

Note that you can secure any path in the database, so that it is not readable, store data in it, and security rules can still reference that data. Keep in mind that security rules cascade, so you want this data in its own path with no readable parents.

The security token mentioned in your comments sounds completely redundant of the user's auth token. If they have authenticated, you have already verified their uid, so it's unclear why a security token adds any additional value.