Fix N3FJP 0,0 location bug and integrate background bridge script

[stearnsy33]

This PR addresses the "Null Island" issue where N3FJP logs were reverting coordinates to 0,0, and officially bundles the N3FJP background bridge script into the repository framework.

Changes Included:

1. Bug Fix (server/routes/wsjtx.js): Patched the cache handling to prevent the grid/coordinate data from resetting to 0,0 on N3FJP logged contacts.
2. Script Integration (scripts/n3fjp-bridge.js): Moved the standalone N3FJP bridge script into the official project directory structure under scripts/.
3. Universal NPM Shortcut (package.json): Added a convenient runner shortcut ("bridge:n3fjp": "node scripts/n3fjp-bridge.js") so users across Windows, Mac, or Linux can seamlessly spin up the bridge using a standard terminal command.

Tested locally on Windows and working beautifully with automated startup macros.

73,
Ben - KC1UEK

[MichaelWheeley]

@stearnsy33 please change target of PR from accius:main to accius:staging

[stearnsy33]

@MichaelWheeley GitHub isn't giving me the option to change the target branch on my end, as far as I can tell. Please feel free to switch the target to staging on your side, or let me know if you'd rather I close this and open a fresh one! Thanks,

[MichaelWheeley]

click on the pencil/edit button as if you were going to edit the title of this PR, then the target becomes available to change

[stearnsy33]

Done! thanks

[accius]

This is a solid fix for the 0,0 placeholder problem and the bridge script is a useful addition. The wsjtx.js cache step is placed correctly, between the bridge-coords trust and the grid lookup, and reusing an active preview line for the logged QSO is the right call. A few notes:

1. The placeholder interception keys off hardcoded lat === 42.4 && lon === -71.7. That is N3FJP's 1st-district default, but it is brittle: a station legitimately at that location would get silently overridden, and if N3FJP ever changes the default the interception goes dead with no signal. Pulling those into a named constant with a comment explaining where the magic numbers come from would make this much easier to maintain.

2. parseAdifCoords(rawStr, isLongitude) never uses isLongitude. Either drop the parameter or use it to bound-check the parsed value (lat to 90, lon to 180).

3. No CI checks have run on this branch. Before merge it is worth confirming format/test pass, since the proxy and stats commits in the branch history net out via the revert and the Staging merges, but it is good to see green rather than assume.

The script is opt-in and runs client-side, so the brittleness in item 1 is not a server risk, just future maintenance pain. Looks good to land once CI is confirmed.

K0CJH

[accius]

Re-reviewed the latest push. The two code notes from last round are both handled: the N3FJP placeholder is now a named constant pair (N3FJP_DEFAULT_LAT / N3FJP_DEFAULT_LON) with a comment, and parseAdifCoords uses isLongitude to bound-check the result. Good.

That said, this revision picked up several issues that block it as-is:

1. The whole dist/ build bundle got committed (around 2.4 MB across the minified js, css, wasm, and image assets). dist/ is in .gitignore, so these had to be force-added. None of it belongs in the PR, it bloats the diff, and it will conflict on the next build. Please drop everything under dist/ from the branch.

2. server/routes/config-routes.js got re-saved in the wrong encoding. The UTF-8 characters in the existing comments are now mojibake (em-dashes show as â€", the check mark as âœ"). That corruption runs through the whole file. The fix is to re-save the file as UTF-8, the cleanest path is to start the config-routes changes from the current Staging version and re-apply only the N3FJP additions.

3. The /api/version endpoint was deleted in this revision. That is a live route: server/health.js probes /api/version for the propagation health check, and the front end polls it for auto-refresh. Removing it breaks both. It needs to stay.

4. Smaller cleanups in the same file: the "N3FJP BRIDGE CONFIGURATION & PROCESS MANAGER" header block is duplicated, and there is a leftover dev note on the } = ctx; line ("Make sure this is exactly a closing brace...") that should come out.

5. Worth a design think before this lands: the route module now fork()s a child process and auto-starts it on boot from config.json. It is gated on n3fjpEnabled === true so it stays dormant on the hosted multi-user instance, which is the right instinct, but spawning and lifecycle-managing a process from inside a route file is a notable change. A short comment on why it lives here, and confirmation that a killed/crashed child does not leave the parent in a bad state, would help the next person.

Also still no CI on the branch. Once dist/ is dropped and the encoding is fixed, please confirm format and tests come back green before this goes up for merge.

The core fix is genuinely good and solves a real problem, it just needs the branch cleaned up.

K0CJH

[accius]

Re-reviewed the Jun 30 / Jul 1 push — thanks for the quick turnaround, Ben. Almost there.

Cleared from last round:

• dist/ bundle removed, config-routes.js encoding fixed (no more mojibake), /api/version restored, duplicate header/dev-note gone.
• The fork() crash-safety I asked about checks out: the parent never .send()s IPC to the child, the reconfigure path does kill()-before-refork inside try/catch, and both fork sites handle 'error' — so a crashed or killed child can't wedge the main server. 👍

One blocker before this can merge — the new endpoint is unauthenticated.

/api/n3fjp/configure is registered with no auth and no rate limiting:

app.post('/api/n3fjp/configure', async (req, res) => {   // server/routes/config-routes.js

whereas the sibling config-mutation route just above it is guarded:

app.post('/api/settings', writeLimiter, requireWriteAuth, (req, res) => {

On the hosted multi-user instance API_WRITE_KEY is set, so requireWriteAuth is exactly what keeps anonymous callers out of config mutations. Because /api/n3fjp/configure skips it, on that deployment any unauthenticated request can:

• make the server fork() scripts/n3fjp-bridge.js with a caller-supplied host/port → an outbound TCP connection to an arbitrary address (SSRF-class + resource use),
• overwrite config.json (n3fjpHost/Port/Enabled) on the shared box,
• churn fork/kill on repeated calls.

Fix is one line — match the sibling route:

app.post('/api/n3fjp/configure', writeLimiter, requireWriteAuth, async (req, res) => {

requireWriteAuth is a pass-through when no API_WRITE_KEY is configured, so this doesn't affect self-hosted/local installs at all.

Non-blocking nit: the forked child has an 'error' handler but no 'exit'/'close'. A crash leaves a stale runningBridgeProcess reference and stops the bridge silently. An .on('exit', () => { runningBridgeProcess = null; }) (plus a log line) would make crashes observable and let a later toggle restart it cleanly. Fine to defer.

Add the middleware and I'll take another look — the core 0,0 fix itself is solid.

73,
K0CJH