Hi, I have built a Meteor website with user create-able subdomains. I want to add Oauth logins with e.g. Facebook, so I added the accounts-facebook package, however Facebook Oauth configuration doesn’t allow wildcards to be specified in the website and /oauth/facebook callback URIs.
I read somewhere it can be done by adding the subdomain name as state parameter to a fixed-subdomain redirect URI, and then use this state subdomain in the fixed-subdomain Facebook response. However, since (Facebook) Oauth handling is all being taken care of by Meteor Oauth libraries (e.g. accounts-facebook), is there any way this can be achieved in Meteor?
Looked a but further into this… one of the first obstacles is that the Meteor Oauth server seems to use the ROOT_URL environment variable for creating the service destination and callback uris, which means that there is no way to use a different subdomain than the one specified in ROOT_URL.
This is a real pity, but it looks like it can’t be done with the current Oauth Meteor libraries as far as I understand. Can anyone confirm this?
Thanks for your response. Let me clarify a bit further:
Our website can be visited via different urls, e.g. ‘project1.ourwebsite.com’, ‘whateverprojectxxx.ourwebsite.com’ etc. These project subdomain names can be created by logged-in users that have specific access rights to create projects. Currently our log-in capabilities are handled by the standard accounts-password and accounts-ui packages, which works well, users can login to any of our subdomains, once they created an account to one of our subdomains.
Now we would like to add e.g. Facebook/Google login capabilities too, so as a start, I added accounts-facebook, and followed all necessary steps.
It turns out the Facebook login only works on one subdomain, being the one that is specified in the ROOT_URL environment variable, e.g. “project1.ourwebsite.com”, and only if I specified the same subdomain in the Facebook developer pages.
So, the restriction is rather on the facebook developer page, that forces you to enter one url per subdomain? Also - does every subdomain reflect a single app or are these just “routes” that in the end point to one single app?
You could still use only one subdomain for all authentications Like auth.mywebsite.com and decide access to subdomains via Roles. Would that bei a viable Option?
Hmm… I don’t think this would work. In that case users would have to login in ‘auth.mywebsite.com’, but as soon as they go to ‘theirproject.mywebsite.com’, their login is lost, and they can’t login there.
Right, I fortgot the localstorage is bound to the current domain realm so your key is lost when switching domains. Hm this is not easy. Two questions from here:
is it really necessary to have subdomains (instead of client routes + dynamic-import)?
And setting multiple redirect URIs like shown here is not an option? It would require to update the whitelist every time a new subdomain is created, though.
Tried that already too, despite the fact that then indeed I would have to add each subdomain to the list manually, but it didn’t work either, because Meteor server Oauth library only “listens” to one subdomain: the one specified in the ROOT_URL.
Pairing multi-tenancy with subdomains might just be attractive in our minds as software engineers, and it may not matter to our customers at all. So ultimately project1.myapp.com/whatever may be the perfect equivalent of myapp.com/project1/whatever for most people who use it. Just my 2 cents.
What you propose is indeed functional equivalent, however it’s all about perception: the project creators want to let it appeal as their own website to their users/clients. John Doe advertising his potential clients to visit “johndoe.domain.com” looks better than pointing them to “domain.com/johndoe”.
I do understand I only should use one subdomain to Facebook. I don’t understand yet though how to achieve this exactly. Could you please elaborate a bit more on each point, e.g. where to do this, on Meteor client or server side? I probably need to dig into the current Meteor oauth packages I suppose to find out how to achieve this.
I’m not sure that clients share that perception with us, but it’s your call entirely. If I were you I would probably survey both clients and project creators, and only go through all this trouble with subdomains if I had hard evidence that it has indeed impact on the product.