# Manufacturer TODO This document describes what the firmware team needs to embed, preserve, and verify when integrating the replacement GUI for `EOC 2-32`. ## Files To Embed Embed these files from `replacement-gui` into the firmware web root: - `replacement-gui/login.html` - `replacement-gui/index.html` - `replacement-gui/axing-eoc.css` - `replacement-gui/axing-eoc.js` - `replacement-gui/login.js` - `replacement-gui/device-config.js` - `replacement-gui/md5.js` Also include these assets in the replacement GUI package: - `replacement-gui/axing-logo.png` - `replacement-gui/axing-favicon.png` ## Delivery Package For Firmware Build Give the firmware team these files for the new firmware upgrade build. Runtime files to embed: - `replacement-gui/login.html` - `replacement-gui/index.html` - `replacement-gui/axing-eoc.css` - `replacement-gui/axing-eoc.js` - `replacement-gui/login.js` - `replacement-gui/device-config.js` - `replacement-gui/md5.js` Package assets required by the frontend: - `replacement-gui/axing-logo.png` - `replacement-gui/axing-favicon.png` Reference and integration documents to include with the handoff: - `device-api-map.md` - `device-api-map.json` - `todo.md` Reference only, not runtime: - `mirror/auth/site/cgi-bin/*` - `mirror/site/cgi-bin/*` Notes: - `device-config.js` controls the device title, branding label, paths, and AXING product link. - the logo and favicon now live inside `replacement-gui`, so the frontend package is self-contained - `mirror/` is reference material only. Do not ship it as a runtime dependency. ## Backend Contract To Keep The replacement GUI depends on the existing CGI backend and must be served from the device origin. Keep these endpoints available: - `GET /cgi-bin/index` - `POST /cgi-bin/login` - `GET /cgi-bin/info` - `GET/POST /cgi-bin/wifinet` - `GET/POST /cgi-bin/wifiradio` - `GET/POST /cgi-bin/wifivap2g` - `GET/POST /cgi-bin/wifivap5g` - `GET/POST /cgi-bin/vlan` - `GET/POST /cgi-bin/activechg` - `GET/POST /cgi-bin/user` - `GET/POST /cgi-bin/upload` Important: - Keep the current form field names and hidden apply markers unchanged. - Keep the login challenge-response flow unchanged: - `LOGIN_RESPONSE = md5(admin + password + challenge)` - Keep the pages same-origin with the frontend so standard browser `GET` and `POST` requests succeed without CORS workarounds. ## Main GUI Changes These are the main differences versus the stock pages: - New login page, but same legacy MD5 challenge flow. - Modernized main shell and styling. - Information page uses clearer labels such as `Subnet` and `PHY Rate`. - Network page keeps the legacy payload but adds clearer IPv4 validation and placeholders. - Wi-Fi uses: - `wifiradio` - `wifivap2g` - `wifivap5g` - The reachable legacy page `/cgi-bin/wifi` is intentionally not exposed in the new GUI. - User page adds a password visibility toggle and shows `Sign Out` only there. - Upgrade page keeps the legacy multipart upload behavior and submit fields. - Active Changes remains a separate explicit step. ## Replacement Workflow Overview This is the runtime flow of the replacement GUI and where each part is implemented. ### 1. Shared device configuration File: - `replacement-gui/device-config.js` What it does: - defines the device branding values used by both pages - defines the app and login paths - derives the AXING product link from `deviceType` ### 2. Login page flow Files: - `replacement-gui/login.html` - `replacement-gui/login.js` - `replacement-gui/md5.js` What happens: - `login.html` renders the replacement login screen - `login.js` loads the challenge page from `/cgi-bin/index` - `login.js` extracts the hidden `Challenge` value - `md5.js` computes `LOGIN_RESPONSE = md5(admin + password + challenge)` - `login.js` submits the legacy login payload to `/cgi-bin/login` - on success, the user is redirected to `index.html` ### 3. Main app shell Files: - `replacement-gui/index.html` - `replacement-gui/axing-eoc.css` - `replacement-gui/axing-eoc.js` What it does: - `index.html` provides the shell layout, menu, header, status banner, and content container - `axing-eoc.css` provides the full shared styling for both login and main app - `axing-eoc.js` controls navigation, loading, rendering, validation, and form submission ### 4. Page loading model Main file: - `replacement-gui/axing-eoc.js` What happens: - the current page is selected from the URL hash - the app requests the matching legacy CGI page with `GET /cgi-bin/` - for local repository preview only, the app can fall back to the mirrored HTML under `../mirror/...` - the returned HTML is parsed to extract `Org*` and `Status*` JavaScript values - the replacement page is then rendered from that parsed data Important: - the mirror fallback is for local development only - firmware integration should use live same-origin CGI pages only ### 5. Rendering and parsing responsibilities Main file: - `replacement-gui/axing-eoc.js` What is done there: - `parseLegacy...` functions extract values from legacy CGI HTML - `render...View` functions build the replacement page markup - `load...View` functions fetch, parse, cache, and render each page - `bindPageBehavior` attaches the page-specific event handlers after render ### 6. Save workflow Main file: - `replacement-gui/axing-eoc.js` What happens: - the replacement forms keep the legacy field names - on submit, the app serializes the form exactly as the CGI backend expects - most pages submit with URL-encoded form posts - firmware upload uses multipart form submission so the browser sends the file payload unchanged - after save, the banner explains whether `Active Changes` is still required ### 7. Activation workflow Main file: - `replacement-gui/axing-eoc.js` What happens: - configuration pages submit their own changes first - `Active Changes` remains a separate page and action - the app posts `ActiveButton=Active` to `/cgi-bin/activechg` - this keeps the legacy activation model intact ### 8. Page responsibilities at a glance Handled in `replacement-gui/axing-eoc.js`: - `info`: status display only - `wifinet`: network settings form and IPv4 validation - `wifiradio`: Wi-Fi band settings and radio-wide options - `wifivap2g`: 2.4 GHz VAP settings - `wifivap5g`: 5 GHz VAP settings - `vlan`: VLAN enable state and per-port settings - `user`: password update form and sign-out link - `upload`: firmware upload form and upload progress text - `activechg`: apply pending changes Not exposed in the replacement GUI: - `/cgi-bin/wifi` Reason: - its inputs are already covered by `wifiradio`, `wifivap2g`, and `wifivap5g` - keeping it out avoids duplicate Wi-Fi editing paths in the new UI ## Prototype Cleanup Before Release Remove the temporary prototype hint blocks from: - `replacement-gui/index.html` - `replacement-gui/login.html` Keep the runtime status banner elements. Only remove the explicitly marked prototype hint comment and the next hint paragraph. ## Configuration Entry Point If this GUI is reused for another device, start with: - `replacement-gui/device-config.js` Adjust there: - `vendorName` - `deviceType` - `loginTitleSuffix` - `appPath` - `loginPath` The AXING product link is derived automatically from `deviceType`. ## Verification Checklist Before releasing a firmware build, verify: - login succeeds with the device's current admin password - the logo and favicon load from `replacement-gui/axing-logo.png` and `replacement-gui/axing-favicon.png` - Information page loads live data - Network form saves and rejects malformed IPv4 values - Wi-Fi Bands saves correctly - 2.4G VAP and 5G VAP save correctly - VLAN form hides its port grid when VLAN is disabled - User password change works with the real backend - Upgrade submits a firmware image correctly - Active Changes applies saved settings - `Sign Out` appears only on the User page - `Refresh` is hidden on `User`, `Active Changes`, and `Upgrade` ## Files To Review First If the firmware team needs to inspect the implementation quickly, start with: - `replacement-gui/device-config.js` - `replacement-gui/login.html` - `replacement-gui/index.html` - `replacement-gui/axing-eoc.js` - `replacement-gui/axing-eoc.css` - `device-api-map.md` - `device-api-map.json`