I’m looking at creating a single app with multiple tenants for a few local clubs to use however I’m trying to understand if this is really possible when considering a single person (with one email account) may register with several clubs. These clubs would be tenants.
I’ve read a few posts on the forum that point to creating a “spoof” email address and then matching on this but I’m struggling to understand how this may work or if I’m complicating things too much?
I had thought of combining the users email address and the home app domain (I’d like to host each club on a subdomain of the main app domain i.e. club1.myapp.com, club2.myapp.com etc…) which would have allowed the user account to be unique but I can’t see functionality within the “create an account” function that would allow the joining of these two bits of text.
Another option I thought about was combining these two items of information on the form as a hidden field and then feeding this value into the “create account” function but would this be open to abuse i.e. could a user with a little javascript knowledge change the value as the data is submitted back to the server?
I have two questions that I’m hoping you can help with:
Am I making this too complicated?
Whats the best (secure) way of trying to create unique accounts that would suite this situation?
Hmm, I suspect that I’m making this too complicated!
I’ve just managed to combine the email address that the user is registering with and the app host name within the workflow “create an account” function but Bubble is validating this and reporting it’s not a valid email so this doesn’t look like an option…
@paul.york Lot of options to build a multi-tenant app. Here are a few points:
Emails to create accounts in your app have to be unique. If a user is part of many clubs, create a Club custom data type then add a field to User type which is a list of Clubs. When new user signs up, they can select from a list of Clubs and this will be saved to their User database entry.
You can have 1 domain or subdomain per app though we are working on a feature to support more. Currently, you can do myapp.com/club1 and myapp.com/club2 if each club has its own page or dynamically myapp.com.com/page/club1 where page and url updates for each club.
To get around above issue, you can have a main app with multiple sub-apps. Sub-apps are like any other app with the additional functionality that you can do a 1-click push from main to sub. This copies over design and settings from main to sub while keeping data unchanged on each app. With this method, you can have separate domains for each app/club. You can also log users into a sub-app with the credentials of a main-app (details).
On initial review the first item looked like a good possible option but as i started out reworking the app that I have, I realise this would still leave a user having one password for all clubs. i.e if they change it for club 1, this affects there club2 membership.
I’d based my initial concept on building a single saas like app that could be funded on a subscription base from each club using it. The intention was that as each of the clubs are separate entities so it would appear that the users accounts were too.
I can technically understand how to separate the users details by subscribed club but but this still leaves the password which is 1:1 with the account so it’s not quite there.
The 3rd option may cut it but it possibly gets too complicated for a few local clubs and at the tier that it’s available this will simply be out of the budget for all concerned.
I have a few other thoughts on how I may manually build it but I’d rather avoid this if there is a simpler / better / path all ready walked…?
The final option is always to reconsider user experience and re-work it so they do have access to all of the clubs via one identity that they are members of but this then introduces more complexity in the membership vetting workflows.
@paul.york Looks like you are on the right track and exploring different approaches. Last few points:
Login with a social network can also be a good choice instead of email/password.
App login is just to register them as a user for your app and for administrative purposes like tracking actions in server logs, send password reset emails, setting privacy roles/permissions for access to each data type/field/page/element etc.
If a user has a separate profile for each club, one approach is to create a Club Profile data type with fields including a passcode which users need to enter to access a club’s page without which they are redirected to the index page.
You can add these individual Club Profiles to Club thing as Members/Applicants and to User thing as Applications/Created Profiles.
