Flowise icon indicating copy to clipboard operation
Flowise copied to clipboard

Feature: Allowed domains for chatflows

Open 0xi4o opened this issue 1 year ago • 5 comments

  • Adds an allowed domains dialog for chatflows where users can whitelist which domains can access the chatflow. By default all domains are allowed. If a list is present, then only those domains can use the chatflow prediction, either from embed or API.

flowise-allowed-domains-settings flowise-allowed-domains-settings-2

0xi4o avatar Feb 20 '24 11:02 0xi4o

I'm a little confused why you'd use this over CORS or CSP? They do the same thing but at a lower level to ensure no access can be done at all except from the whitelisted domains.

automaton82 avatar Feb 24 '24 03:02 automaton82

the intention is to allow the chatbot to be embedded on specific domain: image

HenryHengZJ avatar Feb 24 '24 09:02 HenryHengZJ

Yea I get that but that's the same thing CORS does. Except CORS will pass security tests since the preflight options will also fail when not on an allowed domain.

It's the same functionality just at the level where it's expected. Otherwise they'll be tempted to set CORS to * and use this new config instead which isn't secure, since any domain will be able to access the REST API, regardless of this setting.

If you remember I mentioned this on the other ticket. The very first request xdomain sends is OPTIONS preflight check. This is before any logic can be done about a chatbot ID, thus CORS is in the HTTP pipeline and configured at the env level.

automaton82 avatar Feb 24 '24 13:02 automaton82

If your goal is to solve multi tenancy in cloud hosting (1 host per N clients) then better to solve it with actual accounts and tenancy, where you keep the tenancy as the initial request and sticky it somehow through all subsequent requests.

Anyways just my $0.02 😄

automaton82 avatar Feb 24 '24 13:02 automaton82

Yea I get that but that's the same thing CORS does. Except CORS will pass security tests since the preflight options will also fail when not on an allowed domain.

It's the same functionality just at the level where it's expected. Otherwise they'll be tempted to set CORS to * and use this new config instead which isn't secure, since any domain will be able to access the REST API, regardless of this setting.

If you remember I mentioned this on the other ticket. The very first request xdomain sends is OPTIONS preflight check. This is before any logic can be done about a chatbot ID, thus CORS is in the HTTP pipeline and configured at the env level.

yeah I think there are 2 level of users for Flowise, for devs its always welcomed to set the env variables CORS for that. For no-code users they might not be familiar with the CORS and setting env variables, so this is an alternative, although it doesnt solve at the very root level, but still offers some protective mechanism at the very least

HenryHengZJ avatar Feb 24 '24 13:02 HenryHengZJ

@HenryHengZJ I've updated the error message for a non-whitelisted domain. Please review this.

0xi4o avatar Mar 05 '24 08:03 0xi4o