* 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 <[email protected]>
182 lines
8.1 KiB
JavaScript
182 lines
8.1 KiB
JavaScript
const bcrypt = require('bcrypt');
|
|
const { initializeDatabase } = require('../../src/database/db');
|
|
const { generateReadablePassword } = require('../../src/utils/passwordGenerator');
|
|
const fs = require('fs').promises;
|
|
const path = require('path');
|
|
|
|
exports.up = async function(knex) {
|
|
console.log('Initializing database schema...');
|
|
|
|
try {
|
|
// Initialize tables
|
|
await initializeDatabase();
|
|
|
|
// Create default admin user if none exists.
|
|
//
|
|
// Legacy path — only when ADMIN_PASSWORD is explicitly provided (keeps
|
|
// existing docker-compose installs working unchanged). When it is NOT set,
|
|
// we deliberately leave admin_users empty so the first-run setup wizard
|
|
// (setupService / /setup) creates the admin in-browser — no ADMIN_PASSWORD
|
|
// in .env. Existing deployments already ran this migration, so this only
|
|
// affects fresh installs.
|
|
const adminExists = await knex('admin_users').first();
|
|
if (!adminExists && process.env.ADMIN_PASSWORD) {
|
|
// Use ADMIN_PASSWORD from environment if set, otherwise generate a random one
|
|
const generatedPassword = process.env.ADMIN_PASSWORD || generateReadablePassword();
|
|
const passwordHash = await bcrypt.hash(generatedPassword, 12); // Increased rounds for better security
|
|
|
|
// Get admin credentials from environment or use defaults
|
|
const adminUsername = process.env.ADMIN_USERNAME || 'admin';
|
|
const adminEmail = process.env.ADMIN_EMAIL || '[email protected]';
|
|
|
|
await knex('admin_users').insert({
|
|
username: adminUsername,
|
|
email: adminEmail,
|
|
password_hash: passwordHash,
|
|
must_change_password: true,
|
|
created_at: new Date()
|
|
});
|
|
|
|
// Try to save credentials to file, but don't fail if we can't
|
|
const dataDir = path.join(__dirname, '..', '..', 'data');
|
|
const setupInfoPath = path.join(dataDir, 'ADMIN_CREDENTIALS.txt');
|
|
|
|
// Detect a pending install-from-backup trigger. If one exists,
|
|
// these credentials are about to be obsoleted by the restore —
|
|
// the backup's admin row replaces this fresh-install one a few
|
|
// seconds from now. We still write the file (in case the
|
|
// restore fails and the fresh admin is the only way in) but
|
|
// annotate the top so admins reading the file after restore
|
|
// don't waste time trying credentials that no longer exist.
|
|
// Flagged on PR #596 review.
|
|
const fsSync = require('fs');
|
|
const backupRoot = process.env.BACKUP_ROOT || '/backup';
|
|
const triggerWillFire = fsSync.existsSync(path.join(backupRoot, 'RESTORE_ON_INSTALL'))
|
|
|| fsSync.existsSync(path.join(backupRoot, 'RESTORE_ON_INSTALL.txt'));
|
|
const restoreNotice = triggerWillFire ? `
|
|
|
|
⚠️ RESTORE_ON_INSTALL TRIGGER DETECTED ⚠️
|
|
These credentials are temporary. An install-from-backup run is queued
|
|
to fire on the next server start, which will REPLACE this admin row
|
|
with the one from the backup. After the restore completes, log in
|
|
with your ORIGINAL pre-disaster credentials — not the ones below.
|
|
If the restore fails for some reason, the credentials below remain
|
|
valid as a fallback recovery path.
|
|
` : '';
|
|
|
|
const setupInfo = `
|
|
========================================
|
|
PicPeak Admin Credentials
|
|
========================================${restoreNotice}
|
|
|
|
Your admin account has been created with these credentials:
|
|
|
|
Email: ${adminEmail}
|
|
Password: ${generatedPassword}
|
|
|
|
IMPORTANT SECURITY NOTES:
|
|
1. Please change this password after first login
|
|
2. This file will be created only once
|
|
3. Store these credentials securely
|
|
4. Delete this file after noting the password
|
|
|
|
Login URL: ${process.env.ADMIN_URL || 'http://localhost:3001'}/admin
|
|
|
|
Login with the email address shown above
|
|
|
|
Generated on: ${new Date().toISOString()}
|
|
========================================
|
|
`;
|
|
|
|
try {
|
|
// Try to create directory and write file
|
|
await fs.mkdir(dataDir, { recursive: true });
|
|
await fs.writeFile(setupInfoPath, setupInfo, 'utf8');
|
|
console.log(`📁 Credentials also saved to: data/ADMIN_CREDENTIALS.txt`);
|
|
} catch (error) {
|
|
// If we can't write the file, that's okay - credentials are shown in console
|
|
console.log('⚠️ Could not save credentials to file (permission denied)');
|
|
console.log(' Please copy the credentials shown above');
|
|
}
|
|
|
|
console.log('\n========================================');
|
|
console.log('✅ Admin user created successfully!');
|
|
console.log('========================================');
|
|
console.log(`Email: ${adminEmail}`);
|
|
console.log(`Password: ${generatedPassword}`);
|
|
console.log('\n⚠️ IMPORTANT:');
|
|
console.log('1. Save these credentials securely');
|
|
console.log('2. Please change the password after first login');
|
|
console.log('========================================\n');
|
|
}
|
|
|
|
// Create default email templates if none exist
|
|
const templateExists = await knex('email_templates').first();
|
|
if (!templateExists) {
|
|
await knex('email_templates').insert([
|
|
{
|
|
template_key: 'gallery_created',
|
|
subject: 'Your Photo Gallery is Ready!',
|
|
body_html: `<h2>Gallery Created Successfully</h2>
|
|
<p>Dear {{host_name}},</p>
|
|
<p>Your photo gallery "{{event_name}}" has been created successfully!</p>
|
|
<p><strong>Gallery Details:</strong></p>
|
|
<ul>
|
|
<li>Event Date: {{event_date}}</li>
|
|
<li>Gallery Link: {{gallery_link}}</li>
|
|
<li>Password: {{gallery_password}}</li>
|
|
<li>Expires: {{expiry_date}}</li>
|
|
</ul>
|
|
<p>Share this link and password with your guests to allow them to view and download photos.</p>`,
|
|
body_text: 'Gallery Created Successfully\n\nDear {{host_name}},\n\nYour photo gallery "{{event_name}}" has been created successfully!',
|
|
variables: JSON.stringify(['host_name', 'event_name', 'event_date', 'gallery_link', 'gallery_password', 'expiry_date'])
|
|
},
|
|
{
|
|
template_key: 'expiration_warning',
|
|
subject: 'Your Photo Gallery Expires Soon',
|
|
body_html: `<h2>Gallery Expiring Soon</h2>
|
|
<p>Dear {{host_name}},</p>
|
|
<p>Your photo gallery "{{event_name}}" will expire in {{days_remaining}} days.</p>
|
|
<p>After expiration, the gallery will be archived and no longer accessible to guests.</p>
|
|
<p><a href="{{gallery_link}}">Visit Gallery</a></p>`,
|
|
body_text: 'Gallery Expiring Soon\n\nDear {{host_name}},\n\nYour photo gallery "{{event_name}}" will expire in {{days_remaining}} days.',
|
|
variables: JSON.stringify(['host_name', 'event_name', 'days_remaining', 'gallery_link'])
|
|
}
|
|
]);
|
|
console.log('Default email templates created');
|
|
}
|
|
|
|
// Seed an email config ONLY when the environment actually supplies a host
|
|
// (#705). This used to fall back to `mailhog`, the dev compose service, so
|
|
// every fresh install came up with a LIVE config pointing at a host that
|
|
// does not exist outside the dev stack — the setup wizard then showed empty
|
|
// SMTP fields (reading as "nothing configured") while mail silently failed.
|
|
// With no row at all, emailProcessor logs "No email configuration found"
|
|
// and the wizard's blank fields are the truth. The dev stack keeps mailhog
|
|
// by setting SMTP_HOST explicitly in docker-compose.yml.
|
|
const emailConfig = await knex('email_configs').first();
|
|
if (!emailConfig && process.env.SMTP_HOST) {
|
|
await knex('email_configs').insert({
|
|
smtp_host: process.env.SMTP_HOST,
|
|
smtp_port: process.env.SMTP_PORT || 1025,
|
|
smtp_secure: process.env.SMTP_SECURE === 'true',
|
|
smtp_user: process.env.SMTP_USER || '',
|
|
smtp_pass: process.env.SMTP_PASS || '',
|
|
from_email: process.env.EMAIL_FROM || '[email protected]',
|
|
from_name: 'Photo Sharing'
|
|
});
|
|
console.log('Default email configuration created');
|
|
}
|
|
|
|
console.log('Migrations completed successfully');
|
|
} catch (error) {
|
|
console.error('Initial setup failed:', error);
|
|
throw error;
|
|
}
|
|
};
|
|
|
|
exports.down = async function(knex) {
|
|
// This migration cannot be rolled back as it creates the initial schema
|
|
console.log('Initial setup cannot be rolled back');
|
|
};
|