unifi_page_grants gains role + default grantee types and can_view
(deny-by-default "Everyone else" row); enforcement moves from the
RouteMatched listener — where request->user() is always null and the
check silently failed open — into route-appended middleware with the
permission-holder pass. Pages-access endpoints gain role search +
default-row handling.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Instead of returning HTTP 500 when the UniFi controller can't be reached, these JSON
data feeds now return 200 with an 'available: false' / status 'unavailable' payload so the
dashboard widgets show a friendly unavailable state and the WAN poll stops silently failing.
The Access tab persists user/group grants in unifi_page_grants and the
existing RouteMatched listener honors them on the request path, but
NavItem::visibleTo() only consulted the page's required_permission —
so a granted user never saw the menu entry to reach the page. Register
the unifi.* prefix with the shell's NavVisibilityRegistry so the
sidebar lists exactly the pages the grant table allows.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bundled stable cut for prod. Contents since 1.11.0:
* fix(reboot): suppress webhook alerts during a fleet reboot
regardless of cache driver. RebootAllAps now stamps a Setting
(unifi.reboot_suppression_until) for 20 minutes at the start of a
fleet reboot, and WebhookCheckService consults that Setting in
checkDeviceTransition + checkReboot in addition to the existing
per-MAC cache keys. Database-backed Setting always crosses
container/process/cache-driver boundaries so the suppression can
no longer be defeated by config differences.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Existing Cache::has('unifi:planned_reboot:{mac}') per-MAC suppression
relies on the cache driver being shared across the scheduler and the
snapshot-capture containers. In environments where the cache is
backed by something process-local (or where the keys expire before a
slow reboot completes), webhook alerts fire even though the dashboard
itself initiated the reboots.
RebootAllAps now also stamps a single Setting
(unifi.reboot_suppression_until) at the start of a fleet reboot,
covering a 20-minute window. WebhookCheckService checks this Setting
in addition to the per-MAC cache key, in checkDeviceTransition and
checkReboot. Setting is database-backed so it's always visible across
containers regardless of cache configuration.
v1.11.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bundled stable cut for prod. Contents since 1.10.0:
* fix(banded ssid): treat "PPSK not on this band" as a quiet
info-level skip rather than a failure (1.10.1).
* fix(ppsk sync): the WiFi modal's ingest sync now matches by NAME
within a wlan before falling back to held-by-passphrase, and
salvages rotate_password / schedule from held tombstones into the
active row before pruning them. Prevents the modal from
accumulating phantom "held" duplicates after every rotation and
keeps the rotate flag on the row that's actually live (1.10.2).
* feat(grouped wifi): PPSK updates (both rotation and the manual
modal edit) now follow user-defined SSID groups from the WiFi
Networks page first, falling back to same-SSID-name detection.
Lets the operator pair WLANs whose SSIDs have different names
(e.g. "VCS Guest" and "VCS Guest 5G") (1.10.3).
* fix(name resolution): on this controller, embedded PPSKs don't
carry a name field — the human "GUEST" label is the *network's*
name and entries reference it via networkconf_id. updateEmbeddedPpsk
and verifyEmbeddedPpsk now resolve name → networkconf_id and match
on that, with entry-name and current-passphrase as fallbacks for
other controller variants (1.10.4).
* feat(verify): after every rotation, each affected WLAN is
re-fetched and the new passphrase is checked at the named network.
Anything that didn't actually propagate (mismatch, fetch failure)
shows up as a failed PPSK in the cron run details (1.10.4).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
User-defined SSID groups (configured on the WiFi Networks page and
stored in unifi.ssid_groups) now drive PPSK sibling propagation. The
previous same-SSID-name detection missed cases where two grouped
WLANs have *different* names — e.g. "VCS Guest" on 2.4 and "VCS
Guest 5G" on 5GHz manually grouped by the operator. Falls back to
same-name siblings when no group is configured.
Match-by-name fix: embedded PPSKs on this controller don't carry a
name field — the human "GUEST" label is the *network's* name, with
the entry referenced via networkconf_id. updateEmbeddedPpsk and
verifyEmbeddedPpsk now resolve name → networkconf_id first and match
on that, with entry-name and current-passphrase as fallbacks for
other controller variants.
After every rotation we re-fetch each affected WLAN and verify the
new passphrase is actually present on the named network. Failures
("mismatch" or "fetch_failed" on the primary, anything other than
"not_found" on a sibling) surface in the cron run details as failed
PPSKs so the operator sees what didn't propagate.
v1.10.4.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Every rotation changes an embedded PPSK's synthetic id (it's derived
from sha256(wlan_id : passphrase)). The ingest sync matched only by
unifi_id, so after rotation the row's id was "new" — the sync created
a fresh active row and marked the previous one held. Over multiple
rotations this accumulated: each rotation left a held tombstone, and
the rotate_password / schedule flags were stuck on the original
tombstone instead of transferring to the new active row.
Dev's GUEST PPSK had 3 rows after a few rotations: two held (with
rotate_password=true on the first), one active with rotate=false.
Future rotations would silently skip that PPSK because the active row
no longer had the rotate flag set.
Fix in three layers, all in WifiController::ppskIndex:
1. Match priority extended: unifi_id → name within wlan → held by
passphrase. The name match means a passphrase change just updates
the existing row in place. No more new-row creation per rotation.
2. Salvage step before pruning: for each active row, scan held
tombstones with the same name and copy over rotate_password and
schedule. Operator's rotation opt-in survives history.
3. Prune step: held rows with the same name as an active row in the
same wlan are now hard-deleted (their settings were just salvaged,
their data is stale). Keeps the WiFi modal clean instead of
accumulating phantoms.
v1.10.2.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The sibling-rotation path's "Embedded PPSK not found" error was being
surfaced to the operator as a failure, but it's not — it just means
the PPSK isn't mirrored on that band (GUEST was configured on one
band only, which is a perfectly valid setup). Logging this as a
sibling failure also poisoned the cron run status to "partial".
Now: "not found"-style errors from updateEmbeddedPpsk on a sibling
become info-level log entries and the loop continues. Other errors
(API failures, permissions, etc.) still surface as warnings/failures.
v1.10.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bundled stable cut for prod. Contents since 1.9.0:
* fix(banded ssid): updateEmbeddedPpsk now matches embedded PPSK
entries by name first (e.g. "GUEST") and falls back to current
passphrase. Name-matching survives any passphrase drift caused by
pre-1.8.1 out-of-band manual edits — the sibling-rotation failure
reported on prod after upgrading to 1.9.0 no longer happens.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The sibling-update path on prod failed with "Embedded PPSK not found
by current passphrase" because the DB-stored x_passphrase on the
unedited band was stale — earlier manual edits (pre-1.8.1) only
touched one band, leaving the other band's row out of sync. When
rotation then tried to use that stale passphrase to find the entry,
no match.
updateEmbeddedPpsk now takes an optional $name parameter and tries it
first. PPSK names within a WLAN are unique, so name-matching survives
any passphrase drift caused by historical out-of-band edits.
Passphrase matching stays as a fallback for callers that don't have
a name (none currently — both rotation and the manual modal pass it).
v1.9.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bundled stable cut for prod. Contents since 1.8.0:
* fix(rotate): unifi.password_rotation.last_password is now saved on
successful PPSK rotation as well as whole-SSID rotation. PPSK-only
setups (typical guest-WiFi configurations) will populate the
Settings → Tasks "current password" display and the
/api/unifi/wifi/current-password endpoint after the next rotation.
* fix(banded-ssid): when an SSID is split across 2.4 and 5GHz bands
(band-steering disabled — two wlanconf rows with the same name),
rotating or manually editing a PPSK on one band now also updates
the same-name PPSK on every sibling band. Previously the two halves
drifted out of sync. Both the rotation scheduler and the WiFi modal
use the new UnifiApiClient::getWlanSiblings helper.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three bugs reported from prod after a PPSK rotation:
1. unifi.password_rotation.last_password was only saved after a
whole-SSID rotation. PPSK-only setups (the typical guest-WiFi case)
ran a successful rotation but the setting stayed empty, so the
Settings → Tasks UI never showed the current password and the
/api/unifi/wifi/current-password endpoint returned 404
"no rotated password recorded yet". The PPSK loop now writes
last_password on every successful PPSK rotation.
2. When an SSID is "banded" (band-steering disabled), UniFi splits it
into one wlanconf per band — 2.4GHz and 5GHz each get their own _id
and their own embedded PPSK array. Rotating the PPSK on one band
left the other band with the old password. New
UnifiApiClient::getWlanSiblings($wlanId) finds all wlanconfs that
share an SSID name; both rotation and the manual modal edit now
call updateEmbeddedPpsk on each sibling and update the matching
UnifiPpsk DB rows.
3. The manual WiFi modal edit had the same band-blindness as #2 —
editing the GUEST PPSK on the 2.4GHz half left the 5GHz half stale.
WifiController::ppskUpdate now walks siblings the same way.
v1.8.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bundled stable cut for prod. Contents since 1.7.0:
* feat(access): strict allowlist enforcement. A unifi page with NO
grants is now visible only to super-admins — previously it fell back
to "open for anyone with the route permission". Matches the new
dashboard-wide access model.
* feat(access): the Access tab now adds groups by typeahead search,
mirroring the user-search flow. Only granted groups + super-admin
groups appear in the matrix; other groups are added on demand.
* fix(access): ungranted users hitting a unifi URL get 404 instead of
403 so the page doesn't leak its existence.
Breaking note: super-admins continue to see everything. Non-super
users that previously accessed a unifi page via permission alone now
need an explicit grant in the Access tab. Configure grants before
relying on existing permission-based access.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* UnifiPageGrant::userCanAccess no longer falls back to "open" when a
page has no grants saved. Pages now require an explicit grant for
every non-super-admin user — either a direct user grant or via a
group they belong to. Matches the new dashboard-wide access model.
* Route enforcement returns 404 (was 403) so ungranted users can't even
confirm the page exists.
* New /settings/pages-access/groups/search endpoint mirrors the
user typeahead. Groups are no longer all listed by default — only
super-admin groups (locked-on) and groups with at least one existing
grant show up in the matrix. Operators add more via search.
v1.7.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bundled cut for the stable channel. Contents since 1.6.0:
* fix(webhooks): test endpoint formats payload per platform (Google
Chat / Slack / Discord / Teams) so the Test URL button actually
succeeds against those targets instead of getting a 400 back.
* fix(schema): add missing unifi_device_states.consecutive_count
column the scheduled snapshot capture was failing to insert.
* feat(rotate): persist the active rotated password as
unifi.password_rotation.last_password whenever a whole-SSID
rotation succeeds. Surfaced in Settings → Tasks under the wordlist.
* feat(api): new GET /api/unifi/wifi/current-password JSON endpoint
for external signage / kiosks. Token-protected via
Authorization: Bearer or ?token= query. 401 / 503 / 404 on missing
auth, disabled API, or no rotation yet.
* feat(settings): "Expose WiFi password API" checkbox under the
rotate-passwords block. Off by default. Generate / Regenerate /
Clear token controls and a copy-paste curl example.
No breaking changes. Drop-in upgrade from 1.6.0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previously the API was implicitly active whenever a token existed.
Now there's an explicit unifi.api.enabled setting that gates it:
* WifiApiController returns 503 ("API disabled") when the setting is
off, even if a valid token is presented. Stops the endpoint from
silently working if a token is lying around.
* Settings page exposes the toggle under the Rotate-WiFi-Passwords
block. With it off, the token / URL / curl example are hidden.
* The form submit handles the new api_enabled boolean.
v1.6.3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* RotatePasswords now stores the active wordlist entry as
unifi.password_rotation.last_password whenever a whole-SSID rotation
succeeds. Per-PPSK rotation continues to store passwords on each
PPSK row as before.
* Settings → Tasks tab surfaces the current password in bold beneath
the wordlist textarea so operators can quickly check what's live.
* New JSON endpoint GET /api/unifi/wifi/current-password returns
{"password": "...", "rotated_at": "..."}. Protected by a token stored
in unifi.api_token — pass as Authorization: Bearer <token> or
?token=<token>. 401 on bad/missing token, 503 if no token is
configured, 404 if no rotation has happened yet.
* Settings page lets super-admins Generate / Regenerate / Clear the
token. Generated tokens are 48-char hex from bin2hex(random_bytes(24)).
* The endpoint lives outside the web/auth middleware so external
signage / kiosks can hit it without a session cookie.
v1.6.2.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* The Test URL button was POSTing a generic {event, timestamp, data}
envelope to every endpoint. Google Chat / Slack / Discord / Teams
reject anything that isn't their specific shape — so a successful
Laravel request still got a 400 back from the platform, making the
test look broken. The real webhook events already handle this via
WebhookCheckService::formatPayloadForPlatform; that helper is now
exposed as a public static (buildPlatformPayload) and the test
endpoint uses the same code path, so the test exercises the same
format real events will.
* unifi_device_states was missing a consecutive_count column the
WebhookCheckService inserts on every snapshot capture. The scheduler
was throwing "Unknown column 'consecutive_count'" once a minute.
Added an idempotent migration.
v1.6.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Portal page is removed from the snap-in's nav entry list in composer.json
so it stops appearing in the sidebar. All portal routes, the
PortalController, the Portal.vue page, and the unifi.auth permission
are retained — we'll surface the page again in a later version once the
captive portal flow is fully working.
Minor bump because this is the first release that bundles the recent
batch of features:
* per-page access grants (snap-in-local table, super-admin only)
* cron logs tab with structured per-run history
* PPSK scheduling consistency + drift correction
* settings tabs (Connection / Tasks / Logs / Webhooks / Access)
* webhooks moved under /settings/webhooks + Test URL button
* embedded PPSK update via WLAN config
* page width standardized at max-w-7xl px-4
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Embedded PPSKs live inside the parent WLAN's private_preshared_keys
array — they have no controller-side _id and the synthetic emb_<hash>
we generate locally isn't a real REST id. Hitting /rest/ppsk/emb_xxx
returns HTTP 400/503, which is what the GUEST PPSK rotation was
failing on at the scheduled 3pm run.
* New UnifiApiClient::updateEmbeddedPpsk($wlanId, $oldPass, $newPass):
GETs /rest/wlanconf/{wlanId}, finds the matching entry in
private_preshared_keys by current passphrase, swaps the value while
preserving whichever field name the controller uses (x_passphrase /
password / passphrase), and PUTs the whole WLAN object back.
* RotatePasswords detects emb_-prefixed unifi_ids and routes through
the embedded path. The synthetic id is rederived from the new
passphrase so the DB row stays addressable.
* WifiController::ppskUpdate (manual modal save) does the same — this
is why manual edits sometimes appeared to succeed but the controller
side actually rejected them.
Verified live against the GUEST PPSK on 10.81.0.1.
v1.5.5.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* The model+validation referenced tracked_clients and templates columns
but they were never in the unifi_webhook_configs migration. Any save
attempt that included those keys 500'd with "Unknown column".
Added an additive migration (idempotent) that adds both as nullable
json columns.
* New POST /settings/webhooks/test-url endpoint takes a url+secret in
the body and fires the standard test payload. Lets operators validate
their endpoint before saving the row — useful when first wiring up
Google Chat, Slack, etc.
v1.5.4.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Password rotation was short-circuiting any run that had no whole-SSID
wlan_ids configured, even if there were PPSKs with rotate_password=true
in the database. The PPSK rotation block lived after the early-return,
so per-PPSK rotation never fired. Now we only skip when there's nothing
at all to rotate (neither wlan_ids nor PPSK opt-ins).
* Webhook routes moved from /app/network/webhooks to
/app/network/settings/webhooks so the URL reflects that this is a
settings tab. Route names unchanged.
v1.5.3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Listing every user in the system on the access page didn't scale —
schools have thousands of user rows. Now:
- index() only returns users that already have a UnifiPageGrant
somewhere. Groups stay fully listed (few of them).
- new searchUsers(q) endpoint returns up to 20 typeahead matches
against name or email (min 2 chars).
v1.5.2.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Webhooks now lives as a tab alongside Connection / Tasks / Logs /
Access in the Settings page. The standalone Webhooks page still
exists at /app/network/webhooks but no longer appears in the sidebar.
v1.5.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds unifi_cron_runs table (one row per scheduled-task execution) and
UnifiCronRun::record() wrapper that captures start/finish/status and
exceptions. The three scheduled commands now write through it:
- reboot-all-aps → rebooted/failed AP names per run
- rotate-passwords → rotated SSIDs + PPSKs, failures (when actually
rotating; the "is it due" early-return is silent
so we don't flood the log with no-op rows every
minute)
- sync-ppsk-schedules → enabled/disabled PPSKs (silent when there's
no work)
UnifiCronLogsController returns the most-recent 200 runs as JSON,
filterable by command + status. Behind permission:unifi.settings; no
super-admin required — read-only history is fine for any operator
who can see settings.
v1.5.0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
A snap-in-owned access mechanism. Adds:
- unifi_page_grants table (nav_item_id, grantee_type, grantee_id)
with cascadeOnDelete from nav_items so uninstalling the snap-in
wipes its grant rows automatically
- UnifiPageGrant model + ::userCanAccess(user, navItem) helper
- UnifiPagesAccessController (index + update), super-admin only
- RouteMatched listener in UnifiServiceProvider that 403s any
unifi.* route if the matched nav_item has grants and the user
isn't a super-admin / granted user / member of a granted group
Semantics: a page with NO grants stays open per the existing
permission middleware (no behaviour change). The moment grants are
added, ONLY super-admins and listed users/groups can see/open the
page. Super-admins always pass; their access can't be removed.
v1.4.0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
UniFi's /rest/apgroup endpoints (and per-SSID ap_group_ids writes via
/rest/wlanconf) require session-cookie auth — they don't accept the
X-API-Key header. The Integration API doesn't expose AP groups at all.
So with the current deployment running on API-key auth, every AP-group
operation returned 400 api.err.InvalidObject. Removing the dead code
rather than carrying a feature that can't function.
* Deleted ApGroupController, ApGroups.vue, the /ap-groups/* routes,
and getApGroups/createApGroup/updateApGroup/deleteApGroup from
UnifiApiClient.
* Removed the per-SSID AP-group assignment from Wifi.vue + the
updateApGroups action + /wifi/{wlanId}/ap-groups route + the
ap_group_ids field from the mapWlan output.
* Removed the AP Groups nav entry from composer.json.
If a future deploy adds local-admin username+password auth, AP groups
can be reintroduced — the UnifiApiClient::buildRequest() session-cookie
path is intact.
v1.3.1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previously SyncPpskSchedules returned early when the global setting
was disabled, leaving any PPSK that had been held by a prior sync
stuck in 'held' state. It also only iterated whereNotNull(schedule),
so null-schedule PPSKs ("always on") were never drift-corrected back
to active either.
Now the command always runs and computes a per-PPSK target state:
- global ppsk_scheduling disabled → target = active (always)
- global enabled + null schedule → target = active (always)
- global enabled + has schedule → follow the schedule's slot
PPSKs that drift from the target get enabled/disabled accordingly.
Schedules in unifi_ppsks.schedule are preserved across global toggles
either way — disabling the setting doesn't touch them, so re-enabling
resumes the operator's per-PPSK schedules.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The AP Groups page (ApGroups.vue + ApGroupController + UnifiApiClient
CRUD methods) has been built but never declared in composer.json's
pages list, so it was hidden from the menu. Added it at sort_order=6,
between WiFi Networks and Portal.
The WiFi Networks page already has per-SSID AP-group assignment via
the existing updateApGroups route — that wires into UniFi's standard
ap_group_ids field on wlanconf. (UniFi doesn't expose per-AP-only
assignment separately; the convention is "make a one-AP group for
this AP and assign the SSID to it.")
For the "always pull from UniFi on load" guarantee:
- getWlans() and getApGroups() are already uncached — fresh on every
page load
- getDevices() (feeds the AP picker for group membership) is cached
for unifi.cache_ttl seconds; both ApGroupController::index and
WifiController::index now Cache::forget('unifi:devices') before
reading so the device list is always fresh
v1.3.0.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drops unifi.timezone from the settings form (now lives in
Admin → Settings on the shell). Schedulers (PPSK sync, password
rotation) now read \App\Support\Timezone::current() — same fallback
chain as the rest of the platform.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The /api/self/sites and /proxy/network/api/self/sites endpoints belong
to the legacy session-cookie API — they don't accept X-API-Key auth and
return 401 for keys generated in UniFi OS → Control Plane → Integrations.
Adds /proxy/network/integration/v1/sites as the first endpoint tried,
which is the actual home of API keys. Integration response rows look
like { id, internalReference, name }; getSites normalizes them to the
legacy { name, desc } shape using internalReference as the slug so
downstream URLs (which build paths from $this->site) keep working.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Add password rotation: RotatePasswords console command + migration + service updates
- Add PPSK management: UnifiPpsk model, migration, SyncPpskSchedules console
- Add VLAN groups and AP groups: VlanGroupController, ApGroupController, model, migration
- Add RebootAllAps console command
- Add in_alert column to device states
- Wire new features through service provider, routes, and existing controllers/services
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
