Эх сурвалжийг харах

docs: correct three defects in the form-trigger plan before execution

fszontagh 1 сар өмнө
parent
commit
8c64c054ae

+ 22 - 14
docs/superpowers/plans/2026-08-09-form-trigger.md

@@ -216,7 +216,6 @@ Do this before anything serves an upload. `CPPHTTPLIB_PAYLOAD_MAX_LENGTH` is `SI
 ```json
 {
   "name": "verify-webhook-body-too-large",
-  "requires": {"note": "expects server.max_upload_mb to be set to 1 for this case"},
   "nodes": [
     {"id": "n1", "name": "Webhook", "type": "post-trigger", "position": {"x": 0, "y": 0}, "config": {}}
   ],
@@ -224,12 +223,17 @@ Do this before anything serves an upload. `CPPHTTPLIB_PAYLOAD_MAX_LENGTH` is `SI
   "http": {
     "method": "POST",
     "path": "/webhook/{workflowId}",
-    "bodyPadBytes": 2097152,
+    "bodyPadBytes": 34000000,
     "expectStatus": 413
   }
 }
 ```
 
+The pad is deliberately larger than the 32 MB default, so the case tests the
+shipped configuration. A smaller pad would only fail while the cap was
+temporarily lowered, and would pass for the wrong reason - by being under the
+limit - in every later suite run.
+
 `bodyPadBytes` does not exist yet. Add it to `run_http_case` in `scripts/verify-node.py`, right after the `data = json.dumps(...)` line:
 
 ```python
@@ -274,20 +278,16 @@ Add to `config/webserver.json` under `server`:
 - [ ] **Step 4: Rebuild, restart, and verify both directions**
 
 ```bash
-cmake --build build -j$(nproc)
-```
-Temporarily set `max_upload_mb` to 1 in `config/webserver.json`, restart, then:
-```bash
-systemctl --user restart smartbotic-webserver && sleep 5
+cmake --build build -j$(nproc) && systemctl --user restart smartbotic-webserver && sleep 5
 python3 scripts/verify-node.py tests/nodes/webhook-body-too-large.json
 ```
-Expected: PASS (413).
+Expected: PASS (413) against the shipped 32 MB default.
 
-Now check the limit does not reject what it should accept - a cap that rejects everything would pass the test above while breaking every webhook:
+Now check the limit does not reject what it should accept - a cap that rejected everything would pass the test above while breaking every webhook:
 ```bash
 python3 scripts/verify-node.py tests/nodes/respond-to-webhook.json
 ```
-Expected: PASS. Then restore `max_upload_mb` to 32 and restart.
+Expected: PASS.
 
 - [ ] **Step 5: Run the whole suite and commit**
 
@@ -1184,11 +1184,19 @@ Now check the gate opens as well as closes - a password that never accepts would
 ```bash
 TOKEN=$(curl -s http://localhost:8090/api/v1/auth/login -H "Content-Type: application/json" \
   -d '{"username": "admin", "password": "admin"}' | jq -r '.accessToken')
-# create a form workflow with password hunter2, publish and activate it, note its id as WF
-curl -s -X POST "http://localhost:8090/api/v1/../webhook/$WF" \
-  --data-urlencode "__form_password=hunter2" -i | head -20
+# Create a form workflow with password hunter2 and a "note" text field, publish
+# and activate it, then put its id in WF.
+curl -s -i -X POST "http://localhost:8090/webhook/$WF" \
+  --data-urlencode "__form_password=hunter2" | head -25
+```
+Expected: a `Set-Cookie: sb_form_...` header and a body containing `name="note"` - the real field, behind the gate.
+
+Then confirm a wrong password does not open it:
+```bash
+curl -s -X POST "http://localhost:8090/webhook/$WF" \
+  --data-urlencode "__form_password=wrong" | grep -c 'name="note"'
 ```
-Expected: a `Set-Cookie: sb_form_...` header and a body containing the real field.
+Expected: `0`.
 
 Also confirm a form with no password still renders directly:
 ```bash