I’ve also run into another roadblock with multitenancy: server side rendering.
In publication functions, this.connection.httpHeaders.host (which is normally set to mytenant.127.0.0.1.xip.io:3000 in local development) is localhost:3000 in a server context.
Appears the semi-official best practise with Mongo is to use a separate database (same server) for each tenant.
-Easy deployment for new tenants…
-Easy security with different encryption key for each tenant.
-Easy to extract a tenant’s data when they don’t pay their bill.
Worth watching if you are interested in SAAS with Mongo.
How are you managing direct calls to the url and routing ?
Say you have a request to http://cake.domain.com/
This will load the tenantId, and populate the session.
If on the other hand the user makes a direct call to the url through - i.e. browser URL bar (as opposed to through the app) - then session variable isn’t always in context and doesn’t have the tenantId data at all.
Trying to get this to work with FlowRouter. Namely cake.domain.com/foo,
foo's route doesn’t have the session data, when called directly; but if navigated through the app it does.
Subdomain and routing with Meteor is proving interesting
Yeah, that’s where it gets a bit tricky. I just live with a lot of round-trips to the server and a lot of loading spinners when someone hits a route directly from the browser URL bar.
Once the app’s client side state is all loaded up via a hideous web of reactivity (where results from the server trigger another round-trip, the results of which trigger another round-trip, etc.), then navigating to new routes within the app is nice and snappy (as the client app state is all in place). But that first start up time is a bit grim …
Yeah, it’s not an elegant solution, but it’s easy and it works. I’m currently happy enough with the time from initial html/js bundle load to round trips finished / page fully rendered. That said, if anyone comes up with something slicker, I’m all ears.
I thought I’d post in this thread as it’s been useful so far to me in developing my multi-tenant strategy.
I looked at DB-per-tenant but it seems to complex and expensive right now. So I’ve been taking the approach which is quite similar to @babrahams I believe but simpler. I store the tenantId in the user doc but never let it onto the client. All of my publish functions look like this:
I might need to start deducing the tenant from subdomain though. My issue is that if each tenant can have multiple clients invited into the system, how do I allow a user to be added by two different tenants? So joe@blogs.com for tenant A is different to joe@blogs.com for tenant B.
My current thinking is that if I prepend the tenantId to their email and store that in meteor.users as their username that will solve the issue. Then when logging in on a tenants subdomain I believe I would just need to use the setCustomSignupOptions in Account UI to generate their username from their email and tenantId.
It’s a bit late but that’s exactly what http://keycloak.jboss.org/ does. You define tenants (realms) on which you can enable almost any existing authentication protocol. Your application just talks oAuth2 with keycloak (JWT also supported).
This is a great approach. I currently pass the tenant ID from the subscription on the client, but will have to take a look at this approach of just grabbing it on the server instead.
I have two tenant-related items stored on the user object:
currentOrg is a string representing the organization that the user is currently logged into. This is used as a variable for all publications.
tenants is an array (actually, really should be an object) of all the organizations a user has access to.
Then I use the Roles package to manage permissions within each tenant by matching the Roles group to the tenant ID.
When I create a new user, I first check if the email address already exists, and if so just append the tenants credentials to their user profile and send a separate welcome email.
I know there’s ways to make it better, but that seems to be working for now. Like you, I’d like to better understand how to setup Nginx to use subdomains.
The approach I use is very similar to that of @allenfuller.
Note: you can get away without using nginx at all to manage subdomains. Just make sure your DNS has a wildcard subdomain record like:
* IN A 101.102.103.104
Then do this on the client. (That’s a link to post earlier in this thread detailing how I get the tenant from the subdomain using client side code and a method call.)
I admit, this is not a particularly elegant approach, and requires more round trips than anyone would like, but it does work.
Template.navMain.helpers({
currentOrg: () => {
return Meteor.user().profile.currentOrg;
},
// Checks if the user is a user for more than one organization, or a global admin
multiOrgs: () => {
let userId = Meteor.userId(),
orgs = Meteor.users.findOne({_id: userId}, {fields: {organizations: 1}}),
admin = Roles.userIsInRole(userId, 'admin', Roles.GLOBAL_GROUP),
orgCount = orgs.length;
if (orgCount > 1 || admin) {
return true;
} else {
return false;
}
}
});
I hesitate to share code as I’m still pretty new to this myself. In fact, I think my whole approach started with what I read from @babrahams on this thread!
Cool. I have been thinking of the tenant separation as a very hard security line and doing everything to make sure someone from one tenant can never see another but your approach offers a lot more flexibility and has got me thinking. I’ll post back here again after I have a chance to try it out.
For my app, I’m imagining that one Meteor.user may belong to several organizations and it’d be ideal if they could switch between them easily without having to log in to each. I have a user model similar to the one @allenfuller describes here.
A few questions:
Are there any big benefits or downsides in Meteor with having the organization identifier in the subdomain (e.g. https://acmeco.myapp.com) vs the pathname (e.g. https://myapp.com/acmeco)?
If I use subdomains, does anyone have any tips on redirecting to a subdomain? In my sign up flow, I have a create organization step (/signup/organization), after which I’d like to redirect the user to their organization’s subdomain without making them log in. My attempts so far with Iron Router have not been successful.
If I use the pathname, e.g. myapp.com/:orgName, what’s the best way to handle routing with Iron Router so that on all logged in routes other than / the organization identifier is in the URL? e.g. https://myapp.com/acmeco/project/1.
Appreciate any insights y’all have. Special thanks to @allenfuller and @marklynch for helping me get this far.
This is an old topic, but I just wanted to chime in that I had been tinkering with this myself and found working with sub-domains is possible. I use nginx to front-end a single meteor project with a wildcard letsencrypt SSL certificate. My example app uses https://*.domain.devel.buzzledom.com and the underlying logic determines which domain I am trying to access and serves data accordingly.
I also use accounts:password, which means accounts are the same across sub-domains. By passing the localStorage.getItem('Meteor.loginToken') across sub-domains, I can authenticate via Accounts.loginWithToken(loginToken).
Also worth mentioning is that I figured out how to serve the proper favicon.ico per sub-domain from the filesystem, by virtue of the most powerful WebApp.connectHandlers. The static HTML simply points the the URL for favicon that is being handled by the server
I am currently considering implementing multi-tenancy in Meteor by separating the database for each tenant. I’ve read some useful discussions so far, but is it still challenging to separate the database for each tenant?
Let’s say, you own a SaaS which is being licensed to clients to server their clients. You need each of your clients to have their own tenant with tenant level authentication (confidentiality with you outside the circle) for them to server their own clients?
Is this the case? Or do you have complex security/confidentiality requirements such as SOX or military or medical?
I agree with paulishca. Separate databases for separate users is a DevOps nightmare. If it’s a very small app with very high-end, custom, specialized users… then they should have separate apps.
True multi tenancy from the SaaS perspective, where multiple users / organizations are using the same app for their own purposes, is best served with an ID on all data keyed to the organization and also baked into authentication.