fix(nginx): route /plugin-sdk/ and /index.css to the backend - #155
Merged
Conversation
The plugin SDK is served by Fastify at /plugin-sdk/v1.js and the theme
stylesheet at /index.css, but nginx had no location for either. Both were
captured by the static-asset regex and returned 404, so in any container
deployment a plugin iframe could not load the SDK or the theme variables.
Plugin iframes are same-origin with the frontend: PluginWidgetWrapper sets
src to `${API_BASE_URL}/widgets/<file>`, and VITE_REACT_APP_API_URL has no
default and is not set by docker-compose.yml, so API_BASE_URL compiles to ''.
Native dev points it at the backend, which is why this only affects
containers.
Plugins that load the SDK guard on `window.HomeGlow` and silently fall back
to browser-local behaviour, so the failure surfaced as features quietly not
working rather than as an error.
`^~` and `=` are required rather than stylistic: nginx matches regex
locations before prefix locations, so a plain prefix location would still
lose to the static-asset regex and 404 as before.
Verified through nginx: /plugin-sdk/v1.js 200 application/javascript,
/index.css 200 text/css, with /api/, /uploads/, /widgets/, hashed assets
and the SPA fallback unchanged.
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
2 participants
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.
Fixes #154.
nginx has no
locationfor/plugin-sdk/or/index.css, so both are captured by the static-asset regex and returned as 404. In any deployment where nginx serves the frontend, a plugin iframe cannot load the SDK or the theme variables.Two location blocks, placed before the static-asset regex:
location ^~ /plugin-sdk/— proxied to the backend, which already serves/plugin-sdk/v1.js.location = /index.css— proxied to the backend, which already serves it.^~and=are load-bearing rather than stylistic. nginx matches regex locations before prefix locations, so a plainlocation /plugin-sdk/would still lose to the.js|.cssstatic-asset regex and 404 exactly as before.= /index.csswins as an exact match without shadowing the hashed stylesheets under/assets/. Both carry the same proxy headers as the existing/widgets/block.No behaviour changes outside those two paths.
Verified
On a container deployment before and after, through nginx:
/plugin-sdk/v1.jsapplication/javascript/index.csstext/cssThe served SDK is byte-identical to
server/plugin-sdk/v1.jsat this commit (sha256 comparison, not a status code).Unchanged after the patch:
/api/,/uploads/,/Uploads/,/widgets/,= /index.html, the SPA fallback, and hashed assets under/assets/(stillCache-Control: max-age=31536000, public, immutable).End to end, a plugin declaring
apiVersion: "v1"now reacheswindow.HomeGlow.pluginId, stores server-side (confirmed across two browsers), and picks up the theme variables from/index.css.nginx -tpasses.Note for anyone deploying this
Plugins already installed that load the SDK have been silently falling back to browser-local storage, because they guard on
window.HomeGlow. Once the SDK loads they read server-side settings, which will be empty where a display currently shows local data — so expect a one-time reset of those plugins' settings rather than a migration of them.I have not included any migration code or docs for that stranded localStorage data. Happy to follow up with it in a separate PR (or to add it here) if you would like it — it would have to live in each affected plugin, since only code running in that browser can read its
localStorage.