Support for multi-tenancy based on host_name

[spacebaire]

Hi

Is there any way that flask-dance supports multi-tenancy based on the host name?

I am in the process of adding multi-tenancy to my app (similar to https://stackoverflow.com/questions/51883773/flask-app-that-routes-to-multiple-top-level-and-sub-domains). I have set host_name=True on the Flask app, and use a converter on the host parameter of my routes, which determine which tenant is being accessed (via the url_value_preprocessor decorator). This gets stored in g.host_entity. This works for my other routes when navigating to various URLs.

I understand that I need to set up multiple URLs on the google credentials dashboard.

When I look at app.url_map, I can see the google related route (login/google/authorized and login/google), but it does not have the host parameter as the other routes in the map has.

Is this supported somehow, or is this in the roadmap?

Do you believe this cannot be supported within flask-dance? If it can, do you have some direction I can try to implement this myself maybe?

Thanks in advance, Baire

[singingwolfboy]

@spacebaire: I don't know anything about multi-tenancy in Flask apps, so I don't think I'll be able support this for you. However, I know a great deal about the architecture of Flask Dance, and you probably know a fair amount about multi-tenancy in Flask apps, so maybe we can put our heads together and figure something out?

Would you like to find a time to videochat and discuss your situation? I'd love it if Flask-Dance supported multi-tenancy, and I'd be happy to help you out if you could submit a pull request to make it more generally possible for others in the future.

[spacebaire]

Hi

I played around with a local copy and eventually found that adding the "host" parameter to the add_url_rule calls in BaseOAuthConsumerBlueprint does the trick. I had to set up several hosts on the google credentials dashboard I was testing my app with. I was however able to authenticate from any of the domains I had set up, which was the goal.

To add the "host" parameter, I think it is best to open this up a bit broader and allow for adding any parameter. I couldn't use *kwargs as it was already being used for something else, and I was worried there might be conflicts, so in the end I propose that we add a rulekwargs (dict) on the make_blueprint calls, which then gets passed down (via OAuth1ConsumerBlueprint and OAuth2ConsumerBlueprint), until we can use them. If they have kept their initial None value, then they are effectively ignored. If the dict contains a value, then it is passed into both the login and authorized rules.

There are three potential concerns with my solution:

• If someone passes (rule, endpoint or view_func), then it might raise an exception as the parameter will be passed twice. I originally made it so that it overrides these three parameters, but as they are unique to login or authorized, I did not go through with it.
• The pull request opens it up for adding any parameter. I like this approach, but it might be too permissive for some. I'm not fully sure what the consequences of this can be.
• I do not know anything about tox, so did not manage to get the tests running that was. I did however run them directly with pytest using python3.9. I do not think there is anything that is not python2.7 compatible.

Please have a look at the pull request I submitted and let me know if you think this approach makes sense to add to flask-dance. (There were 3 files that conflicted, but I believe I've corrected them). From my initial testing I believe it is sufficient for my needs, and hopefully opens things up for other possibilities as well.

Regards, Baire

[singingwolfboy]

@spacebaire The change you made in #358 is now published in Flask-Dance 5.0!

[spacebaire]

@spacebaire The change you made in #358 is now published in Flask-Dance 5.0!

Thank you! I'll give it a try and let you know if I face any issues.