We're still fairly new to MongoDB, and I'm curious if storing the user account in the same database as the data is really a wise idea. The db.createUser() documentation didn't seem to cover this topic, or I missed it while re-reading the page.
Where should I specify, especially when the account doesn't belong to only one database?
Should every account go inside the admin database?
Should I make a separate database for storing user accounts?
use someDb #<----what I'm wondering about when doing:
db.create({ "user": "someUser",
"pwd":"somePassword",
"roles":[
{"role": "readWrite", "db":"someDb"},
{"role": "readWrite", "db":"someOtherDb"}
]
})
Maybe a more experienced admin could guide me on some best practices here. As we're all learning, I need to make sure we're making good decisions.
Thanks in advance!
Related
I want to implement the like functionality in my app and im searching for a good solution when it comes to the database. Until now I looked at Firebase, and it seems it could the job when using sharding. As I am a beginner with DBs I thought of asking you.
What do you think?
Maybe AWS or something else has something suitable for this use-case?
Well, first of all I will choose the same DB as you are using to save users data.
If you don't have anyone yet, I will recommend you go with Firebase, it can handle your users sessions, social logins, databases and also you can implement a solution for the like functionality.
If your already using firebase, the realtime database should be best practice. Theres even an example with likes in the firebase rtDb Docs for web. But of course you should use react-native-firebase.
I am in the process of building a basic no-code solution to build RESTful APIS that support CRUD operations on a MongoDB collection. Right now it is just a Proof of Concept project that I use internally with no external users.
I saw this question on Stack Overflow the other day and I though that it could allow me to convert this little project into a SaaS concept.
Allowing users to create their own collections in MongoDB could be potentially insecure, but I couldn't think of any catastrophic consequence... Maybe the fact that malicious users can purposely create a collection that is horrible in performance? Or maybe the user could inject some references to other collections...?
Does having a separated Mongo database help to mitigate those attacks? Or could you give me more reasons why this is a bad idea?
Thank you very much!
You can manage user and privilege (on database, collections, etc..) with mongo through access control
https://docs.mongodb.com/manual/tutorial/enable-authentication/
https://docs.mongodb.com/manual/core/collection-level-access-control/
You can also create "capped collection" to limit the size of collections
https://docs.mongodb.com/manual/core/capped-collections/
I don't know exactly how you can limit "user performance" but i'm interested if you find an answer :)
I work for an app that store some health datas and the law and our ethic make us respect some rules about the treatment of personnal datas.
We want to store the health datas of our users in a different database than the personnal datas (especialy the name of the user). The goal is that if a hacker get access to the health database/server app, he will not be able to get the identity of the persons. And if he get access to the personnal data database/server app, he will not be able to get the health informations of the persons.
Anyone in my team never made this kind of thing, the client proposed this kind of structure
The goal is to have a middleware that manage authentification and provide the id of the personnal data database with the other one.
In my mind, we could make far better by using some asynchronous tricks but i'm not an expert in security and i only have a confused idea of what i could make. Maybe there is some standard solution that is used in this kind of situation.
It would be realy great to have some advice of the community about this problem.
Ok, so about a year ago I wrote a web app that helps organize appointments for my dads company. He now "couldn't do business without it". I have decided that I want to build a SAAS subscription model out of it and open it up to the public.
It's currently built on codeigniter and php which I do not think is a good fit for a SAAS version. I am planning on rebuiling it from scratch in laravel 4 and using stripe as a payment gateway.
My concern is how best to handle the database / application structure for more than one client. Currently, it just serves the one business and is very un-abstract and is specific to my dads companies needs. I need it to be able to handle different data depending on what the business who uses it does.
I have looked into multi-tenancy but i'm not sure this is right for this. I am thinking that a 'gmail' style approach would be better. One app / domain that after login the user will see their customised dashboard and only their data.
Before I get stuck in with the coding I need to work out how best to handle multiple 'accounts' on the one database. I do not want to create a table for each user, nor a database for each user.
I guess my question is can anybody point me in the right direction for how best to handle a monthly payment subscription in Laravel? It's not so much the code that I'm stuggling with, rather what exactly I would need to build to handle charging the customer each month and denying them access if billing failed etc.
Thanks
You are in for a lot of reading and a ton of work!
First of all, let's completely ignore the billing aspect of this for now — at the end of the day that portion of the application is really fairly trivial. Take a page out of 37signals Rework (page 93 and 94) and launch your product with a 30 day free trial before you even begin implementing it (you should know how to implement it by then).
Second, why do you think that "gmail" doesn't use multi-tenancy, URI structure tells nothing about the underlying database structure. I'm fairly confident they aren't cloning a database schema for every one of their customers. Therefore you've probably answered your own question — you want to implement multi-tenancy.
You're going to want to abstract your database (and application architecture), and honestly there is no better resource to help you on your way to doing that than Taylor Otwell's (creator of Laravel) book Laravel: From Apprentice To Artisan. His book is not for beginners, and by the time you're done reading it you should probably be able to answer this question for yourself.
You are not going to be creating a table or a database for each user, you aren't even going to be creating one for each organization. Instead you'll be creating abstract database structure in code, which will pull your users data out of the database.
Think about checking for permission to access an organization as another layer of user authentication. On every request you'll be checking to see if that user can access a particular organization. You'll likely also check to ensure that organization is still active (did it expire because they didn't pay?) this will again happen on every request and likely with a filter within laravel.
This really leads to the next very important factor of developing a SaaS application.
I don't know about you, but I'm paranoid, and I couldn't sleep well at night if I wasn't sure that user number 4506 couldn't see the data of an organization that he doesn't belong to. The only really good way to ensure this is through unit testing, which I'd highly suggest learning if you haven't already.
The best way to do this within Laravel 4 is to read Jeffrey Way's book Laravel Testing Decoded. This book is extremely advanced, but still easy to understand if you have a good grasp of the fundamentals.
Last but not least, the number one thing is get involved in the community — the easiest way I'd suggest doing that is idling on the #laravel IRC channel (freenode). Ask some questions, maybe answer some questions, everyone in the channel is very nice and responsive.
You are definitely in for an adventure, don't be afraid to ask questions and make mistakes. Good luck.
As a rough overview, I would have a clients table, and a subscriptions table. Any other data that needs storing such as contacts, or appointments, can be associated using foreign keys to the client table.
In laravel, you can use the ORM to get the currently logged in client, and then through a relationship, fetch appointments and contacts belonging to them.
There are some useful tools for laravel at cartalyst.com, including sentry and sentry-social for user auth, and integrating user accounts with facebook/google/twitter, etc.
Stripe will allow you to configure recurring payments, and will notify you via web hooks each time there is a payment attempt. you can log these in the payments table, and associate them with a user/client. you can use this to keep track of who has paid, and how recently.
Also, bear in mind that you may not want to cancel the account immediately on failed payment.
Stripe will reattempt, and it may be that your best response is after it is two or three days late, or you get an invalid card notification,to get in touch with the client and prompt them to update their payment details.
It may also be an opportunity to check when they last logged in.
If it was over a month ago you can credit them with a free month, and remind them of how much your app can do for them.
By doing this, you may be able to get people to continue using (and paying) for something they had forgotten they had subscribed to.
I have a web design issue regarding to performance to ask advice. On a web site, there are many personalized information, for example the friends of a user of facebook. Personalized I mean different users have different friend list.
Suppose friend list is stored in database like Oracle or Mysql, each time the user clicks Home of his/her facebook page or login, we need to read database again. Each time the user add/remove friend, the database needs some update operations.
My question is, I think the performance capability (e.g. concurrency of transactions of read/write) of database is limited, and if facebook is using database to store friend list, it is hard to implement the good performance. But if not using database (e.g. MySql or Oracle), how did Facebook implement such personalization function?
This is a pretty good article about the technology behind facebook.
As Justin said, it looks like a combination of Memcached and Cassandra.
Facebook and other large sites typically use a caching layer to store that kind of data so that you don't have to make a round trip to the database each time you need to fetch it.
One of the most popular is Memcached (which, last I remember reading, is used by Facebook).
You could also check out how some sites are using NoSQL databases as their caching layer. I actually just read an article yesterday about how StackOverflow utilizes Redis to handle their caching.
From what I can gather they use a MySQL cluster and memcached and lots of custom written software. They open source plenty of it: http://developers.facebook.com/opensource/
the solution is to use a super-fast NoSQL-style database. Start with Simon Willison's excellent tutorial on redis, and it will all begin to become clear :)