9431b9f094
* feat(setup): configure the public address and SMTP in the wizard, not .env
A fresh install could not configure its own public address. `general_site_url`
and the `email_configs` row already existed as admin settings, but nothing
could reach them:
- docker-compose.yml injected FRONTEND_URL=${FRONTEND_URL:-http://localhost:3000}
and Dockerfile.aio baked in ENV FRONTEND_URL=http://localhost:3000, so
getFrontendBaseUrl() returned on its first branch every time and the setting
was never read. .env.example shipped the same value as an uncommented
placeholder for FRONTEND_URL / ADMIN_URL / API_URL.
- the wizard never asked for the address at all, and skipped its whole config
step unless a CRM-ish feature was selected — so a gallery-only install was
also never offered SMTP, despite gallery links, guest invites and expiry
warnings all going out through email_configs.
- eleven call sites read process.env.FRONTEND_URL directly rather than the
resolver, three of them defaulting to placeholder hosts that reached real
recipients: https://app.example.com in payment-reminder emails, localhost:3005
in admin invitation emails, https://app.example.com in dev template previews.
Stop injecting a default anywhere, and resolve the origin instead:
FRONTEND_URL -> general_site_url -> the origin the request arrived on ->
whichever exists -> ''. A loopback candidate is treated as unconfigured so the
installs that already have http://localhost:3000 baked into their environment
self-heal; the same guard previously lived inline in routes/gallery.js for the
slideshow QR (#848) and is now shared. The empty return is preserved because
shareLinkService and the SSO redirects in routes/auth rely on it to emit
relative urls — callers needing an absolute url use getAbsoluteFrontendUrl(),
which still ends at http://localhost:3000.
The wizard now persists window.location.origin right after the admin account is
created, so an install that skips the rest still has a usable origin for
background jobs that have no request to derive one from, and offers it as an
editable "Public address" field. Settings -> General shows the field read-only
when FRONTEND_URL pins it, instead of silently ignoring edits.
Also drop the `|| 'mailhog'` fallback when seeding email_configs: that host only
exists in the dev compose profile (which does not even start by default), so a
fresh install came up with a live config pointing nowhere while the wizard
showed empty SMTP fields. With no row, blank fields are the truth and
emailProcessor logs "No email configuration found". Developers set
SMTP_HOST=mailhog explicitly.
backend/src/services/emailService.js is deleted: nothing in backend/ references
it, and it was the only consumer of the SMTP_* variables, which misrepresented
how mail is configured.
Refs #705
* fix(setup): keep FRONTEND_URL ahead of ADMIN_URL/APP_URL when resolving links
The previous commit routed two call sites through the resolver but put the
site-specific variable FIRST, silently reversing precedence:
userManagementService was: FRONTEND_URL || ADMIN_URL || localhost:3005
became: ADMIN_URL || resolver
adminEvents/crud was: FRONTEND_URL || APP_URL || ''
became: APP_URL || resolver
An install with both variables set would have flipped which one won. Call the
resolver first instead — it starts with FRONTEND_URL, so the original relative
order is preserved and only the final fallback changes: localhost:3005 (not
even the frontend's port) and '' (a relative link inside an email) both become
the resolved origin.
Refs #705
* fix(setup): unpin loopback FRONTEND_URL, keep ADMIN_URL/APP_URL reachable
Review feedback on #1104.
isEnvPinned() reported ANY FRONTEND_URL as authoritative, including the
loopback values getFrontendBaseUrl() deliberately demotes. An install
upgrading with the old compose default FRONTEND_URL=http://localhost:3000
therefore resolved its origin from general_site_url correctly, but got the
Site URL field rendered read-only in Settings and skipped by the wizard's
seeding - locking the exact operators this change exists to unblock out of
configuring a public address anywhere. The predicate now mirrors the
resolver, and the derived general_site_url_effective the General tab reads
comes from the same helper instead of re-normalising process.env inline.
APP_URL and ADMIN_URL had become dead code: getFrontendBaseUrl() only
returns falsy when NOTHING is configured, so `|| process.env.ADMIN_URL`
after it never ran once a site URL existed - which after this PR is the
normal case. A split-origin install pointing ADMIN_URL at a separate admin
host got invite links on the public gallery origin instead. They are now
passed as an explicit `override` that resolves directly below FRONTEND_URL,
preserving the historic FRONTEND_URL-before-ADMIN_URL order while beating
the database- and request-derived fallbacks.
general_site_url now feeds the CORS allowlist and the
Access-Control-Allow-Origin header, not just email links, so a schemeless
value is an allowlist entry no browser origin can match. Validate it
server-side in PUT /general (isURL with require_protocol, require_tld off
so LAN/NAS installs on http://nas:3000 still work) and client-side in both
surfaces that write it - type="url" never fires in either, since neither
input sits inside a form.
Two more wizard fixes: the General tab no longer reposts general_site_url
while it is env-pinned, because the field then holds the effective env
value rather than the stored one and the round-trip read as a change to a
protected key, 403ing a settings.edit-without-settings.domains admin on an
unrelated save. And SetupConfigStep validates the From address before
posting - /admin/email/config rejects a blank one, which used to surface as
a generic warning while the wizard advanced from its finally block anyway,
discarding every SMTP value the user had typed, password included. A failed
save now keeps them on the step.
* fix(setup): surface a rejected public address instead of swallowing it
Review round 2 follow-up on #1104, pushed onto the branch.
saveSiteUrl() caught and discarded every error. That was defensible before
round 2 added a server-side URL check, but PUT /general can now answer 400 —
and the two validators disagreed:
http://my_nas.local client: accepted server: rejected
http://foo_bar:3000 client: accepted server: rejected
validate() let those through, the 400 was swallowed, `failed` stayed false and
onDone() ran. The operator finished the wizard believing the public address was
stored when nothing had been. That is the silent misconfiguration this whole
change exists to remove, landing on the LAN and NAS installs it targets.
Three parts:
- saveSiteUrl() throws. finish() resolves it before anything else is posted and
puts the message on the address field rather than the generic "some settings
could not be saved" warning. Skip for now still always leaves, by contract,
but warns instead of dropping the value in silence.
- allow_underscores on the server check, for the same reason require_tld is
off: browsers resolve http://my_nas.local and the client accepts it, so
rejecting it server-side only produced the mismatch above. Both validators
now agree across the LAN/NAS, IDN, bare-IP and scheme-less cases.
- LOOPBACK_BASE_RE anchors its host token. Bare prefix matching also demoted
https://localhost-nas.example.com, and now that this predicate gates the
whole resolver rather than just the slideshow QR, being demoted means a
configured address is silently ignored. 127. stays a bare prefix on purpose:
all of 127.0.0.0/8 is loopback.
Resolver suite 31 passing, up from 26. Mutation-checked: restoring the
unanchored regex fails the three new host-boundary cases.
* fix(settings): don't lock the General tab on a site URL nobody typed
Review follow-up on #1104, pushed onto the branch.
general_site_url was free-text until this PR added a server-side check, so an
upgraded install can hold something schemeless that predates it. The tab
flagged that on load, and `disabled={!!siteUrlError}` then killed Save for
EVERY General setting.
An admin holding settings.edit but not settings.domains could not clear it
either: correcting the address is a change to a protected key and 403s. The
tab has no permission gating, so that role was simply locked out of the tab
with no self-service way back.
That is the same role adminSettings.js:85-95 documents the no-op round-trip
allowance for. The allowance only helps if the request is made, and this
blocked it in the browser first.
Validation now waits until the field is actually edited, and an unchanged
value is dropped from the payload rather than reposted — matching what the
env-pinned case already does one line above, and for the same reason.
stored value invalid, untouched Save works, key not sent
edited to something unusable Save blocked
edited to a usable absolute url saved
Four tests, first coverage for this feature. Mutation-checked: removing the
dirty gate fails the untouched-value case.
---------
Co-authored-by: Paul Nothaft <53005142+the-luap@users.noreply.github.com>
191 lines
8.0 KiB
JavaScript
191 lines
8.0 KiB
JavaScript
const { db } = require('../database/db');
|
|
|
|
// Terminal fallback for callers that need an ABSOLUTE url (emails, QR codes,
|
|
// payment links). Deliberately not the fallback of getFrontendBaseUrl(): some
|
|
// callers (shareLinkService, the SSO redirects in routes/auth) rely on an
|
|
// empty base to emit a RELATIVE url, which is the better answer for a
|
|
// same-origin redirect.
|
|
const DEFAULT_ABSOLUTE_BASE = 'http://localhost:3000';
|
|
|
|
// A loopback base is treated as "not configured" so a better answer can win.
|
|
// Rationale (#705): docker-compose used to inject
|
|
// FRONTEND_URL=http://localhost:3000 unconditionally, so millions of installs
|
|
// have it baked into their environment; taking it literally means gallery
|
|
// links, QR codes and reminder emails point every recipient at THEIR OWN
|
|
// machine. The same guard already existed locally in routes/gallery.js for
|
|
// the slideshow QR (#848) and is centralised here.
|
|
//
|
|
// The host token has to end at a real boundary. Bare prefix matching (which is
|
|
// what routes/gallery.js did while this only gated the QR) also demotes
|
|
// https://localhost-nas.example.com — a legitimate public host, and now that
|
|
// this predicate decides "is this configured" for the entire resolver, being
|
|
// demoted means the operator's configured address is silently ignored.
|
|
// 127. stays a bare prefix on purpose: all of 127.0.0.0/8 is loopback.
|
|
const LOOPBACK_BASE_RE = /^https?:\/\/(localhost(?=[:/?#]|$)|127\.|0\.0\.0\.0(?=[:/?#]|$)|\[::1\])/i;
|
|
|
|
const isLoopbackBase = (url) => !!url && LOOPBACK_BASE_RE.test(url);
|
|
|
|
const normalise = (val) => (typeof val === 'string' ? val.trim().replace(/\/+$/, '') : '');
|
|
|
|
// Cached copy of the `general_site_url` setting. Two reasons: this now sits in
|
|
// per-request paths (CORS headers), and the sync accessor below has no other
|
|
// way to see the database. Invalidated explicitly when settings are written;
|
|
// the TTL is the backstop for writes that bypass that path (a restore, a
|
|
// direct SQL edit), so the documented worst case is CACHE_MS of staleness.
|
|
const CACHE_MS = 30_000;
|
|
let cache = { value: '', at: 0, primed: false };
|
|
|
|
const readSettingFromDb = async () => {
|
|
try {
|
|
const setting = await db('app_settings')
|
|
.where('setting_key', 'general_site_url')
|
|
.select('setting_value')
|
|
.first();
|
|
|
|
if (!setting || !setting.setting_value) return '';
|
|
let val = setting.setting_value;
|
|
if (typeof val === 'string') {
|
|
try { val = JSON.parse(val); } catch (_) { /* stored as a bare string */ }
|
|
}
|
|
return normalise(typeof val === 'string' ? val : '');
|
|
} catch (_) {
|
|
return '';
|
|
}
|
|
};
|
|
|
|
const getSiteUrlSetting = async () => {
|
|
const now = Date.now();
|
|
if (cache.primed && now - cache.at < CACHE_MS) return cache.value;
|
|
const value = await readSettingFromDb();
|
|
cache = { value, at: now, primed: true };
|
|
return value;
|
|
};
|
|
|
|
// Expire the entry WITHOUT blanking it, then refresh in the background.
|
|
// Blanking would leave the synchronous accessor (the CORS allowlists) with no
|
|
// value at all until some async caller happened to re-read, which for
|
|
// Access-Control-Allow-Origin means falling back to '*' - a wider header than
|
|
// the operator configured. A briefly-stale origin is the safer trade.
|
|
const invalidateSiteUrlCache = () => {
|
|
cache = { ...cache, at: 0 };
|
|
primeSiteUrlCache().catch(() => {});
|
|
};
|
|
|
|
// The origin the request itself arrived on. `trust proxy` is configured in
|
|
// server.js, so req.protocol honours X-Forwarded-Proto behind the standard
|
|
// reverse proxies. Note frontend/nginx.conf forwards $host with the port
|
|
// stripped, so this can lose a non-default port on the split stack — which is
|
|
// why the setup wizard persists the browser's own window.location.origin
|
|
// instead of relying on this. It stays a last resort, and it is unavailable
|
|
// entirely to background jobs (reminder emails) that have no request.
|
|
const originFromRequest = (req) => {
|
|
if (!req || typeof req.get !== 'function') return '';
|
|
const host = req.get('host');
|
|
if (!host) return '';
|
|
const proto = req.protocol || 'http';
|
|
return normalise(`${proto}://${host}`);
|
|
};
|
|
|
|
const envBase = () => normalise(process.env.FRONTEND_URL);
|
|
|
|
// The env value ONLY when it actually wins the resolution below — i.e. set and
|
|
// not loopback. A loopback FRONTEND_URL is demoted by getFrontendBaseUrl(), so
|
|
// reporting it as authoritative would lock the admin UI's Site URL field for
|
|
// exactly the operators this exists to unblock: an upgrade that still carries
|
|
// the old compose default FRONTEND_URL=http://localhost:3000 must be able to
|
|
// configure its public address through the wizard and Settings (#1104).
|
|
const envPinnedBase = () => {
|
|
const env = envBase();
|
|
return env && !isLoopbackBase(env) ? env : '';
|
|
};
|
|
|
|
// Is the public origin pinned by the environment? The admin UI uses this to
|
|
// show the Site URL field as read-only, so an operator never edits a setting
|
|
// that an env var is silently overriding. Mirrors the resolver exactly.
|
|
const isEnvPinned = () => !!envPinnedBase();
|
|
|
|
/**
|
|
* Resolve the public origin, best answer first:
|
|
* 1. FRONTEND_URL, when it is not loopback
|
|
* 2. `options.override` - a purpose-specific env var (ADMIN_URL, APP_URL)
|
|
* the caller passes in, when it is not loopback
|
|
* 3. the `general_site_url` setting, when it is not loopback
|
|
* 4. the origin this request arrived on, when it is not loopback
|
|
* 5. whichever of the above exists at all (covers a genuine localhost install)
|
|
* 6. '' - caller decides between a relative url and DEFAULT_ABSOLUTE_BASE
|
|
*
|
|
* (2) exists because split-origin deployments are supported (API_URL, #798):
|
|
* an operator who sets ADMIN_URL for a separate admin host has stated an
|
|
* explicit per-purpose intent, and that must beat a value derived from the
|
|
* database or from whichever request happened to trigger the email (#1104).
|
|
* It sits BELOW FRONTEND_URL to preserve the historic
|
|
* `FRONTEND_URL || ADMIN_URL` order those call sites used.
|
|
*/
|
|
const getFrontendBaseUrl = async (req, options = {}) => {
|
|
// Short-circuit before touching the database: a pinned, non-loopback
|
|
// FRONTEND_URL is the answer, and this runs in per-request paths.
|
|
const env = envBase();
|
|
if (env && !isLoopbackBase(env)) return env;
|
|
|
|
const override = normalise(options.override);
|
|
if (override && !isLoopbackBase(override)) return override;
|
|
|
|
const setting = await getSiteUrlSetting();
|
|
if (setting && !isLoopbackBase(setting)) return setting;
|
|
|
|
const request = originFromRequest(req);
|
|
if (request && !isLoopbackBase(request)) return request;
|
|
|
|
return env || override || setting || request || '';
|
|
};
|
|
|
|
/** Same precedence, for callers that must produce an absolute url. */
|
|
const getAbsoluteFrontendUrl = async (req, options = {}) =>
|
|
(await getFrontendBaseUrl(req, options)) || DEFAULT_ABSOLUTE_BASE;
|
|
|
|
/**
|
|
* Synchronous variant for call sites that cannot await (Express middleware
|
|
* setting a response header). Sees the environment and the last cached
|
|
* setting only - it never reaches the database - so prime the cache at boot
|
|
* via primeSiteUrlCache().
|
|
*/
|
|
const getFrontendBaseUrlSync = (req) => {
|
|
const env = envBase();
|
|
const setting = cache.primed ? cache.value : '';
|
|
const request = originFromRequest(req);
|
|
|
|
for (const candidate of [env, setting, request]) {
|
|
if (candidate && !isLoopbackBase(candidate)) return candidate;
|
|
}
|
|
return env || setting || request || '';
|
|
};
|
|
|
|
const primeSiteUrlCache = async () => {
|
|
cache = { value: await readSettingFromDb(), at: Date.now(), primed: true };
|
|
return cache.value;
|
|
};
|
|
|
|
/**
|
|
* Public API origin used for assets that email clients must load. Explicit
|
|
* API_URL wins (split-origin deployments); otherwise it is the resolved
|
|
* public origin + /api, so the wizard's single answer covers it.
|
|
*/
|
|
const getApiBaseUrl = async (req) => {
|
|
const explicit = normalise(process.env.API_URL);
|
|
if (explicit) return explicit;
|
|
return `${await getAbsoluteFrontendUrl(req)}/api`;
|
|
};
|
|
|
|
module.exports = {
|
|
getFrontendBaseUrl,
|
|
getAbsoluteFrontendUrl,
|
|
getFrontendBaseUrlSync,
|
|
getApiBaseUrl,
|
|
invalidateSiteUrlCache,
|
|
primeSiteUrlCache,
|
|
isLoopbackBase,
|
|
isEnvPinned,
|
|
envPinnedBase,
|
|
DEFAULT_ABSOLUTE_BASE,
|
|
};
|