Firebase Security Rules for a Multi-Chat Application

Question

I'm having trouble understanding what the security rules look like for an application that looks like this:

• One base with multiple chats.
• The moderator authenticates through a separate PHP application.
• Moderators have only permission to change their chat, they can read, write, update and delete anything in their chat room.
• Guests come and authenticate through a separate PHP application.
• Guests have read and write access, but may not delete anything.

My questions right now are as follows:

• Can rules be configured to meet all of these requirements? Or are there some requirements that cannot be met?

• To what extent should the PHP server interact with Firebase to notify Firebase of the existence of users?

Answer 1

First of all, check out this meaning , an example of which I dealt with some time ago for several chats.

• Yes. It is quite possible.
• PHP server? You do not need a server! :)

The data structure basically looks as follows:

# chats roughly equal "rooms" /chats/chat_id/users/... # a timestamp of when each participant last viewed the room /chats/chat_id/last/... # the messages sent /chats/chat_id/messages/... 

Safety rules are self-documenting. It uses a local copy of referential integrity.

 { "chat": { // the list of chats may not be listed (no .read permissions here) // a chat conversation "$key": { // if the chat hasn't been created yet, we allow read so there is a way // to check this and create it; if it already exists, then authenticated // user (specified by auth.account) must be in $key/users ".read": "auth != null && (!data.exists() || data.child('users').hasChild(auth.account))", // list of users authorized to participate in chat "users": { // if the list doesn't exist, anybody can create it // if it already exists, only users already in the list may modify it ".write": "!data.exists() || data.hasChild(auth.account)", "$acc": { // for now the value is just a 1, later it could be a read/write/super privilege ".validate": "newData.isNumber()" } }, // timestamps recording last time each user has read this chat "last": { "$acc": { // may only written by the authenticated user and if user is in $key/users ".write": "$acc === auth.account && root.child('chat/'+$key+'/users').hasChild($acc)", ".validate": "newData.isNumber()" } }, "messages": { "$msg": { // to write a message, it must have all three fields (usr, ts, and msg) // and the person writing must be in $key/users ".write": "root.child('chat/'+$key+'/users').hasChild(auth.account)", ".validate":"newData.hasChildren(['ts', 'usr', 'msg'])", "usr": { // may only create messages from myself ".validate": "newData.val() === auth.account" }, "msg": { ".validate": "newData.isString()" }, "ts": { ".validate": "newData.isNumber()" } } } } } } 

The moderator authenticates through a separate PHP application. Use a custom registration module to create a Firebase token for administrators. Apply the security rules in accordance with the data stored in this token.

Moderators have permission to change their own chat room ... This should be pretty clear just by expanding the user rights above.

Guests come and authenticate through a separate PHP application. Use a custom registration module to create a Firebase token for administrators. Apply the security rules in accordance with the data stored in this token.

(Or cancel your PHP application and just use Firebase baked with authentication !)

Guests have read and write access, but may not delete anything. To prevent deletion, use newData.exists () or newData.hasChildren (...) inside the ".write" rule.

Guests cannot cheat other guests. Authentication identifiers will prevent this.