Facebook Oauth login on wildcard subdomains

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?

Where so you want to include wildcards? In the Server or the Client? How are the Subdomains related to the oauth Workflow?

Edit: I didn’t understand from your first post the reason why the Subdomains are so imortant for the oauth workflow

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?

Every subdomain is landing in the same web app, we just behave differently, depending on the project specified as subdomain.

I think there are 2 obstacles:

  1. Facebook does not allow wildcards to be specified as subdomains

  2. Meteor only handles Oauth for one subdomain, the one specified in the ROOT_URL environment variable.

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)?
  • how often do user switch between subdomains?

Well, most users only go to their subdomain, so they hardly ever switch. Most users don’t even know the other subdomains.

I don’t want to sacrifice the subdomain scheme, because it is a nice way to go to “their” website.

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.

1 Like

Why not use only 1 subdomain for login?

  1. use login.domain.com
  2. complete oauth with facebook and login user
  3. update nonce key in user account
  4. redirect user to correct subdomain with nonce key
  5. Check nonce key and login user to that subdomain

This will require a custom login function

1 Like

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.

Currently mobile. You can check the documentation

We created our custom login handler and use these functions

1 Like

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.