I am creating a portal with multiple apps. The users will come from one of multiple companies. I want to lock down access to individual apps and access only that user’s company’s data.
For example, I want user1 from company company1 to have access to app1 but not app2. However, user1 to have access to company1 data.
I can just tie all the users to a specific company in the user record. Then I can tie all client data to a specific company. I can then write the queries to only bring back data that is tied to the users company. However, this just seems to have the potential for some security issues. It also seems a bit kludgy to have a company ID in almost ever db record.
I have never done something with multiple databases or used the database routing. However, it seems like it would allow me to create per company databases. Then I could keep all the apps generic but database routing to connect an individual user to their database.
I would love to have some confirmation that multiple databases is a valid way to go and works well in situations like this, some pointers in some other directions, or to hear why my first concern shouldn’t be a concern.
edit: btw - I would leave all the users in the default database. I would just use a customer database for apps.
I wouldn’t even think about segregating this by database. That’s going to open a can of worms large enough that I wouldn’t want to deal with in my wildest nightmares.
If I were looking at something like this, I’d create custom managers that applies your desired filters when querying these objects. (Some of the detailed answers would be very specific to the models being used - there’s not really a generalized answer I can provide to that.)
(And I definitely wouldn’t sweat about applying a company ID for those tables needing it. It doesn’t need to be in every table - if a table has a reference to another table with the company ID, the queries can follow the references.)
Thanks for the response. Over the last hour, I came to the same conclusion about multiple databases. It just breaks too many other things (like migrations). I didn’t know about managers. This looks perfect Thanks!
I can confirm that having the data in the same database is the prefered way to implement multi-tenancy. If separate databases are an unavoidable requirement, things can get a bit nightmarish, but only the kind where you’re late for an exam, not the kind that makes you wake up screaming. Things only get really tricky if you share the same model across all tenants and you require separate databases and you also want an API on top of that. We had that problem and came to a somewhat undjangonic solution, as described here: Struggling with application structure for multi-tenant system