Skip to content

fix(ui): render VAG vehicle brand configuration - #1510

Merged
frahlg merged 14 commits into
srcfl:masterfrom
segran2:test/vag-ui-v0.139.2-beta.1
Oct 4, 2026
Merged

frahlg merged 14 commits into
srcfl:masterfrom
segran2:test/vag-ui-v0.139.2-beta.1

Conversation

@segran2

@segran2 segran2 commented Oct 3, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • render the VAG EU Data Act setup as Brand + VIN + Email + Password
  • do not show TeslaBLEProxy Proxy IP controls for managed VAG drivers
  • keep the legacy Cookie value intact but hide it from the normal VAG UI
  • hydrate Core HTTP allowed hosts from the Lua driver's own DRIVER.http_hosts declaration, so older saved configs and connection probes can use automatic VAG sign-in without operator-supplied cloud hosts
  • update the UI browser smoke test to use the current Overview view
  • add registry regression coverage for driver-declared HTTP host hydration on both normal startup and connection probes

Root cause

VAG v0.2.0 declares its fixed cloud boundary in DRIVER.http_hosts, but Core previously built HostEnv.HTTPAllowedHosts only from saved YAML/config. Existing VAG configs therefore reached host.http_request with an empty allowlist and automatic sign-in failed with:

http_request: requires a non-empty allowed_hosts

The Settings UI also identified VAG by a filename-only check. A managed/repository driver path could therefore be misclassified as a TeslaBLEProxy-style vehicle and render Proxy IP instead of the VAG credentials.

Verification

Previously validated on the branch:

  • npm test: 684 tests / 94 suites passed
  • ./scripts/ci-local.sh: passed before the latest focused fixes
  • Linux ARM64 builds had vcs.modified=false
  • go test ./internal/drivers/... passed on the Core allowlist fix

Latest IRL ARM64 validation used clean build 6de237e8b49e827b3b42d93e2546a0d59a019205 (vcs.modified=false).

Hardware / IRL validation

Validated against a real Audi through the VW Group EU Data Act portal.

Before the Core fix, both ordinary VAG startup and Test connection selected sign-in=email but failed with the empty-allowlist error above.

After the Core fix:

  • ordinary startup selected sign-in=email
  • automatic VW Group identity sign-in succeeded
  • the driver read the EU Data Act dataset
  • Test connection returned Connected (about 2.3 s, 3 ticks)
  • identity resolved to Audi + the configured VIN
  • the corrected Settings UI shows Brand, VIN, Email and masked Password
  • Proxy IP is no longer rendered for VAG
  • no credentials or authentication form bodies are logged or included here

The returned vehicle dataset was about 15.5 hours old during validation. That telemetry freshness is separate from authentication and this PR does not claim to fix it.

Safety / compatibility

The allowlist is hydrated only from driver-authored DRIVER.http_hosts; arbitrary operator input is not used to grant VAG cloud hosts. Explicit configured HTTP hosts are retained and merged for drivers that need them.

The legacy VAG Cookie is not deleted or overwritten. It remains available in config for compatibility, but is hidden from the normal VAG setup because v0.2.0+ uses Email + Password for automatic re-login.

A separate hardware-CI FTW process was left untouched during IRL testing.

segran2 commented Oct 3, 2026

Copy link
Copy Markdown
Contributor Author

Hardware validation completed successfully on a real ARM64 FTW installation.

Validated build: v0.139.2-beta.2 built from PR head a64469a.

  • Native release installed and committed successfully; previous release retained for rollback.
  • FTW started normally and API reached ready state.
  • VAG EU Data Act driver loaded and authenticated successfully.
  • Device Settings now renders the intended VAG configuration: Brand, VIN, Email and Password.
  • Legacy cookie is not exposed in the normal UI.
  • No TeslaBLEProxy Proxy IP field is shown for the managed VAG device.

PR #1510 is hardware-validated and ready to merge.

segran2 commented Oct 3, 2026

Copy link
Copy Markdown
Contributor Author

@frahlg Could you please review/merge this when you have a chance? All checks are green, there are no base-branch conflicts, and the PR has now been hardware-validated on a real ARM64 FTW installation (see validation above).

frahlg and others added 2 commits October 4, 2026 07:31
Core now merges DRIVER.http_hosts into the allowlist, so the settings
page no longer replaces capabilities.http.allowed_hosts on render. That
replacement dropped any host the operator had added. Also drop the hint
about pasting a cookie, since the cookie field is hidden, and gofmt the
test.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@frahlg

frahlg commented Oct 4, 2026

Copy link
Copy Markdown
Member

Thanks @segran2, and thanks for the hardware validation. I pushed one small commit (d126277) before merging:

  • The settings page no longer replaces capabilities.http.allowed_hosts on render. Your Core change already merges DRIVER.http_hosts into the allowlist, and the UI replacement would drop any host an operator had added.
  • I dropped the hint about pasting a cookie, since the cookie field is hidden.
  • gofmt on the new test.

I also merged master into the branch. It merges once CI is green.

🤖 Generated with Claude Code

@frahlg
frahlg merged commit 695f899 into srcfl:master Oct 4, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants