Repository navigation
fix(my_egeria): serve_my_* page URLs follow the browser's address - #419
Merged
Merged
Conversation
textual-serve builds every asset and WebSocket URL in the page from one fixed public_url. With the egeria-workspaces portal configured for https://laz.local:8843/my-egeria, a browser that reached it as https://localhost:8843 was pointed at another origin; the page's CSP blocked the script and My Profile showed only its title. So one container could only work from one hostname -- not workable for localhost plus a demo site. serve_my_profile / serve_my_egeria now use a Server subclass whose handle_index computes the base URL per request: - behind a proxy (X-Forwarded-Host/-For): host = first *valid* X-Forwarded-Host entry, else Host; scheme = X-Forwarded-Proto, else the configured public URL's; path = the configured public URL's (/my-egeria) - direct connection: the request's own scheme and host (previously textual-serve pointed browsers at 0.0.0.0) Skipping invalid entries matters: egeria-workspaces' Apache sends "X-Forwarded-Host: i=99, localhost:8843" (a misconfigured RequestHeader, reported to that repo). Verified in the live portal container: localhost and laz.local each get same-origin URLs, load the script and render My Profile over the WebSocket. Tests run real textual-serve pages through aiohttp's test server; plain textual-serve fails the localhost case. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
dwolfson
added a commit
that referenced
this pull request
Oct 3, 2026
Release carrying the serve_my_profile / serve_my_egeria fix (#419): page asset and WebSocket URLs follow the browser's address, so one portal container works from localhost, the machine name and a demo hostname. Also picks up the dependency updates merged after 6.1.26 (tornado, pyjwt, urllib3, notebook). Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Makes
serve_my_profile/serve_my_egeriawork from any hostname, so one container serveslocalhost, the machine's name and a demo site alike.The problem: textual-serve builds every asset and WebSocket URL in the page from one fixed
public_url. The egeria-workspaces portal is configured forhttps://laz.local:8843/my-egeria. A browser that reached it ashttps://localhost:8843was sent to another origin; the page's CSP blocked the script, and My Profile showed only its title.The fix: a
textual_serve.Serversubclass whosehandle_indexcomputes the base URL per request.X-Forwarded-HostorX-Forwarded-For):X-Forwarded-Hostentry, elseHost;X-Forwarded-Proto, else the configured public URL's scheme;/my-egeria).0.0.0.0.X-Forwarded-Host: i=99, localhost:8843, from a misconfiguredRequestHeaderline. That's been reported to that repo.Server.handle_indexbuilds its URLs synchronously, so swappingpublic_urlfor the duration of one request can't interleave with another.Docs: the handoff doc, integration doc and My Profile manual now explain that only the path and scheme come from
MY_EGERIA_PUBLIC_URL.Testing
tests/micro-tests/test_my_egeria_serve.py: serves real textual-serve pages through aiohttp's test server and fetches them aslocalhost,laz.local, a demo hostname, IPv6, direct connections, and the exact junk header Apache sends. Plain textual-serve fails thelocalhostcase. The fulltests/micro-testssuite passes.quickstart-my-profilecontainer (with thisserve.py): bothhttps://localhost:8843andhttps://laz.local:8843get same-origin URLs, loadtextual.js, and render My Profile's welcome screen over the WebSocket, with no errors.🤖 Generated with Claude Code