fix: serve phpMyAdmin, pgAdmin and Mongo Express behind the dashboard proxy - #20
Open
geodro wants to merge 3 commits into
Open
fix: serve phpMyAdmin, pgAdmin and Mongo Express behind the dashboard proxy#20geodro wants to merge 3 commits into
geodro wants to merge 3 commits into
Conversation
… proxy These three admin UIs set a session cookie the browser refuses to carry into a cross origin iframe, so embedded in the lerd dashboard they render but fail every form they post. phpMyAdmin and pgAdmin worked around it by asking for SameSite=None, which needs Secure, which phpMyAdmin only sets when it believes it is on HTTPS, so the preset forced that too. Chromium blocks the cookie anyway. They now declare dashboard_external, so lerd-ui serves them under its own origin, which puts the cookie back in first party territory and lets both workarounds go. phpMyAdmin gains an Apache alias so it answers under the proxy mount as well as at its root, matching how RabbitMQ declares its path prefix. pgAdmin and Mongo Express take their mount path from lerd at generation time and need nothing here beyond the flag. An older lerd reads all three the same as it did before and opens them in a new tab at their own port, where the cookie was never third party to begin with.
dashboard_external is understood by every released lerd that proxies a dashboard, so publishing it for pgadmin and mongo-express would send those installs to /_svc/<name>/ while nothing had told either app it moved, and the dashboard would answer 404 after nothing more than a store refresh. Both take their mount path from lerd rather than from this file, so they ask with dashboard_proxy, which an older lerd reads as an unknown key and ignores. phpmyadmin keeps dashboard_external. The apache alias it mounts carries its mount path, so any lerd that proxies it reaches it, and this fix takes effect there without waiting for a release.
…inert flag A lerd that does not know dashboard_proxy still frames these from their own origin, so the SameSite=None settings this dropped are what carry their session cookies wherever third party cookies are still allowed. Taking them out only made those installs worse than they are today, since the proxy that replaces them is not something an older binary can do. They cost nothing once a dashboard is served same-origin, so they stay until no supported lerd frames these cross-origin. phpmyadmin asks with dashboard_proxy rather than dashboard_external for the same reason. An older lerd acts on dashboard_external and starts proxying at once, but the apache alias only reaches the container on a restart that regenerates its unit, which that lerd does after it has already restarted, so the dashboard answers 404 in between. Confirmed on a 1.31.0 guest. What reaches an older lerd now is a flag it cannot see and a file mount that only adds a path, so nothing it does changes.
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.
These three admin UIs set a session cookie the browser refuses to carry into a cross origin iframe, so embedded in the lerd dashboard they render but fail every form they post. phpMyAdmin and pgAdmin worked around it by asking for SameSite=None, which needs Secure, which phpMyAdmin only sets when it believes it is on HTTPS, so the preset forced that too. Chromium blocks the cookie anyway.
They now ask to be served under lerd's own origin, which puts the cookie back in first party territory and lets both workarounds go. phpMyAdmin gains an Apache alias so it answers under the proxy mount as well as at its root, matching how RabbitMQ declares its path prefix. pgAdmin and Mongo Express take their mount path from lerd at generation time and need nothing here beyond the flag.
The flag differs by where that mount path comes from, so this stays safe on a lerd that predates the work. phpMyAdmin uses dashboard_external, which every released lerd understands, and since the alias travels in this file any lerd that proxies it reaches it, so the fix takes effect without waiting for a release. pgAdmin and Mongo Express use dashboard_proxy instead, because dashboard_external would send an older lerd to /_svc// while nothing had told either app it moved, and the dashboard would answer 404 after nothing more than a store refresh. An older lerd reads dashboard_proxy as an unknown key and leaves both dashboards exactly as they are today.
Refs lerd-env/lerd#1462