On 19/07/2014 3:51 AM, Subodh Nijsure wrote:
This is the first time I am trying to implement multi-tenant setup under django and hence the question.Problem/Setup - There are two companies signed up for service from portal I am developing say CompanyA, CompanyB. - Each user with this setup is identified by unique email address, users login using their email address and password. - CompanyA has following users A-tech1 A-tech2 A-tech3 - CompanyB has following users B-tech1 B-tech2 B-tech3 Requirements: 1. Data security/isolation: Technician A-tech1, A-tech2, A-tech3 should only be able to view data associated with companyA. Same for B-tech* technicians should only be able to see data from companyB. 2. Scalability: CompanyA, CompanyB might be of different sizes - companyA might have 10 users. While CompanyB might have 10000s users representing large customers. 3. SLA: There might be different service level agreement with companyA & companyB. I think, it doesn't make sense to lump data related to companyA, companyB into same database. Proposed Architecture Possibilities: Path 1: - system will use one replicated database for authentication/authorization - When a company is registered within the system, 'Administrator' will assign a company to specific database connection. And request will be routed to correct database using database router, based on currently logged in user. See https://docs.djangoproject.com/en/dev/topics/db/multi-db/ for multi-db applications under django. Path 2: Do the url based routing c1.company.com , c2.company.com in apache server setup and let apache configuraion refer to different wsgi.py scripts to set proper values for DJANGO_SETTING_MODULE. And each settings file points to different databases. Are either of these approaches (1 or 2) work better?
Another possible approach (in Postgres) is to keep everything in the same database but segregate the private tables into different schemas. Normally in Postgres everything goes into the public schema and you deal with privacy using decorators and logic. But you could use non-public schemas as a different segregation level. I'm not sure how easy or otherwise that might be using Django.
I have a similar if not identical privacy/segregation requirement which needs to be solved before I can advance from prototype to production. Hence I'm very interested in how you solve yours. Please share ...
Mike
-Subodh
-- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/53C9C227.7020405%40dewhirst.com.au. For more options, visit https://groups.google.com/d/optout.
