Summary
In development mode (-Dlsfusion.server.devmode=true) the platform auto-authenticates the caller as admin — but only for requests that carry no Authorization header. As soon as a request includes an Authorization header, the server runs a real credential check, so a request can fail with HTTP 401 even in dev mode.
This makes dev-mode behavior inconsistent and surprising. Proposed change: in dev mode, ignore the passed authorization entirely and always serve the request as the auto-authenticated admin, regardless of whether (and which) Authorization header is present.
Current behavior
With the server started in dev mode:
curl with no -u → 200 (auto-authenticated as admin).
curl -u admin:<wrong-password> → 401 (server performs a real credential check on the header).
curl -u admin: (empty password) → currently accepted on most builds because it matches the default admin account, but it has been observed returning 401 on at least one snapshot build.
So "no header" ≠ "header with an empty password": the dev-mode auto-auth fires only when the Authorization header is absent. The behavior is the same on the application server's HTTP port (7651) and on the web port.
This is documented in spirit (Launch parameters → dev mode: "Anonymous access to the API and UI is enabled … anonymous access in this mode is as an admin and not an anonymous user"), but the dependency on the presence of the header is an undocumented sharp edge. It repeatedly trips up Action-API / automation callers and HTTP-client libraries that attach Basic auth unconditionally.
Expected / requested behavior
In dev mode the server should not take the passed authorization into account at all — any request is served as the auto-authenticated admin, no matter what Authorization header is sent. No credential combination should produce 401 in dev mode.
Why
- Removes the "no header ≠ empty password" trap.
- Makes dev mode uniform and predictable for the Action API (
/eval, /eval/action, /exec), the File API, and the Form API — many clients send Basic auth by default and currently get a confusing 401.
- Matches the existing stated intent of dev mode ("anonymous access as admin").
Consideration / open question
Today, sending credentials is the only way to exercise the API as a specific (e.g. non-admin) user while in dev mode. If authorization is ignored unconditionally, that capability is lost. Two options:
- Ignore authorization entirely in dev mode — simplest, matches this request.
- Never fail on bad/empty credentials: honor a valid credential if one is supplied, but fall back to the admin auto-auth instead of returning
401 when the header is missing, empty, or invalid.
Flagging for a decision.
Repro
Server started with -Dlsfusion.server.devmode=true:
# no -u → 200
curl -s -o /dev/null -w '%{http_code}\n' -X POST \
-H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' \
--data-urlencode "script=EXPORT FROM r = 'ok';" \
http://localhost:7651/eval/action
# with -u (wrong creds) → 401, even in dev mode
curl -s -o /dev/null -w '%{http_code}\n' -u admin:wrong -X POST \
-H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' \
--data-urlencode "script=EXPORT FROM r = 'ok';" \
http://localhost:7651/eval/action
Summary
In development mode (
-Dlsfusion.server.devmode=true) the platform auto-authenticates the caller asadmin— but only for requests that carry noAuthorizationheader. As soon as a request includes anAuthorizationheader, the server runs a real credential check, so a request can fail withHTTP 401even in dev mode.This makes dev-mode behavior inconsistent and surprising. Proposed change: in dev mode, ignore the passed authorization entirely and always serve the request as the auto-authenticated
admin, regardless of whether (and which)Authorizationheader is present.Current behavior
With the server started in dev mode:
curlwith no-u→200(auto-authenticated asadmin).curl -u admin:<wrong-password>→401(server performs a real credential check on the header).curl -u admin:(empty password) → currently accepted on most builds because it matches the default admin account, but it has been observed returning401on at least one snapshot build.So "no header" ≠ "header with an empty password": the dev-mode auto-auth fires only when the
Authorizationheader is absent. The behavior is the same on the application server's HTTP port (7651) and on the web port.This is documented in spirit (Launch parameters → dev mode: "Anonymous access to the API and UI is enabled … anonymous access in this mode is as an admin and not an anonymous user"), but the dependency on the presence of the header is an undocumented sharp edge. It repeatedly trips up Action-API / automation callers and HTTP-client libraries that attach Basic auth unconditionally.
Expected / requested behavior
In dev mode the server should not take the passed authorization into account at all — any request is served as the auto-authenticated
admin, no matter whatAuthorizationheader is sent. No credential combination should produce401in dev mode.Why
/eval,/eval/action,/exec), the File API, and the Form API — many clients send Basic auth by default and currently get a confusing401.Consideration / open question
Today, sending credentials is the only way to exercise the API as a specific (e.g. non-admin) user while in dev mode. If authorization is ignored unconditionally, that capability is lost. Two options:
401when the header is missing, empty, or invalid.Flagging for a decision.
Repro
Server started with
-Dlsfusion.server.devmode=true: