ChromeCard Proxy Portal
++ Primary browser entry point for the current prototype. Browser traffic now targets k_proxy directly. + Enrollment, login, session reuse, counter access, and logout all happen on this TLS endpoint. +
+diff --git a/Setup.md b/Setup.md index 187fe40..1dea768 100644 --- a/Setup.md +++ b/Setup.md @@ -345,6 +345,20 @@ Session note (2026-04-25, Phase 6 enrollment contract): - Phase 6 now has a real `k_client -> k_proxy` enrollment request path - the remaining gap is not basic routing; it is deciding the final enrollment semantics and whether the browser should stay behind a local portal or talk to `k_proxy` directly +Session note (2026-04-25, browser target moved to k_proxy): +- `k_proxy` now serves the browser-facing portal UI directly on `/` over `https://127.0.0.1:9771`. +- `k_client_portal.py` is now a temporary bridge page: + - it points users to `https://127.0.0.1:9771/` + - it is no longer the primary browser target +- Verified direct browser/API target behavior from `k_client`: + - `GET https://127.0.0.1:9771/` returns the proxy portal HTML + - `GET https://127.0.0.1:9771/health` returns `ok=true` + - direct `POST /enroll/register` for `carol` succeeds + - direct `POST /session/login` for `carol` succeeds +- Current implication: + - browser traffic is now intended to go straight to `k_proxy` + - the `k_client` portal remains only as a temporary bridge/compatibility layer + Session note (2026-04-25, in-VM forwarding test): - Tested the intended in-VM forwarding path with `qvm-connect-tcp` instead of host-side `qrexec-client-vm`. - Forwarders start and bind locally: diff --git a/Workplan.md b/Workplan.md index f28638b..11fb3a3 100644 --- a/Workplan.md +++ b/Workplan.md @@ -265,9 +265,8 @@ Exit criteria: Status (2026-04-25): - Added first `k_client` implementation at `/home/user/chromecard/k_client_portal.py`. - Current prototype flow: - - browser talks to local portal on `k_client` - - portal stores only a preferred username locally - - portal calls `k_proxy` over `https://127.0.0.1:9771` + - browser now targets `k_proxy` directly over `https://127.0.0.1:9771` + - `k_client_portal.py` remains only as a temporary bridge page - `k_proxy` continues to authenticate with the card and forward to `k_server` - Verified end-to-end through the portal: - enroll `alice` @@ -278,12 +277,13 @@ Status (2026-04-25): - Enrollment contract progress: - `k_proxy` now exposes prototype enrollment endpoints - proxy-side enrollment storage exists and is checked before login is allowed - - `k_client` portal enrollment now routes to `k_proxy` over TLS instead of remaining client-local only + - direct browser/API traffic can now use those proxy endpoints without going through the local bridge - Phase 6 is materially further along for the current prototype shape: - - client-side process exists - - login/resource flow is integrated + - direct browser target is on `k_proxy` + - login/resource flow is integrated on the direct proxy path - enrollment now has a real client->proxy path - - final enrollment semantics and UI shape are still provisional + - the `k_client` bridge remains only for transition/compatibility + - final enrollment semantics are still provisional ## Phase 6.5: Concurrency and Multi-Client Test Setup diff --git a/k_client_portal.py b/k_client_portal.py index f50d420..1622eaa 100644 --- a/k_client_portal.py +++ b/k_client_portal.py @@ -27,35 +27,34 @@ HTML = """
-+ Primary browser entry point for the current prototype. Browser traffic now targets k_proxy directly. + Enrollment, login, session reuse, counter access, and logout all happen on this TLS endpoint. +
+