I’m encountering a strange issue where a custom Security Middleware is being bypassed when attached to a workflow, even though it works perfectly when tested individually.
The Setup:
I have a workflow designed to delete a record from a “cars” collection. To ensure security, I added a middleware that checks if the car_id belongs to the currently authenticated user.
Middleware Logic: It takes car_id as a parameter, performs a Select on the database, and uses a True/False split.
True: Proceeds to the Next action.
False: Returns a 401 Unauthorized response.
Workflow: This middleware is attached to the “Security” settings of the Delete workflow.
The Problem:
Testing the Middleware: When I run a test directly inside the Middleware editor with a car_id that does NOT belong to the user, it correctly returns a 401 error.
Live/Workflow Execution: When I trigger the actual Delete workflow (where this middleware is applied), the middleware seems to be completely bypassed. Instead of stopping at the 401 error, the workflow continues to execute the delete action.
Expected vs. Actual: I expect a 401 (or 502 depending on the gateway response), but the record is deleted anyway.
Screenshots:
Image 2: Shows the Middleware configuration inside the Security tab.
Image 1: Shows the logic flow inside the Middleware (True/False split leading to 401).
Has anyone experienced a situation where Middleware doesn’t seem to “fire” or is ignored during the actual workflow run? Am I missing a specific toggle to ensure the workflow waits for the middleware validation?
Middleware bypass confirmed: Send Response (401) ignored even in Dummy Middleware
The Issue: Following up on my previous report. I’ve conducted a more isolated test to rule out logic errors. I created a Dummy Middleware designed to always fail, yet the main workflow still bypasses it and executes fully.
Experimental Setup:
Dummy Middleware: I removed all parameters and database selectors. I used a simple True/False split where both branches lead to a Send Response (401) action.
Workflow Integration: This middleware is active in the Security settings of my workflow (alongside Authenticated check).
Results:
Middleware Editor: Clicking “Test” returns a 401 as expected.
Workflow Execution: When triggering the main workflow, the middleware fails to stop the execution. The workflow ignores the Send Response from the middleware and proceeds to complete all subsequent actions.
It appears that the Send Response action inside a middleware is not being treated as a “termination” signal when the middleware is attached to a workflow.
In that case, the middleware runs first and blocks the request when the condition fails. However, when you test the API call directly from the editor, the middleware attached to the workflow’s Security settings is not triggered.
So the middleware is not being bypassed in the actual frontend execution. The difference is only in how the workflow is being tested.
Could you try triggering your workflow from the interface instead of testing it directly from the editor?
I just reviewed the official WeWeb tutorial on Supabase Integration and Middleware (link to video at 17:05).
In that video, the team explicitly demonstrates testing a Delete API endpoint directly within the editor. When they input an unauthorized ID and click “Test”, the middleware correctly triggers and blocks the request with an error message.
This contradicts the previous response stating that middleware is bypassed in the editor. In my case, even with a “Dummy Middleware” that is hardcoded to return 401, the “Test” button in the workflow editor still allows the entire workflow to proceed to completion.
If the official documentation shows it working in the editor, why is my project bypassing it? This seems like a bug or a regression in how workflows handle the Send Response action from a middleware during testing.
