I'm looking to move my json file to an database service. I've been looking at Firebase-- Firestore in particular.
What the website is, is a collection of recipes.
Users can search for recipes by category. Or they can search by typing in ingredient.
I dont need to have users signing up and logging in.
Its not overly clear to me:
If this service can be used as a 'read only' database to populate the website with what the user selects.
If the database can be secure yet not have users sign up and log in.
Can anyone direct me to documentation/tutorial on the "how to" to have the data itself secured, but available for read only and without needing users to create log-ins.
Thank you,
Lee
Yes
Yes
You need to look into security rules to make sure your public read-only data is actually read only: Just allow read: if true for each collection that you want to give access.
Related
I've been trying to understand the differences of one-to-many and many-to-one relationships in nosql databases. I purchased a few courses on this and Firestone security rules language and have a basic grasp of it all, but I can't think of an efficient way to make a document accessible with a group of people.
I'm trying to implement an application where a user can have a profile and add users to be able to visit the profile/page as well. The only way I know how to do this is to add a field of allowed users to a document and when a user pulls the document down if their ID isn't in that field of permitted users then the profile won't display. I understand this is horribly flawed in that the user was still able to read the document and could rewrite it if permissions aren't set correctly. The only security in this method is hoping that no malicious users no the file path to where documents are stored.
Does anyone know how to properly add a group of users to be able to access a document in firebase?
So far I've implemented UID authentication in Firestone rules to ensure that a user is authenticated, but still any authenticated user can read or write any document in the app I'm demoing around with right now.
I also know you can create custom user types in firebase. This doesn't seem a valid solution for my application since I want to create a custom 'group' for each user that has a profile. Any advice would be greatly appreciated.
I am making a web app but I'm a little confused as to how I should give elevated permissions for the administrators. For instance, here, I want regular users to be read-only and admins to obviously have read and write permissions. How should I go about defining that? Any insight would be very much appreciated!
You want to add custom claims to your user accounts. It is also common to add a 'role' field (or similar) to user documents in Firestore.
That alone doesn't do you any good. You also need to protect your reads and writes with Firestore security rules where you can check if the user requesting a resource has a access to the document.
Is this a common/reasonable Use case?
An app allows a user to save favorites locally so that the user doesn't need to signup.
Then the user afterwards desires to share their favorites.
Therefore favorites data needs to be synced from local to remote. The usual local storage for flutter is sqflite, and firebase/store is the remote. However, this seems cumbersome, as sql to nosql conversion is necessary.
I thought that this would be a general issue for UX etc, but I can't find any discussion of this issue? Maybe forcing the user to create an account is the most general solution?
It's a common understanding that if you don't have user account then you can't have any user data associated with your name. You don't have to force the user to have an account or lock them out.
When they favourite something just show a dialog telling them "If you don't have an account your favourites are stored on the device only. If you want your favourites to be available everywhere please create an account" then show options for "Create account" or "No, Thanks"
Create account: Goes to account creation page
No, Thanks: Adds the device to the favourites list and lets the user continue to do what your app does.
There's no problem to solve here from what I'm seeing. If you don't have an account you don't get account functionality. If you track users without them entering anything it's also a little bit illegal and creepy so no need to push the limits on how you can track the same user.
Another way to think of it is to make signup so easy they don't mind and also guarantee that it's worth it. Won't be used for spam or information selling. Take what's app as an example, even though you need to mobile number to send the messages, it's just used as a unique identifier and has nothing to do with the device's number.
Ask for their phone number or email or just any email, you'll most likely get fake info.
And what does your analytics say? Are you getting requests from users saying they lost all their information on a different device? How many people are using your favourite functionality?
I may have come to the party a little late here but here's my 2 cents worth.
The Sql to NoSql conversion is not cumbersome. In fact, there is a reasonable use case for this. I have the same requirement for an app that I am about to build.
Anyway, to store data in RDMDB or NoSQLDB you will need a data model to ensure consistency in your app. If the user has been using the app offline, and they later choose to go online, you can allow them to create the Remote Account, then check if they have local favorites. If they do, you will HAVE to ask them if they'd like to import them into the remote storage. If they choose to do so, you will then have to read their favorites from the local storage and store them in a List<Model> then map() that back to the online storage.
NoSqlDB can accept the json type data, so your model should include the conversion fromMap() and toJson() for this purpose (and others).
When I have come around to doing this, I will share my code (if I remember to come back here).
Is it possible to create a realm where everyone has read access, but users can only modify objects that they create? An example would be a forum where any user can post and all users can see all posts, but only the user who made the post can edit it or delete it.
No, it is not possible.
The permissions for Realms are global to the Realm.
To get your desired behaviour, you would need to use multiple Realms.
Each user has a Realm which they write into.
Users have write permission to their own Realms, and read permissions
to all the others.
I'm new to meteor and I've reading a lot however I'm a little confused around the meteor.users collection and the best way to use it. My interpretation of the best practice guide is that meteor.users collection should only be used for managing the accounts.ui package; email, password and username. The guide states that profile is insecure, a flaw in the original meteor design and should not be used.
So my question is, if I want to create a user profile that contains things like first name, last name, age, address, avatar etc do I create a separate collection like 'userProfile' and link it using the meteor.userid or am I suppose to keep it in the meteor.users collection somehow
Common practice is to put user profile information such as the kind you're describing into Meteor.user().profile. In fact people often do much more, for example memberships in groups, arrays of postIds, all kinds of things. Keeping a separate 1:1 profile collection is an option but there's no fundamental reason to do so that I can think of. On the contrary it makes things just a bit more complicated.
Update: As #jonatan points out in the comments, the Meteor Guide has now unrecommended the use of the profile field in the user document.
Instead they recommend storing custom user information as top-level keys in the user document. This is not only more secure but also more performant since incremental updates can get published over DDP on top-level keys but on sub-keys.
Meteor.user().profile is always auto-published for the current user even after the autopublish package has been removed. Information about other users is not published at all unless you explicitly setup a publication. In that case care must be taken to only publish those fields that should be visible to other users. For example you may only want to publish the usernames of other users and not their email addresses for privacy. You would do this with:
Meteor.publish('otherUsers',function(){
return Meteor.users.find({},{ fields: { 'profile.username': 1 }});
});
You might also restrict the set of other users that is published based on them being connected in some way to the current user to avoid publishing all users all the time.
You should also avoid publishing the services key which contains security information about the user (ex: the bcrypt of their password). As #David Weldon points out in the comments, you shouldn't put other security information in the profile either and you probably want a deny rule on the user modifying their own profile from the client.