I have different types of users(admin, employe, user) in my mongo db and I wanted to ask what the best strategy is to handle this scenario.
1)Should I use mongoose schema extend so I can query on just one schema type(for example at registration) ?
2)Should I handle every user type for it self?
3)Is there a better solution you would recommend ?
4)Would you save permissions for each user type in the db or in a config file?
I guess the question is basic, but since I dont have any kind of experience on this field I am glad to get some good advise from you guys :)
It kind of depends what you want to do.
If users can have different sets of properties, I would suggest using a separate model per user type, and splitting your database into different collections per user type. I don't have experience with mongoose schema extend so I couldn't really comment on that, but it seems to be made for this scenario.
If you have roles that you also need to account for, and that you want to store in the database (e.g. for easy configuration and changes later on), perhaps you should look into a relational database because in this case you're talking about relations (between the user and the roles) and MongoDB isn't really the best choice for that.
If you don't need to store the user roles in your database (e.g. if they're hardcoded in your application) and your users don't have different properties, you could simply add a usertype property to your user model, and just check which value it has wherever you need it in your application.
Disclaimer: I'm no MongoDB expert, this is just from my own experience :)
Related
I'm having a lot of trouble figuring out how to organize my business logic in mongoose. I'm pretty new to MongoDB and still trying to figure out everything.
So, I'm trying to achieve what socialite from Laravel does, I need to login with Facebook, check if the user is already registered, if it is, just login, if it's not, then register with the info from facebook.
I created a providerAccount and a user model. The providerAccount is the schema with the Facebook ID and userId relation, the user is the user's schema with all the fields I need.
I tried to create a createOrGetUser() static in the user's schema, which should do exactly what I said earlier, the problem is I just don't know how to properly write this function nor if this is the correct place to write it.
Should I require() the providerAccount inside my user model and keep chaining the queries and ifs or there is a better way to do this kind of logic?
Thanks!
I have a PouchDB app that manages users.
Users have a local PouchDB instance that replicates with a single CouchDB database. Pretty simple.
This is where things get a bit complicated. I am introducing the concept of "groups" to my design. Groups will be different CouchDB databases but locally, they should be a part of the user database.
I was reading a bit about "fancy replication" in the pouchDB site and this seems to be the solution I am after.
Now, my question is, how do I do it? More specifically, How do I replicate from multiple remote databases into a single local one? Some code examples will be super.
From my diagram below, you will notice that I need to essentially add databases dynamically based on the groups the user is in. A critique of my design will also be appreciated.
Should the flow be something like this:
Retrieve all user docs from his/her DB into localUserDB
var groupDB = new PouchDB('remote-group-url');
groupDB.replicate.to(localUserDB);
(any performance issues with multiple pouchdb instances 0_0?)
Locally, when the user makes a change related to a specific group, we determine the corresponding database and replicate by doing something like:
localUserDB.replicate.to(groupDB) (Do I need filtered replication?)
Replicate from many remote databases to your local one:
remoteDB1.replicate.to(localDB);
remoteDB2.replicate.to(localDB);
remoteDB3.replicate.to(localDB);
// etc.
Then do a filtered replication from your local database to the remote database that is supposed to receive changes:
localDB.replicate.to(remoteDB1, {
filter: function (doc) {
return doc.shouldBeReplicated;
}
});
Why filtered replication? Because your local database contains documents from many sources, and you don't want to replicate everything back to the one remote database.
Why a filter function? Since you are replicating from the local database, there's no performance gain from using design docs, views, etc. Just pass in a filter function; it's simpler. :)
Hope that helps!
Edit: okay, it sounds like the names of the groups that the user belongs to are actually included in the first database, which is what you mean by "iterate over." No, you probably shouldn't do this. :) You are trying to circumvent CouchDB's built-in authentication/privilege system.
Instead you should use CouchDB's built-in roles, apply those roles to the user, and then use a "database per role" scheme to ensure users only have access to their proper group DBs. Users can always query the _users API to see what roles they belong to. Simple!
For more details, read the pouchdb-authentication README.
I am using nodejs, and have been researching acl/authorization for the past week. I have found only a couple, but none seem to have all the features I require. The closest has been https://github.com/OptimalBits/node_acl, but I don't think it supports protecting resources by id (for example, if I wanted to allow user 12345 and only user 12345 to access user/12345/edit). Hence, I think I will have to make a custom acl solution for myself.
My question regarding this is, what are some pros and cons to storing roles (user, admin, moderator, etc.) under each user object, as opposed to creating another collection/table that maps each user with their authorization rules? node_acl uses a separate collection, whereas most of the other ones depend on the roles array in user objects.
By the way, I am using Mongodb at the moment. However I have not researched the pros and cons yet of using relational vs. nonrelational databases for authentication yet, so if let me know if your answer depends on that.
As I was typing this up, I thought of one thing. If I store roles in a separate collection, it is more portable. I would be able to swap out the acl system much more easily. (I think?)
The question here seems like it could be abstracted from "where should I store my roles" to "how should I store related information in Mongo (or NoSQL in general)". It's a relation vs non-relational modeling issue.
Non-Relational
Using Node + Mongo, storing the roles on the user will make it really easy to determine if a user has access to the feature, given that you can just look in the 'roles' property. The trade off is that you have lots of duplicate information ('user_read' could be a role on every user account) and if you end up changing that property, you'll need to update it inside every user object.
You could store the roles in their own collection and then store the id for that entry in the Roles collection on your User model, but then you'll still need to fetch the actual record from the collection to display any of it's information (though arguably this could be a rare occurrence)
Relational
Storing these in a relational DB would be a more "traditional" approach in that you can establish the relationships between the tables (via FKs / join tables or what not). This can be a good solution, but then you no longer have the benefits of using a NoSQL database.
Summary
If the rest of your app is stored in Mongo and has to stay there (for performance or whatever constraint) then you are probably better off doing it all in Mongo. Most of the advice I've come across says don't mix & match data stores, e.g. use one or the other, but not both. That being said, I've done projects with both and it can get messy but sometimes the pros outweigh the cons.
I like #DavidWelch answer, but I'd like to tackle the question from another perspective because the library mentioned gives the option to use a different data store entirely.
Storing roles in a separate data store:
(Pro) Can make the system more performant if you are using a faster data store. (More advantageous in distributed environments?)
(Con) You will have to ensure consistency between the two data stores.
General notes:
You can add roles/permissions such as 'blog\123' in acl. You can also give a user permissions based on verbs such as put, delete, get, etc..
I think it is easier to create a pluggable solution that does not depend on your storage implementation. Perhaps that is why acl does not store roles in the same collections you have.
If you choose to keep the roles in your own collection, consider adding them to a token (JWT). That way, you will not have to check your collection for every request that needs authorization.
I hope that helped.
Building a REST API with Express.js and Mongoose on node - I have stumbled upon a code design issue - where should I handle relationships - in models or routers?
First, I am pretty new to the MVC and such, and even though express.js is not a full MVC, I would like to follow best design practices.
The issue is rather easy - the app has users, each user can have multiple documents (projects, orders, etc). Obviously I have to at least store the user ID for every document that is created. The question is - where should I do that?
I can get the user ID from the session in each router and attach it to a document, or I can just set the current user ID to a global variable, for example app.currentUserID and use that in my model to attach the ID to the document.
There are actually more interesting cases, where a user can have multiple organizations, and I have to set the organization ID for each document that the user creates when operating with a specific organization.
So the question is: should I handle this kind of logic in my router (express does not have 'controllers' as such) or model?
Do it in the model. Even if you're not creating an enforced relation, storing the actual ID of a related object still changes the model, so there's no reason to leave the logic in the router.
MongoDB (and Mongoose) doesn't have referential integrity like relational databases do. This means that the database will not give you an error if you insert a relation to an object which doesn't exist. It lets the application code handle those relations.
Mongoose is an attempt to bring structure to an otherwise pretty liberal nosql DB. As such, it offers an ability to create such relations with the ObjectId schema type.
Read the following SO answer for more info: https://stackoverflow.com/a/7813331/1801
say i have two collections in mongodb,one for users which contains users basic info,and one for apps which contains applications.now if users are allowed to add apps,and the next time when they login, the web should get the user added app for them.how should i construct this kind of database in mongodb.
users:{_id:ObjectId(),username:'username',password:'password'}
apps:{_id:ObjectId(),appname:'',developer:,description:};
and how should i get the user added app for them??? should i add something like addedAppId like:
users:{_id:ObjectId(),username:'username',password:'password',addedApppId:[]}
to indicate which app they have added,and then get the apps using addedAppId???
Yep, there's nothing wrong with the users collection keeping track of which apps a user has added like you've indicated.
This is known as linking in MongoDB. In a relational system you'd probably create a separate table, added_apps, which had a user ID, app ID and any other relevant information. But since you can't join, keeping this information in the users collection is entirely appropriate.
From the docs:
A key question when designing a MongoDB schema is when to embed and when to link. Embedding is the nesting of objects and arrays inside a BSON document. Links are references between documents.
There are no joins in MongoDB – distributed joins would be difficult on a 1,000 server cluster. Embedding is a bit like "prejoined" data. Operations within a document are easy for the server to handle; these operations can be fairly rich. Links in contrast must be processed client-side by the application; the application does this by issuing a follow-up query.
(this is the extra bit you'd need to do, fetch app information from the user's stored AppId.)
Generally, for "contains" relationships between entities, embedding should be be chosen. Use linking when not using linking would result in duplication of data.
...
Many to many relationships are generally done by linking.