Local PFS locks legitimate callers out of `/listsecrets` and `/Telemetries/` after auth fix in #4090

[YizukiAme]

Bug Description

The March 13 auth hardening in PR #4090 changed local_user_only() to trust only request.environ["REMOTE_USER"], but the local PFS startup path still launches plain Waitress (waitress.serve(...)) without any middleware that injects REMOTE_USER for local requests.

Under normal WSGI rules, client-supplied headers are exposed as HTTP_* keys, not REMOTE_USER, so local callers never satisfy the guard. The two endpoints still protected by @local_user_only — /v1.0/Connections/<name>/listsecrets and /v1.0/Telemetries/ — now return 403 even for the same desktop user who started PFS.

This is not an intentional breaking change — there is no corresponding documentation update, CHANGELOG entry, or migration path. The in-tree tests still send X-Remote-User (which no longer maps to REMOTE_USER), confirming the regression is unintentional.

Root Cause

src/promptflow-devkit/promptflow/_sdk/_service/utils/utils.py L60-66:

user = request.environ.get("REMOTE_USER")
if user != getpass.getuser():
    abort(403)

src/promptflow-devkit/promptflow/_cli/_pf/_service.py:

waitress.serve(app, host=service_host, port=port, threads=PF_SERVICE_WORKER_NUM)
# No middleware to inject REMOTE_USER for local requests

Evidence

1. Gate reads REMOTE_USER — utils.py L60
2. No injection path — waitress.serve() is called without any auth middleware
3. Tests still use old contract — tests/sdk_pfs_test/utils.py L66, L129, L231 and test_telemetry_apis.py L15 still send X-Remote-User
4. Historical context confirms this was the API contract:
   • PR [pfs] Hide x-remote-user in promptflow service #1191 only hid X-Remote-User from Swagger docs, did not remove runtime support
   • PR feat: add private api to record telemetry directly #1750 (Jan 2024) added telemetry API using the same X-Remote-User pattern
5. No follow-up — No subsequent PR/issue addresses the broken local auth path
6. #4092 is unrelated — that's a listing/spam issue, not this regression

Steps to Reproduce

1. Start local PFS: pf service start
2. Try to list secrets: GET /v1.0/Connections/my-conn/listsecrets
3. Response: 403 Forbidden (even though you are the local user who started PFS)
4. Same for POST /v1.0/Telemetries/

Expected Behavior

The security fix in #4090 should have simultaneously provided a new trusted identity mechanism for local PFS callers. Local requests from the user who started PFS should still be authorized.

Suggested Fix

Keep the anti-spoofing fix from #4090, but also add a trusted local auth mechanism that actually populates REMOTE_USER in the PFS hosting stack — for example, a WSGI middleware that sets REMOTE_USER to getpass.getuser() for connections originating from 127.0.0.1/::1. Update the test helpers and swagger text to reflect the real contract.

[rehan243]

So you're hitting the 403 on /listsecrets and /Telemetries/ after that auth fix in #4090? We're using Waitress too, and I recall we had to add a custom middleware to inject REMOTE_USER for local requests. Turns out, Waitress doesn't automatically set it, which is what's causing the issue here. The local_user_only() check is now failing because REMOTE_USER isn't being populated. We ended up creating a simple wrapper that sets REMOTE_USER to the current user if the request is coming from localhost. Are you running the latest version of Promptflow, btw?

[YizukiAme]

Yeah, this was against the latest main at the time of filing. I just rebased the PR (#4131) and there are no conflicts, so the regression is still present.
btw, the fix in the PR is essentially what you described: a small WSGI middleware that sets REMOTE_USER for loopback connections. Hopefully it gets reviewed and merged soon so others don't have to work around it independently.🙃

[rehan243]

Ah, got it — yeah, I saw the rebase, and it’s good there’s no conflicts. That middleware fix is basically what we rolled out internally too. The thing is, if you're on the latest main, that fix should be in — maybe the review just hasn't merged yet? Or maybe there's a mismatch in local cache? Lmk if you want me to ping anyone about the status.

[github-actions]

Hi, we're sending this friendly reminder because we haven't heard back from you in 30 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 7 days of this comment, the issue will be automatically closed. Thank you!

[YizukiAme]

Hi, we're sending this friendly reminder because we haven't heard back from you in 30 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 7 days of this comment, the issue will be automatically closed. Thank you!

🤔