Observed with the Reader Chrome extension and local connector beta.110, using SDK beta.108.
The extension uses portable/device-code authorization. Relay reads work. After explicit optional host permission for http://127.0.0.1/* and requestDirectAccess(), readiness/operations receive HTTP 403 and the application session can become blocked with "The collection authority returned a response that is not valid JSON."
Confirmed read-only: GET /v1/ready with an Origin: chrome-extension:// header returns 403. crates/connect-agent/src/loopback.rs authorize_browser_request explicitly accepts only http/https schemes (plus separately handled null), so an exact extension origin is rejected before the registered-grant origin check. Grant origin semantics must also be checked end-to-end for portable extensions.
Expected: support exact registered extension origins through normal signed-grant authorization, without spoofing Origin, allowing arbitrary origins, or weakening local authorization. A failed direct probe must preserve relay availability and report a useful typed error rather than an empty-response JSON error.
Please cover readiness, encrypted operations, files, exact origin mismatch/rejection, and relay fallback after failed opt-in. Reader now uses explicit browser permission controls and disables direct preference/recreates its session after a failed opt-in; that does not make direct access work with the current daemon.
Observed with the Reader Chrome extension and local connector beta.110, using SDK beta.108.
The extension uses portable/device-code authorization. Relay reads work. After explicit optional host permission for http://127.0.0.1/* and requestDirectAccess(), readiness/operations receive HTTP 403 and the application session can become blocked with "The collection authority returned a response that is not valid JSON."
Confirmed read-only: GET /v1/ready with an Origin: chrome-extension:// header returns 403. crates/connect-agent/src/loopback.rs authorize_browser_request explicitly accepts only http/https schemes (plus separately handled null), so an exact extension origin is rejected before the registered-grant origin check. Grant origin semantics must also be checked end-to-end for portable extensions.
Expected: support exact registered extension origins through normal signed-grant authorization, without spoofing Origin, allowing arbitrary origins, or weakening local authorization. A failed direct probe must preserve relay availability and report a useful typed error rather than an empty-response JSON error.
Please cover readiness, encrypted operations, files, exact origin mismatch/rejection, and relay fallback after failed opt-in. Reader now uses explicit browser permission controls and disables direct preference/recreates its session after a failed opt-in; that does not make direct access work with the current daemon.