As a non-hosting user, I don't want to expose details about my location to other users because that can be used maliciously and is not needed for any functionality of the app I'm using.
Currently we store all data we have about a user under a single path in Firebase RTDB: /Users/<id>. Some functionalities read the /Users or /Users/<id> path to aggregate user data so we can't set granular permissions within there because of the way Firebase RTDB security rules work. The result is that all user data can be read by anyone who has access to any user data. That is everyone on the web as long as #30 isn't fixed and all logged-in users after that.
To be more precise in what is and isn't allowed, I propose the following:
We keep /Users/<id> as-is, as a path that contains all data about a user that the platform has. This should only be accessible by the user themselves, back-end code in Cloud Functions to runs data aggregations, and admins;
We add a /Profiles/<user id> that is legible by all logged in users. We can add and remove data to/from /Profiles/<user id> as a user enables or disables functionalities. So the user's approximate location and host feedback would only be put in there if the user actually enables hosting. And when they disable it it goes away again. The user's email address will always be only in /Users and never in /Profiles because that's just for the platform to identify the user and should never be leaked.
We'll probably want to store the Profiles in Cloud Firestore instead of Real-Time Database because we're already using Cloud Firestore for the markers and it seems a better fit for our app in the long run.
Progress
As currently ongoing on branch feature/user-profiles:
[x] Set up security rules that allow only user themselves to access /Users/<id> in RTDB
[x] Make sure logging in still works
[x] Make sure logging out still works
[x] Make sure viewing the map at high level still works
[x] Make sure reading Country Wiki pages still works
[ ] Make sure users can still edit their own profile information
[ ] Make sure people can register as a user
[ ] Decide on a way to enforce the schema for Profile records
[ ] Write a Cloud Function to write /Profile records in Cloud Firestore based on the /Users records in RTDB
[ ] Port existing functionalities for user interaction to the /Profile system (to be expanded when we get here)
As a non-hosting user, I don't want to expose details about my location to other users because that can be used maliciously and is not needed for any functionality of the app I'm using.
Currently we store all data we have about a user under a single path in Firebase RTDB:
/Users/<id>. Some functionalities read the/Usersor/Users/<id>path to aggregate user data so we can't set granular permissions within there because of the way Firebase RTDB security rules work. The result is that all user data can be read by anyone who has access to any user data. That is everyone on the web as long as #30 isn't fixed and all logged-in users after that.To be more precise in what is and isn't allowed, I propose the following:
/Users/<id>as-is, as a path that contains all data about a user that the platform has. This should only be accessible by the user themselves, back-end code in Cloud Functions to runs data aggregations, and admins;/Profiles/<user id>that is legible by all logged in users. We can add and remove data to/from/Profiles/<user id>as a user enables or disables functionalities. So the user's approximate location and host feedback would only be put in there if the user actually enables hosting. And when they disable it it goes away again. The user's email address will always be only in/Usersand never in/Profilesbecause that's just for the platform to identify the user and should never be leaked.We'll probably want to store the Profiles in Cloud Firestore instead of Real-Time Database because we're already using Cloud Firestore for the markers and it seems a better fit for our app in the long run.
Progress
As currently ongoing on branch
feature/user-profiles:/Users/<id>in RTDB/Profilerecords in Cloud Firestore based on the/Usersrecords in RTDB/Profilesystem (to be expanded when we get here)