Skip to content

fix: serve phpMyAdmin, pgAdmin and Mongo Express behind the dashboard proxy - #20

Open
geodro wants to merge 3 commits into
mainfrom
fix/admin-dashboards-same-origin
Open

fix: serve phpMyAdmin, pgAdmin and Mongo Express behind the dashboard proxy#20
geodro wants to merge 3 commits into
mainfrom
fix/admin-dashboards-same-origin

Conversation

@geodro

@geodro geodro commented Aug 11, 2026

Copy link
Copy Markdown
Member

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

… 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.
@geodro
geodro requested a review from a team as a code owner August 11, 2026 10:15
geodro added 2 commits August 11, 2026 13:31
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant