Created
December 5, 2016 08:01
-
-
Save asciimike/405c9bf6a1a48a8c17a61b6ff387eaae to your computer and use it in GitHub Desktop.
Firebase Storage "serverless" group permissions
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/* | |
You can create a Role Based Access Control system by storing ownership and access membership in the custom metadata of the file. | |
The proposed solution uses the existing "owner" "editor" and "reader" permissions. | |
If you store a user and the associated permission as a key/value pair in the file metadata: | |
// custom file metadata looks like: | |
metadata: { | |
"user:1234": "owner", | |
"user:5678": "editor", | |
"user:0912": "reader" | |
} | |
You can write rules as follows: | |
*/ | |
function isMember(group) { | |
return resource.metadata[request.auth.uid] == group; | |
} | |
service firebase.storage { | |
match /files/{fileName} { | |
allow read: if isMember("owner") | |
|| isMember("editor") | |
|| isMember("reader"); | |
allow write: if isMember("owner") | |
// prevents editors from changing custom metadata | |
|| (isMember("editor") && request.resource.metadata == resource.metadata); | |
} | |
} | |
/* | |
The owner would then have to add the new people to each file: | |
1) a user could write to the "file's access queue" in the DB | |
2) owners can listen for new requests | |
3) owners can then approve/deny the request by updating the file metadata accordingly | |
This strategy also means that the owner can easily revoke the permission without user approval | |
*/ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment