[LSWF] Remote Access Control: block remote access by SKU whitelist

[AustinChangLinksys]

Background

The LSWF app (release-3.6.1, Cordova-based hybrid app) needs to block remote access for router models that are not on a cloud whitelist, as part of the cloud service sunset. Filed in response to the DevOps/Jimmy change request.

The code lives in the internal git.lswf.net symmetry-mobile repo (Bitbucket, so it can't be linked as GitHub PRs). Branch: release-3.6.1-local-setup-remote-access. Follows on from the build-environment work in #1160. The frontend changes are shared across platforms; verified on Android for this task.

Goal

After the user logs in via the cloud, check each router's SKU (model number) on the account against the whitelist. Routers not on the whitelist have remote control disabled and are marked "Not Available"; when all routers on the account are off the whitelist, show a terminal screen. The evaluation is re-run on every launch (the result is not persisted — this avoids permanently locking a user out).

Task breakdown

• Whitelist loader (extensions/remoteAccessWhitelist.js): abstracted source (mock for now) + cache with expiry (reuses storage) + per-SKU compare + fail-open switch
• checkNetworks (authentication.js) evaluates each router's routerModelNumber after login and tags a per-router remoteAllowed flag
• networkSelect per-router "Not Available" marker + tap guard
• All-blocked terminal screen remoteAccessUnavailable + log-out exit
• Wire up the real whitelist source (S3 txt / API)
• Finalize fail policy (fail-open / fail-closed)
• Final wording (currently placeholder i18n keys)
• Functional verification with a real multi-router account

Current status

Frontend code is done, committed, and pushed to origin (branch release-3.6.1-local-setup-remote-access on git.lswf.net). Verified: grunt build passes, whitelist compare logic unit-checked (case-insensitive / mixed / all-blocked / fail-open), and the terminal screen renders on a physical device (Pixel 8).

Confirmed by Jimmy (2026-07-28)

• Fail policy → "same as the cloud-down scenario" — default to local access when the list can't be fetched. (matches our fail-open direction)
• Wording / translation → no localization service anymore; translations will be done via AI. Our placeholder i18n keys stay; only the translation source changes.
• Log-out exit → keep it; PM will provide the on-screen message.
• Whitelist source → Jimmy will provide a sample .txt file (in a day or two). Confirms S3 txt over API.

Key relationship: A and B are driven by the same whitelist (pending Jimmy)

An important relationship we surfaced with Jimmy (awaiting his final confirmation):

• Remote access depends on cloud provisioning done during setup — provisioning is what associates a router with the cloud account. Without it, the router never appears in the remotely-manageable list.
• So a model set up "fully local" (see [LSWF] Local-only setup: skip all cloud steps (sunset) #1163) cannot be remotely accessed afterward. This implies the whitelist = "the list of models allowed to use cloud," and it drives both this issue (remote access) and [LSWF] Local-only setup: skip all cloud steps (sunset) #1163 (local setup) in the same direction:
  • On whitelist → cloud setup (provisions) + remote allowed
  • Not on whitelist → fully local setup (skips provisioning) + remote not possible → "Not Available"
• connected ≠ managed: for the remote scenario, the user isn't next to the router, so the managed-routers list (and their SKUs) can only come from cloud login — a local JNAP SKU lookup does not help item 1 (it only sees the currently-connected router). JNAP-local SKU lookup is relevant to setup/EOL, not to remote whitelist evaluation.

Pending Jimmy's confirmation: for a whitelisted model, does setup still go through normal cloud provisioning (so it can be remotely accessed)? This decision also settles #1163's trigger.

Pending confirmation

• Whitelist source & format: S3 txt confirmed; awaiting Jimmy's sample file. Key format (e.g. model-number string like MR8300) to confirm from the sample.
• Fail policy → confirmed (cloud-down / default local), see above.
• Wording / translation → confirmed (AI translation), see above. Placeholder i18n keys in place; awaiting PM message for the terminal screen.
• Terminal-screen exit: log out is built in — do we also want a "switch account" option? (avoids locking out users who signed into the wrong account)