Critical fixes:
- Renamed controller actions to follow Phoenix conventions (verify→new, create→verify)
- Added sudo mode check in GET action using last_sudo_at timestamp
- Added TOTP enrollment check in GET action with redirect
- Changed default return path from /orgs to /users/settings
- Updated route paths from /users/sudo/verify to /users/sudo-verify (dash separator)
- Added success flash message "Identity verified."
Implementation details:
- new/2 (GET): Checks recently_verified_sudo?/1 helper that examines last_sudo_at
instead of authenticated_at to distinguish sudo verification from regular login
- verify/2 (POST): Adds info flash and defaults to /users/settings
- recently_verified_sudo?/1: Private helper checking last_sudo_at within 10 minutes
- Updated all routes, templates, and tests to use new paths and action names
Tests:
- Added tests for already-in-sudo-mode redirect behavior
- Added test for TOTP enrollment requirement
- Updated all test assertions for new route paths and success messages
- All 15 controller tests passing
- Full test suite passing (4076 tests, 0 failures)
- Add UserSudoController with GET and POST /users/sudo/verify routes
- Create verify.html.heex template for TOTP verification form
- Only accept TOTP codes (6 numeric digits), reject recovery codes
- Update grant_sudo_mode to set authenticated_at virtual field
- Exclude /users/sudo paths from return_to overwriting
- Add comprehensive controller tests (12 test cases)
- Verify redirect behavior, error handling, and session management
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The plug was incorrectly placed in the endpoint, causing it to run on
all requests including APIs. Moved to :browser pipeline where it belongs,
and removed redundant fetch_session call since the pipeline handles it.
The test incorrectly suggested the plug handles duplicate headers,
but put_req_header replaces values. Cloudflare only sends one
cf-timezone header, making this test unnecessary.
- Load available firmware in DeviceLive.Show
- Add firmware_update_available? and format_date helpers
- Display blue indicator banner when newer firmware available
- Show current vs latest version with release date
- Add download link and release notes link
- Support MikroTik initially, extensible to other vendors
Phase 6 (final) of firmware tracking complete. All phases implemented:
✅ Database schema (firmware_releases, device_firmware_history)
✅ Version comparison logic (VersionComparator)
✅ RSS fetching worker (daily Oban cron)
✅ Firmware context with logging and PubSub
✅ Version change detection in Discovery
✅ LiveView UI indicators
Implements compare/2 and newer?/2 functions for comparing semantic versions.
Parsing rules:
- Supports 0-3 part versions (e.g., '7', '7.14', '7.14.1')
- Strips v/V prefix and whitespace
- Ignores suffixes after hyphen or space
- Pads missing parts with 0
- Invalid versions (4+ parts, non-numeric, negative) fall back to 0.0.0
Part of firmware version tracking feature (Phase 2).
- Create firmware_releases table to store latest available firmware versions
- Create device_firmware_history table to track version changes over time
- Add FirmwareRelease and DeviceFirmwareHistory Ecto schemas with validations
- Add comprehensive tests for both schemas (23 tests, 100% coverage)
firmware_releases stores one record per vendor/product_line with latest version.
device_firmware_history is append-only audit log of device firmware changes.
Part of firmware version tracking system for MikroTik (extensible to other vendors).
