[Feature Request] Allow setting BFL API endpoint and key directly in the workflow

[Duanyll]

Motivation:

This feature proposal aims to provide more flexibility for users who run ComfyUI in various environments, especially on cloud platforms where they might not have direct access to modify configuration files.

1. Cloud Environment Constraints: Some users operate ComfyUI in environments provided by cloud vendors. In such scenarios, they often lack the permissions to modify the node's configuration files directly. Their primary method of interaction is by submitting workflows with all necessary parameters embedded.
2. Support for Alternative Endpoints: Users may need to connect to non-official or third-party FLUX API endpoints. The current implementation, which relies on a single, statically configured endpoint, makes this difficult.

Allowing the API endpoint and credentials to be set within the workflow itself would solve these issues and make the nodes more versatile.

Proposed Implementation:

I suggest the following changes to enable this functionality while maintaining backward compatibility:

1. New CreateBFLConfig Node:

   • Introduce a new node, CreateBFLConfig, which would have two input fields: base_url and x_key.
   • This node would output a ConfigLoader object containing this information.

2. Modify API Call Nodes:

   • Update all existing API call nodes to include an optional config input.
   • If this config input is connected, the node will use the ConfigLoader object to retrieve the API endpoint and key.
   • If the input is not connected, the node will fall back to the original method of reading from the config.ini file, ensuring backward compatibility.

3. Refactor Authentication Header Logic:

   • Refactor the code that reads the API key. Instead of reading the X_KEY directly from environment variables or a config file, it should be accessed via a new make_headers() method within the ConfigLoader object.
   • This make_headers() method should add both the X-KEY header (for official BFL compatibility) and an Authorization: Bearer <key> header to support a wider range of third-party FLUX API providers.

Potential Risks:

It is important to acknowledge that embedding API keys directly into workflow files could lead to accidental exposure if the image metadata (which often includes the workflow) is shared publicly. However, it can be assumed that users who choose this method are aware of the inherent security risks and will handle their workflows and generated images appropriately. A note in the node's documentation could also serve as a helpful warning.

Next Steps:

I have already implemented these features in my personal fork: Duanyll/ComfyUI-FLUX-BFL-API.

I am happy to open a pull request to contribute this functionality to the main repository. Please let me know if this proposal is aligned with the project's direction.

Thank you for your consideration!

[gelasdev]

Thank you, @Duanyll.

Thank you for taking the time to outline this proposal in such detail — I really appreciate the clear motivation and backward-compatible design.

I’ve just implemented the requested functionality on my side, although I haven’t been able to run a full test yet. If you have any feedback or further suggestions, I’d be happy to hear them.

Best regards,