Feat: Add server proxy for standalone deployment

[toi500]

Enhanced Chatflow Management and Security in Embed Server

This PR introduces significant improvements to chatflow management, security, and developer experience, making it easier to configure and deploy secure embedded chatbots.

Easy Flow Management with Environment Variables:

• Simplified Configuration: Replaced the single CHATFLOWS environment variable with a more flexible and scalable CHATFLOW_X format. Each chatflow is now configured with its own environment variable, making it easier to add, remove, or modify individual chatflows without affecting others. Example:

  agent1=chatflowId,https://domain1.com,https://domain2.com
  agent2=anotherId,https://anotherdomain.com

• Robust Validation: Implemented validation for chatflow configurations, ensuring that each CHATFLOW_X variable has the correct format and includes a valid chatflow ID and allowed domains.
• Clear Error Messaging: Added clear and informative error messages for invalid chatflow configurations, making it easier to troubleshoot and correct issues.
• Startup Prevention for Invalid Flows: The server will now refuse to start if no valid chatflow configurations are found, preventing unexpected behavior and ensuring a working configuration.
• Eliminated Wildcard Domains: Removed support for wildcard domains (*) in chatflow configurations to enforce explicit domain whitelisting and enhance security. Attempts to use wildcards will result in an error message, and the affected chatflow will be disabled.

Enhanced web.js Access Control:

• Domain-Based Restriction: Implemented domain-based access control for the web.js embed script. The script will only be served to requests originating from allowed domains defined in the CHATFLOW_X configurations. This prevents unauthorized use of the embed script.

Improved Documentation:

• Updated README.md: Significantly updated the README.md file with the following information:
  • Detailed explanation of the new CHATFLOW_X environment variable format and configuration options.
  • Comprehensive overview of the implemented security features, including API key verification, domain whitelisting, and request header validation.
  • Clear instructions and requirements for deploying the embed server to cloud environments.
  • Updated and practical implementation examples to guide developers.
• Updated index.html: Refreshed the index.html file with the latest embed script examples, demonstrating the new configuration options and best practices.

Embed Script Display Utility:

• Startup Display: Added a utility to generate and display the embed script code in the terminal on server startup. This provides developers with a convenient way to copy and paste the correct embed code for their configured chatflows.
• Chatflow Details: The displayed embed script includes information about the configured chatflows and their allowed domains, making it easy to verify the configuration.
• Colored Output: Implemented color-coded console output for improved readability and clarity of the displayed embed script and chatflow information.

Strengthened Server Security:

• Request Header Validation: Added validation for essential request headers in the validateApiKey middleware, ensuring that requests originate from legitimate browsers and further mitigating potential security risks.
• API Key Verification: Continued enforcement of API key verification for all API requests, except those explicitly whitelisted, ensuring that only authorized requests are processed.
• Domain-Based Access Control: Implemented domain-based access control for all proxy routes, restricting access to only the allowed domains specified in the CHATFLOW_X environment variables.

[toi500]

@HenryHengZJ, our friend @saatchi-david gave me a good idea tonight when we were talking on Discord.

We could extend the proxy to support multiple chatflows for the same deployment. I think that the easiest way to do this is by adding a CHATFLOWS JSON configuration:

Backend (.env):

CHATFLOWS={
    "default": "ce158a4f-989f-467b-9a9f4-d0f3f7def6b7, *",
    "support": "f5d84d3a-2c72-4853-8574-37a4a87dd5c4, www.support-site.com",
    "sales": "89b7e421-9f3a-4669-8a6f-9b7d3e31739c, www.sales-site.com"
}

Frontend:

<script type="module">
        import Chatbot from './web.js'

        // Support chatflow
        Chatbot.init({
            chatflowid: 'support/proxy',  // Uses support flow
            apiHost: 'http://localhost:3000'
        })
    </script>

[saatchi-david]

(Cross-posting from Discord) That's exactly the functionality I was hoping for. Awesome. Would be awesome to see something like that more baked into flowise, potentially as an addition to the "Allowed Domains" interface. Or maybe more appropriate to replace that tab with a "security" tab where users could specify allowed domains and toggle the proxy functionality.

On a related note, Henry mentioned exploring adding more control/security for the config overrides. Just thinking out loud, but I could imagine the security tab including a toggle to disable the config overrides as well.

Taking that a step further... it would be awesome if we could specify defaults for each of the config options from within flowise, preventing the need to handle so much with the embed. Then from flowise, have the overrides disabled by default, and have the option to enable specific ones as needed.

This would consolidate configuration to the flowise interface, simplifying setup by reducing the need to update code, and by default create a more secure setup. Then if users need to control something via override, they can enable only what they need, e.g. maybe only the session ID, and not have the risk of things like prompt and model being overridden by the user.

[toi500]

-- off topic --

@saatchi-david, I don't want to go off-topic too much here, but I agree 100%. The overrideConfig limitation is definitely something they are already cooking, and I think it is a brilliant idea. It will reduce the risk of hijacking a lot. It would be much less attractive to mess around with other people's flows. And I really hope they bring back together Flowise and the Embed Chatbot in the future for Flowise Cloud for an effective proxy implementation you just described. Not a easy task though.

--

In relation to this PR and my last comment, I think it makes sense to have just one deployment to manage multiple embedded chatbots from different flows.

[toi500]

@saatchi-david @HenryHengZJ I've added the multi-flow feature. I managed to do it entirely through.envconfiguration, so all variables are in one place. All of this is built on top of the current implementation, and no changes are needed in the FlowiseAI repository.

This approach is much better. Testing it now.

[HenryHengZJ]

thank you! let me know when its ready to review

[toi500]

@HenryHengZJ I have removed the legacy /proxy sufix (from the original single-flow implementation) and now it is ready to review.

[toi500]

@HenryHengZJ I have made the requested changes. Please review.