I'm new to MongoDB and I am trying to create a database for students in classes. As I will have multiple classes all with different users, how can I make sure that users are able to only see other users in their own class (or just information on themselves would be even more preferable), while only using 2 collections. One collection holding the class information and one collection holding all the user information. This is to ensure that there are no privacy breaches.
Thanks in advance!
Related
I'm building an application where a user can have multiple identites. These identities hold public information and thus should be readable by anyone while the user behind the identities should remain private. However, the user should often be able to manage their application through multiple identities at once.
- Users [collection] (private)
- Identities [collection] (public)
It may seem obvious that identities should be a sub-collection of user documents so that the user can efficiently query all their identities. However, when other people query one or multiple identities through collection group queries, the path to these documents become visible to them as demonstrated by the answer to this question (using querySnapshot).
This poses a problem for me as this would allow people to link multiple identities to the same user, which is a privacy issue.
I could store the identities as a top-level collection, and maintain an array on the user documents, but this makes querying a lot less efficient as many reads spanning multiple identities would require as many queries as identities.
- Users [collection] (private)
- array of identity ID's
- Identities [collection] (public)
Is there actually a way to hide the parent relationship in collection group queries? And if not, are there more optimal architectural designs for my problem?
There is no way to hide the path to a document from someone who can read that document.
You'll have to find another way to implement your use-case, either through an additional collection, or by encapsulating your search functionality behind a custom API (like a Cloud Function).
I want to save a document to a collection in MongoDB.
I have users collections provided by accounts-ui and accounts-password in meteor.
I would like to save documents that owned by multiple users.
I know I can do this using insert function. But I would like to know what is the better way to do this? How can I do this?
For example, the user created an object and save it to the collection. Then the user will share it to other users.
This is a fairly broad question and therefore hard to answer. One approach could be to use the alanning:roles package which will allow you define roles, and also groups.
Your documents could be assigned to either a role or a group, and then the retrieval code can check their access in returning the documents.
I have 2 groups of users on my website. One is user and the other one is admin. Currently I put them in 2 different collections user and admin. My questions is:
Mongodb generates _id automatically for both collections. Since they're in 2 different collections chances are one day you created one user and one admin with the same _id right? I have a table keeping track of user / admin balances so I certainly don't want the _id to collide.
I can also put all users and admins in one collection. This way I don't have a problem but I am not sure if I should do this.
Any comments are greatly appreciated. Thanks!!
There is a very very low chance that you will have collisions.
Yes, you could put users and admins in one collection and then have a 'type' attribute that differentiates regular users and admin users. I don't know your requirements or why you have them in separate collections currently, so I can't say if you should or shouldn't do it, but it sounds like it would make some things easier.
I am creating a web service using Meteor.
I am designing the model, and I have stumbled across a difficult problem: Mongo is not designed to work with joins. However, I must logically associate a user with a subscription (which is an object that has many properties in it).
Therefore, my question is this:
Should I embed the subscription model into the Meteor.users collection, or should I create a new collection called "Subscriptions" and fight my way through manual joins? The reason why I am hesitant to use the first solution is that Meteor.users is a collection that is being handled by Meteor's Accounts and Password frameworks. Sure, you can embed a "profile" object upon creation, but how is this method going to scale up afterwards?
I would appreciate any insights on this..
I use the Meteor.users collection to store custom data all the time, there's nothing to prevent you from modifying it by adding additional fields, just keep in mind the following:
There are certain fields Meteor treats specially, be careful not to break them.
By default a user is only allowed to see their own profile, username and id, you'll need to write your own publication if you want the user to be able to see other fields, such as a custom 'subscriptions' collection.
Several of the Meteor used fields are security sensitive, when writing logic to allow a user to update subscriptions you need to take care that you don't allow a user to edit those fields.
http://docs.meteor.com/#meteor_users
Update:
I'm not entirely sure about the performance implications of adding subscriptions to a user record, since I don't know exactly what you're going to store in the subscription, or how you want to use that data. We tend to use user specific subscriptions a lot in our apps, eg:
Meteor.publish({
'userSubscriptions': function () {
return Subscriptions.find({userId: this.userId});
}
})
I'm trying to model a simple, experimental app as I learn Symfony and Doctrine.
My data model requires some flexibility, so I'm currenty looking into the possibility of using either an EAV model, or document store in MongoDB.
Here's my basic requirements:
Users will be able to store and share their favourite things (TV prog, website, song etc).
The list of possible 'things' a user can store is unknown. For example, a user may want to store their favourite animal.
Users can share their favourite things with other users. However, a user can decide what he / she shares with each other user. For example, a user may share their favourite movie with one user, but not another.
A typical user will log in and view all the favourite things from their list of friends, depending on what his friends have decided to share. The user will also update their own favourite things, which will be reflected when each other users views their own profile. Finally, the user may change which of his friends can see what of his favourite thing.
I've worked a lot with Magento, which uses the EAV model extensively. However, I'm adding another layer of complexity by restricting which users can see what information.
I'm instantly drawn to MongoDB as the schemaless format gives me the flexibility I require. However, I'm not sure how easy (or efficient) it will be to access the data once it's saved. I'm also concerned about how changes to the data will be managed, e.g. a user changes their favourite film.
I'm hoping someone can point me in the right direction. This is purely a demo app I'm building to further my knowledge, but I'm treating it like a real-world app where data access times are super-important.
Modelling this kind of app in a traditional relational DB makes me sweat when I think about the crazy number of joins I'd need to get the data for one user.
Thanks for reading this far, and please let me know if I can provide anymore information.
Regards,
Fish
You need to choose a model based on how you need to access the data.
If you just need to filter out some values when viewing the user profile, a single document for each user would work quite well, with each favorite within that having a list of authorized user/group IDs that is applied in the application code. Both read and write are single operations on a known document in this case, so will be fast.
If you need views across multiple profiles though, your main document should probably be the favorite. You'll need to set up the right indexes, but performance shouldn't be a problem.
Actually, the permissions you describe don't add that much complexity to an EAV schema - as long as attributes can have multiple values the permissions list is just one more attribute.