Repository navigation
Answer unknown paths of the tala.run sites with 404 - #43
Conversation
Nginx sent every path that is not a file to index.html with 200, so probes such as /wp-admin/install.php, xmlrpc.php and phpinfo.php were answered as pages: scanners take that for a hit, and search engines index soft 404s. The three server blocks now fall back to @Application, which serves the app shell only for the routes of the application, / and /docs/<page>, and answers every other path with 404. error_page keeps index.html as the body of the 404, so a visitor still reaches the landing page through the router. A test reads the three sitemaps and requires every listed page to match the accepted routes, and scanner paths, /docs and nested paths not to; it also requires the same route rule in all three blocks. OPERATIONS.md describes the expected 404s, and asks for --no-same-owner, chown -R root:root and LF line endings when files are copied from a developer machine: the 2026-10-18 release had left the frontend owned by a Windows user ID. Applied on the server with the owner's approval and verified: nginx -t is clean; /, /docs/overview, talac /docs/command-line, tazel /docs/commands, robots.txt and /api/v1/site answer 200; /wp-admin/install.php, /no-such-page and /docs answer 404. npm test passes, 45 tests.
…test npm audit fix moves the development dependencies vite to 7.3.7 and launch-editor past GHSA-698v-4r3x-3vcv, GHSA-r825-w8mm-5pxw and GHSA-587h-7wmj-h5pm; the frontend audit gate failed on them. Prettier formats tests/site-integrity.test.mjs, which the format check flagged.
Leitwolf11
left a comment
Leitwolf11
left a comment
There was a problem hiding this comment.
Self-review from the diff: ops/nginx/tala.conf sends unknown paths to a named @Application location that serves index.html only for the routes the single-page application owns (/ and /docs/) and answers 404 for everything else, in all three server blocks; this configuration is already live and tested from outside. Documents/OPERATIONS.md records the 404 behaviour and the extraction flags (--no-same-owner, chown, LF). frontend/tests/site-integrity.test.mjs checks that every sitemap page matches the nginx route expression, so the two cannot drift. The lock file update moves the development-only vite and launch-editor past their advisories. Local build, 45 tests and the format check pass; all checks are green.
Nginx sent every path that is not a file to index.html with 200, so
probes such as /wp-admin/install.php, xmlrpc.php and phpinfo.php were
answered as pages: scanners take that for a hit, and search engines
index soft 404s.
The three server blocks now fall back to @Application, which serves
the app shell only for the routes of the application, / and
/docs/, and answers every other path with 404. error_page keeps
index.html as the body of the 404, so a visitor still reaches the
landing page through the router.
A test reads the three sitemaps and requires every listed page to
match the accepted routes, and scanner paths, /docs and nested paths
not to; it also requires the same route rule in all three blocks.
OPERATIONS.md describes the expected 404s, and asks for
--no-same-owner, chown -R root:root and LF line endings when files are
copied from a developer machine: the 2026-10-18 release had left the
frontend owned by a Windows user ID.
Applied on the server with the owner's approval and verified: nginx -t
is clean; /, /docs/overview, talac /docs/command-line, tazel
/docs/commands, robots.txt and /api/v1/site answer 200;
/wp-admin/install.php, /no-such-page and /docs answer 404. npm test
passes, 45 tests.