Captivo Portal changelog — 2026 · Page 7 of 12

New

• Settings changes now also record which field changed and its PREVIOUS value. The "recent changes on this page" strip shows lines like "smsEnabled: on → off", so finding out what a setting used to be no longer requires restoring a backup.

Improvements

• The entry title now names the changed fields ("Portal settings updated (smsEnabled, sessionTtl +2)"), so the list is no longer filled with the same repeated line.
• Unchanged fields are not recorded; even when the form submits everything, only genuine changes are listed.

New

• A search box has been added to the Settings page. You no longer need to know which of the twenty-plus settings pages holds what you are looking for: just type the word that comes to mind — "TLS", "GDPR", "OTP", "587". Only pages you have access to are listed.

Improvements

• Search is insensitive to Turkish characters, so typing without diacritics still finds the right page.

Improvements

• The MAC Whitelist now flags randomized MAC addresses (generated by the device itself). iPhones and Android phones generate such an address per network and change it from time to time, so the entry silently stops working one day with nothing explaining why. A warning also appears when adding one, explaining how to turn off "Private/Randomized address" on the device.
• Entering a multicast address is now rejected — client devices never have such an address, so the entry would never match anything.

New

• An e-mail delivery log has been added. Under Settings > Logs, a new "E-mail" tab shows every send: who it went to, the subject, whether it succeeded, WHY it failed if it did, and which SMTP configuration was used. Previously a failed e-mail was not visible anywhere — it failed silently and nobody noticed.

Improvements

• Recipient addresses are masked in the list (the same approach as the SMS log).
• Records are deleted automatically after 180 days (configurable via EMAIL_LOG_RETENTION_DAYS); recipient addresses are personal data and are not kept indefinitely.

New

• Settings pages now have a "recent changes on this page" strip. On the RADIUS, Portal, SMS and Branding pages you can see the latest changes, who made them and when, right there. Especially where a setting affects the portal, the answer to "why is this like this" is now on the same page.

Improvements

• Repeated identical changes are collapsed into a single line with a count, so the strip is not filled with the same entry over and over.
• The strip is not shown at all when there are no records.

Fixes

• The most destructive operations in RADIUS settings were not recorded in the audit log at all: regenerating the shared secret, regenerating and revoking the portal API key, and adding or removing NAS IP addresses. These break the portal and guest authentication instantly, yet there was no answer to "who did this, and when". Each is now recorded separately, and NAS operations also record which address was involved.
• These are kept separate from the general "RADIUS settings updated" entry, so that a checkbox change and a secret rotation are not conflated during a security review.

Improvements

• The API key now shows its age as information when it has not been changed for more than 6 months.

Fixes

• The confirmation shown when regenerating the API key understated the consequence: it only said the old key would be revoked and a new one created. But the API key is embedded in the portal HTML you downloaded — the moment it is regenerated, the portal on your NAS stops working and guests cannot sign in until you download and upload the template again. The confirmation now states this and the step you need to take.
• The same omission applied to regenerating the RADIUS shared secret and the webhook secret. Both now say what must be updated on the other side (the NAS settings / the webhook receiver).

Improvements

• The Setup Status panel on the Settings page now has an "upcoming expiry dates" section. It gives advance notice when MAC entries, local users or voucher batches expire within 14 days, and separately highlights records that have already expired but still appear active in the list. It also notes that when a voucher batch expires, every code in it stops working at once.

Fixes

• The "Test connection" button in SMTP settings failed the same way and is fixed too. The same calculation existed in four places in three different forms; it now comes from a single source.
• Requesting a password by e-mail failed with a "wrong version number" error when the SMTP settings used port 587 with "SSL/TLS" ticked. Port 587 is a STARTTLS port: the connection starts in plain text and is then upgraded. The behaviour of standard ports is now applied correctly regardless of that checkbox (587/25/2525 → STARTTLS, 465 → direct SSL); on non-standard ports your own setting still applies. No settings change is needed — existing configurations are fixed as well.

New

• The Setup Status panel on the Settings page now warns about settings that block guest login. It previously measured each integration separately; it now also checks whether they work together. For example, if SMS login is enabled but no SMS provider is configured, the portal offers SMS to guests, they enter their number and the code never arrives — this is now visible at a glance on the settings page, with a link straight to the relevant page.

Improvements

• Checks included: SMS/e-mail/hotel login enabled without a ready provider, sponsor approval enabled with no active sponsors, RADIUS configured with an empty NAS IP list, and every address in that list being a LAN address (in which case no device can authenticate).

Improvements

• In Settings > Portal Customization, the SMS Login card now shows a status badge: "SMS: ready" or "SMS: not configured". The e-mail and Hotel cards already had this badge; SMS did not. If no provider is configured, or it is inactive, the card shows a warning and a link to the SMS settings.

Fixes

• When SMS login was enabled but no SMS provider was configured, the portal still offered SMS to guests: they entered their number and the code never arrived — and nothing on the settings page explained why. The status is now shown on the card.

Fixes

• The CSV download on the Sessions page always wrote personal data (guest name, phone, IP, MAC) in the clear, even where it was masked on screen. Anyone who could see the page could download it, bypassing the tenant's open-data setting, the user's reveal permission and the automatic re-masking. The download now follows the same rule as the screen, and exporting personal data in the clear is written to the audit log.

Fixes

• Devices allowed through by MAC (MAC whitelist) could get online, but their sessions never appeared on the Dashboard, Analytics or Sessions pages. Because these devices send a bare MAC address as their identity, the session could not be attributed to any tenant; it is now resolved from the MAC list. The MAC is recognised in any notation the device sends (upper or lower case, colons, dashes, or no separator).

Fixes

• In Analytics > Peak Hours, the "daily average" read lower than it should when a date range was selected, because one day outside the range was counted as well.
• In timezones that observe daylight saving, report tables and charts gained an extra empty day that fell outside the selected range. The daily axis now walks calendar days directly.
• Monthly scheduled reports could be set to day 29-31 of the month, in which case they silently never ran in months without that day. The choice is now limited to 1-28, matching the picker in the interface.

Improvements

• Session duration on the Sessions page is now based on the duration the device itself reports. It was previously derived from the start time alone, so if that timestamp was corrupted (which can happen when a device reboots and resets its session counter) a session of a few minutes could appear to have run for months.

Fixes

• For tenants in timezones that observe daylight saving (e.g. America/New_York), day boundaries drifted across the clock changes: on the day the clocks go back, the last hour of that day dropped out of analytics and reports entirely, and on the day they go forward an hour belonging to another day was pulled in. The "yesterday" and "last 7 days" boundaries on the dashboard could also shift by a day right after a transition. Tenants in Turkey were unaffected, as the Turkish timezone is permanently UTC+3.
• The day count allowed for unmasked report downloads was one too high for ranges containing a daylight saving transition, which could permit a range beyond the limit.

Improvements

• In Analytics, "Session Duration Distribution" and "Average Dwell Time" only count completed sessions while the Sessions card above also counts ongoing ones, with nothing explaining the difference. The captions now say "completed sessions".

Fixes

• The Settings > Privacy > Open Data Display help texts described the opposite of the actual behaviour: when the setting is ON, personal data is shown openly and the 'Show' step disappears; revealing fields one at a time with 'Show' is what happens when it is OFF. The warning also claimed these accesses were recorded in the audit log — but with no 'Show' step nothing is recorded, and auto re-masking does not apply either. The texts now match the real behaviour.
• In Analytics > Conversion Funnel the "Portal Opened" bar looked longer than the others even when all counts were equal. The drop-off column on the right was not rendered for the first row, so the bar expanded into the empty space; all four bars now share the same scale.

Improvements

• Dashboard > System & NAS Health now explains that the address shown is the one the device reports about itself, which may legitimately differ from the whitelist in RADIUS settings.

Fixes

• Dashboard > System & NAS Health marked healthy devices as "not listed" while showing the IP that actually sends your traffic as "silent" (dead). The check was comparing two different addresses: the IP the device reports about itself and the source IP packets arrive from. The check was redundant anyway — the RADIUS server never accepts packets from an address that is not on the list.

Improvements

• Settings > RADIUS > NAS IP Whitelist now marks LAN/private IP entries with a "no effect" badge. Previously the warning appeared once when adding the IP and nothing in the list showed that the entry did nothing.
• The NAS IP Whitelist description now makes clear what is being asked for: the source IP your device sends RADIUS packets from (its WAN address). The LAN IP the device reports inside the packet shows up in the session list but is not used for matching — a distinction that was causing confusion.

Fixes

• On some MikroTik devices sessions appeared to have started months earlier, and today's usage was attributed to the wrong day on the Dashboard and Analytics pages. The device resets its session counter on reboot, so a new session overwrote the old record; session start times are now corrected automatically from the duration the device reports.
• On-premise installs showed a "you must enter a public IP" warning when adding a LAN IP to the NAS IP list. On-premise the device connects from the same network, so a LAN IP is the correct value — the warning has been removed.

Fixes

• The sponsor dropdown in the portal was always empty: even with sponsors defined and sponsor login enabled, guests only saw "-- Select a sponsor --" and could never submit the form because the field is required. The list is now loaded when the portal opens, and clearly says so when no sponsor is defined.

New

• Terms of Use and Privacy Policy links in the portal now open inside the portal instead of a new tab. Guests stay in the login flow — on phones, the captive portal window often cannot open new tabs or loses the session. If the window cannot open, an "open in a new tab" option is offered.

Improvements

• The "Advanced Settings" section in portal settings was renamed to "Links & redirect" — all three fields in it are link settings.
• A notice was added to that section: it lists the domains of the addresses you entered with one-click copy, and states clearly that those domains must be in your access point's walled garden for guests to reach the pages.

Improvements

• Guest status now reflects access validity: guests whose login credentials have all expired are automatically moved to "Expired", so you can filter and clean them up in bulk.
• The "Sponsor-only login" description in portal settings was clarified: it explains that your SMS and email settings are kept, merely hidden from guests, and return when you turn it off.

Fixes

• On the guest detail page, phone, email and name were shown in the clear regardless of your privacy settings. It now follows the same rule as the list: masked by default, revealed with the eye icon, re-masked after the timeout, and every reveal is recorded in the audit log.
• Logo, favicon, portal background and feedback attachment uploads failed with a server permission error (EACCES); fixed and made durable across deployments.
• Singular phrases were wrong in the English interface ("1 days", "1 guests selected" — 61 strings); correct singular/plural forms are now used.

New

• A "Setup status" panel was added to the settings home: it shows at a glance whether the portal, RADIUS, SMS, email, guest profiles, branding, hotel and webhooks are configured, and links straight to whatever is missing. Only areas you have access to are shown.
• Scheduled reports now have a "Send me a test" button: send the report to yourself instead of the recipient list to check its content. The schedule is not affected.
• Hotel reservations now have a manual "Check out" button: it closes an active stay and terminates the guest's WiFi sessions.

Improvements

• When picking the portal's primary colour, its readability against the background (WCAG contrast) is shown instantly, so an unreadable choice is caught before saving.

Improvements

• The documentation page is noticeably faster: release notes now load only when you open that tab (page payload dropped from 88 KB to 26 KB).
• The feedback detail dialog now closes with Esc and is properly marked up for screen readers.
• You are warned before leaving the page with an unsent feedback message.

Fixes

• Fixed missing Turkish characters in error messages guests see (42 strings such as "daily SMS limit exceeded", "wrong username or password", "invalid phone number").
• When removing a feedback attachment failed, nothing was reported; the attachment disappeared from the screen but stayed on the server.
• Feedback submission is now rate limited; each submission emails and notifies every administrator, and there was no limit.

Improvements

• The scheduled report form now states which timezone the time refers to.
• Report recipient addresses are validated as you add them; an invalid address previously surfaced only on save, with an English error message.
• Resetting branding to defaults is now recorded in the audit log.

Fixes

• Fixed missing Turkish characters in the branding reset error message.

Improvements

• 802.1X and VPN operations are now recorded in the audit log: creating users and groups, resetting passwords, unlocking, resetting authenticators, adding/removing switches and gateways, regenerating shared secrets.
• Setting a password for an 802.1X or VPN user now uses a masked field; the password used to appear in plain text in a browser prompt.
• Resetting a VPN user's authenticator enrollment now asks for confirmation — they cannot sign in until they enroll again.
• Unsaved-change warnings now also cover directory (LDAP), UniFi and server address settings.

Fixes

• The group selector in the 802.1X user list is now named for screen readers.