Flowise
Flowise copied to clipboard
Feature: Allowed domains for chatflows
- 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.
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.
the intention is to allow the chatbot to be embedded on specific domain:
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.
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 😄
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 I've updated the error message for a non-whitelisted domain. Please review this.