System

Login Config

Login Config — Systems › Login Config — is the mapping layer between a physical WiFi controller/AP's captive-portal redirect and Kiwire's captive portal entry point. Each entry defines one URL slug (used as /login/{slug}) and tells Kiwire which query parameter name that controller vendor uses for MAC, IP, destination, and the rest of the standard fields. Entries are global — the same slug serves every tenant running that controller type, with the specific tenant/NAS resolved per request.

'alt' => 'Dashboard overview', 'caption' => 'The default Kiwire dashboard layout', 'screenshot' => true, 'class' => '', ]) Drop images into: public/assets/img/docs/{page}/{filename} --}}

Image not uploaded yet public/assets/img/docs/login-config/overview.png

The Login Config grid — one row per controller vendor/firmware profile, showing slug, vendor label, and status.

This page documents the Login Config screen itself. For the full walkthrough of wiring a physical controller end-to-end — registering the device, creating a Login Config, pointing the AP's redirect, and pointing RADIUS — see Controller Integration.

What It Does

When a guest connects to an AP, the AP redirects their browser to https://{domain}/login/{slug}, appending its own query string. Kiwire looks up the Login Config whose slug matches, then uses that entry's parameter mapping to read the guest's MAC, IP, and the rest of the standard fields from whatever query keys the controller actually sent — since every vendor names these differently.

A slug with status inactive, or no matching slug at all, causes the request to return a 404.
One entry covers every physical AP of that vendor/firmware, across every site and every tenant — you don't create a separate entry per device or per tenant.

Fields

Field	Description
`slug`	The URL segment used in the redirect — becomes `{slug}` in `/login/{slug}`. Lowercase, hyphenated (e.g. `mikrotik`, `ruckus_ap`, `cisco_wlc`). Changing this on an entry already in use moves the live redirect URL — see the warning under Edit.
`vendor`	Cosmetic label shown in the grid, picked from the configured vendor list. Does not affect request handling — only the parameter mapping does.
`status`	`active` — the redirect endpoint accepts requests for this slug; `inactive` — requests to this slug return a 404.

Parameter Mapping

For each standard field below, enter the query parameter key the controller actually sends it as. Leave a field blank if the controller doesn't send it — it simply resolves to empty rather than causing an error.

Field	What it's used for
`mac`	Guest device's MAC address — primary identity key for the session.
`ip`	Guest device's client IP address.
`destination`	The URL the guest originally tried to reach, for post-login redirect.
`controller_ip`	The controller/NAS's own IP address as reported in the redirect.
`login_url`	The vendor's own callback URL to post the login result back to, where the redirect scheme requires it (e.g. Mikrotik).
`controller_id`	NAS identifier (often `gw_id`, `ap_mac`, or `nasid`) — must match the registered Device Controller so Kiwire can resolve the tenant and zone.
`vlan`	VLAN ID the guest is on, if reported.
`ssid`	SSID the guest associated to.
`zone`	Explicit zone override, on the few vendors that can pass one.
`error`	An error code the controller passes back, surfaced to the login page.

See Controller Integration for a worked example of a real redirect URL and its mapping.

Custom Parameters

If a controller sends additional fields you want recorded that don't fit any standard field above, add them in the Custom Params box as JSON — key is the label to store it under, value is the query key the controller sends:

{
    "ap_name": "ap_name",
    "site_id": "wlan_site"
}

Available Actions

Add Login Config

Click Add Login Config, set the slug, optional vendor label, status, and fill in the Parameter Mapping fields for whichever standard fields this controller sends.

View

Click a row to open a read-only panel showing the resolved redirect path (/login/{slug}), vendor, status, the full parameter mapping table, any custom parameters, and who created/last updated the entry.

Edit

All fields can be changed, including the slug.

Changing the slug on an entry already in production moves the live redirect URL — any physical controller still pointed at the old /login/{old-slug} will start receiving 404s until its splash-page setting is updated to match.

Delete

Removes the entry entirely. Any controller still redirecting to that slug immediately starts receiving a 404 instead of the login page.

Before deleting or deactivating a slug, confirm nothing is still using it — check recent hits in Monitoring › Controller Test or the Portal Log for that slug first.

Required Permissions

Superuser-only — hidden from regular tenant admins in the navigation, and gated by the view-login-config permission.