v10.34.1

RADIUS proxy forwarding

RADIUS backends now forward safely preservable dictionary-unknown attributes by default. Set proxy_unknown_attributes false to retain the previous behavior. Unknown attributes that cannot safely cross RADIUS/1.0 and RADIUS/1.1 still cause proxy conversion to fail.

EAP-Initiate and EAP-Finish (Codes 5 and 6) now pass strict RADIUS EAP validation, including fragmented messages.

The new eap-message-validation setting defaults to enforce. Set warn or allow on both the backend server and downstream server to forward unchanged malformed EAP from an authenticated Access-Accept or Access-Reject. Requests, challenges and policy-created or modified EAP remain strictly validated.

Improved Radiator UI mobile layouts

The Logs view now provides compact log-source navigation and a full-width search field on small screens. Row details use the full mobile viewport, while Dashboard service and latency categories remain accessible without scrolling through partially visible tabs.

Long names in the configuration Files browser no longer overlap row actions. Backend, server, and service license status tables can be scrolled horizontally on narrow screens instead of compressing their contents. Pages also reserve additional bottom space so mobile browser controls do not obscure their final content.

No configuration changes are required.

Server status and automatic recovery

Radiator now starts available servers even when another server cannot bind or otherwise start. An unavailable server remains visible as failed in Radiator UI with its failure reason. Radiator retries startup every 30 seconds by default and reports the endpoints that the running server actually created.

The Management API /servers and /servers/{name} responses now contain only server identity, installed endpoints, lifecycle status, failure reason, and relevant live activity values. Update API clients that previously read server configuration fields from these responses.

Server names now identify logging and metric namespace components. Before upgrading, rename any server whose name starts with _, contains :: or control characters, or has leading or trailing whitespace. See server configuration for the complete rules.

Configuration backup and restore shell scripts

New radiator-backup and radiator-restore shell scripts provide command-line tools for automated configuration backup and restore through Management API. Before export, the backup script checks for pending configuration and requires --allow-pending when pending changes are detected. Restores support staging, selective import, configuration testing, and deployment. Restart Radiator after deployment to load general configuration changes.

See Configuration Backup and Restore with Shell Scripts for workflow details and operational considerations.

More efficient Radiator UI live updates

The Radiator UI now keeps status, counters, and charts up to date with less network traffic and server processing. Historical charts remain readable across the available time ranges, and the selected range is preserved when a page is reloaded or shared.

Background tabs pause live updates to reduce browser connection and server resource use, then catch up automatically when brought back into view. If live updates are temporarily unavailable, the rest of the Radiator UI remains usable and updates resume after reconnection.

Keep log navigation available for unavailable loggers

Radiator UI now keeps the log view tabs available when the selected AAA logger has no in-memory output configured. This allows operators to switch directly to another configured log view while still showing why the selected view is unavailable.

RadiatorDB Hex Fields and Typed Lists

RadiatorDB collection schemas now support the hex field type for opaque binary values. Hex fields accept hexadecimal text with or without a 0x prefix and store it as lowercase text with a 0x prefix. RadiatorDB put bindings also encode raw byte values automatically, avoiding lossy text conversion when storing RADIUS attributes and other binary AAA data.

List fields can now use any document field type as their item-type. Each item receives the same validation and canonicalization as a standalone field. For example, the following collection stores each address in canonical IP form and preserves packet state as hexadecimal:

field "addresses" {
    type list;
    item-type ip;
}

field "state" {
    type hex;
}

RadiatorDB put bindings preserve list values when only one item is present and avoid adding an extra array around an existing list. This keeps values written by AAA pipelines compatible with typed list schemas.

See the RadiatorDB collection configuration reference for all supported field and list item types.

Improved log row details

Log row details can now be opened by double-clicking a row. Links use the normal text color for both text and underlines, table text no longer becomes selected while opening details, and selected details remain readable with theme-specific neutral colors.

Log tables now keep the main message visible by constraining metadata columns and giving messages the available space. Timestamp columns show the selected timezone once in the header instead of repeating it on every row.

HTTP backend request retries

Generic HTTP, Duo, RSA Authentication Manager, and YubiKey backends now support configurable request retries. Use the retry block to select the retry count, retryable failures and HTTP statuses, delay, and additive random jitter. When you omit delay, Radiator uses 10% of the per-request timeout.

The request timeout applies separately to each attempt. The backend action timeout remains the deadline for the complete operation, including retry waits. Generic HTTP, Duo, and RSA Authentication Manager backends do not retry by default. YubiKey backends now use two retries by default.

See HTTP request retries for the complete configuration and retry-condition reference.

Clarify Radiator UI outage and session notifications

Radiator UI now groups connection failures into one “Server is unreachable” notification while the server remains unavailable. The notification can be dismissed, and once connectivity recovers, a later outage can notify the operator again. If session renewal fails while the server remains reachable, the separate session-expiry warning includes a Continue session action that retries renewal immediately.

Restarting the server from the UI, including after deploying configuration, no longer shows a misleading connection-failure notification during shutdown.

Outages behind a reverse proxy also use one shared notification, without duplicate request errors or session-check warnings. Recovery clears the outage notification automatically.

Reliable Concurrent RadiatorDB Startup

RadiatorDB now coordinates replication topology setup across databases that share the same PostgreSQL instances. Multiple Radiator processes can initialize these databases concurrently, including when they prefer the cluster nodes in different orders, without creating a cross-database startup deadlock.

Interrupted or timed-out subscription setup now releases its coordination locks and recovers incomplete replication slots on retry. This prevents a failed startup attempt from blocking later initialization. Existing RadiatorDB configurations require no changes.

See the RadiatorDB installation guide for multi-master deployment requirements.

Secure Management Session Cookies

Management session cookies now use SameSite=Strict. They also use the Secure attribute when Radiator serves the Radiator UI or API through a TLS listener. Browsers do not send these cookies with cross-site requests or over unencrypted HTTP connections.

Set secure_session_cookie true; in the management.http block when an HTTPS reverse proxy connects to Radiator through HTTP. HTTP-only deployments continue to work without configuration changes. See the management configuration reference for details.

Open backend errors from the dashboard

Radiator UI dashboard now links the Backend errors total directly to Application logs filtered to error-level entries. The total uses the normal dashboard foreground color so it remains readable without implying an undocumented alert threshold.

Open instance details from any Radiator UI page

The profile menu now includes an Instance details action that shows the server version, hostname, uptime, CPU target, and license information without leaving the current page. The existing dashboard action remains available for discoverability and opens the same details surface.

View log message explanations from the logs table

Select a documented message in the application logs table to view the exact log message, event fields, emission details, and explanation in a dialog. Long field values wrap for readability. Filters and the current logs view remain in place while the dialog is open, and a link opens the complete documentation page when more detail is needed.

Search across the Radiator UI

Use the search field in the Radiator UI toolbar to find documentation, configuration filenames and file contents, and live counter names. Search results link directly to the relevant documentation, configuration line, or counter details. Matching application log entries show the event message, timestamp, level, and namespace. Open one result to inspect its row details, or open all matching logs in the filtered Application Logs view. Results from each source are mixed, and category filters let you focus the list.

Documentation search gives more relevant results for multiword queries without being distracted by common words such as "and". Minor spelling mistakes are tolerated, and matching text is highlighted in previews and on the opened page.

Refreshed Radiator UI

Radiator UI has a refreshed look, with consistent headings, spacing, panels, menus, dialogs, and loading and empty states. The updated layouts cover sign-in and management pages, work in light and dark themes, and fit both desktop and mobile screens. Opening Radiator UI also requires a smaller initial download.

Keyboard navigation and mobile dialogs now retain focus consistently. Metric selection includes searchable groups and an explicit selection list, with counter comparison available directly from the overview. RadiatorDB collections can be searched by name or description. Failed database and document requests show an error with a retry action instead of appearing empty. System values remain readable in narrow cards.

No operator action is required.

RadiatorDB Stores Strings Containing NUL Characters

RadiatorDB now accepts documents whose JSON string values contain NUL characters. These characters are stored as Unicode replacement characters, consistent with other invalid text input, instead of causing the entire database write to fail. This also applies to NUL characters in nested attribute values.

Unmasked trace diagnostics

Detailed protocol and backend diagnostics use one exposure policy. Radiator obscures protected values as **obscured** by default. Use the per-request trace action to select detailed AAA backend diagnostics without exposing secrets.

Set RADIATOR_LOG_LEVEL=trace and pass --unmask-secrets to expose protected values in RADIUS packets, LDAP operations, HTTP requests and responses, SQL operations, and MySQL, PostgreSQL, or RadiatorDB connection configuration. Radiator UI displays a warning while secret exposure is enabled.

Modify HTTP request bodies

HTTP server policies can now read, replace, or clear the complete request body through http.request in radconf and context.http.request in Lua. Replacing the body before invoking an HTTP backend also lets a policy forward the updated value with a root JSON binding:

bindings json {
    . http.request;
}

Nested values such as http.request.subscriber.name remain read-only. Replace the complete http.request value to change the body, or set it to none in radconf or nil in Lua to clear it.

The existing http.body and context.http.body names remain available as deprecated compatibility aliases. Existing configurations continue to work, but should migrate to the new request namespace.

See HTTP request and response handling for radconf and Lua behavior, JSON and XML examples, and HTTP backend bindings.

Radiator UI name

The browser-based interface is now called Radiator UI throughout current product text, documentation, configuration templates, and examples. Existing configuration names, environment variables, URLs, and API behavior remain unchanged.

The management certificate template has a new checksum because its visible labels now use the Radiator UI name. Radiator UI warns that the template has changed when opening a configuration generated from the earlier version.

Management sessions follow user activity

Radiator UI now refreshes authenticated management sessions only in response to trusted user interaction. Leaving an unlocked browser tab open no longer keeps the session alive indefinitely, and returning to the UI after system sleep checks the server-side expiration without extending it.

Multiple tabs for the same Radiator UI origin coordinate refreshes so activity in one tab keeps the shared session active without duplicate refresh requests. The UI warns before the session expires and lets the user extend a rolling inactivity deadline. The configured maximum session timeout remains an absolute limit from login, so its warning asks the user to save their work and sign in again instead.

See Management session timeouts for configuration and behavior details.

Pass arguments to backend calls and process results

Backend calls can now pass immutable, request-local values to backend query expressions through an args block:

backend {
    name "RADIATORDB";
    query "FIND_GROUPS";

    args {
        username = radius.request.attr.User-Name;
    }

    @each {
        modify {
            user.groups += doc | jsonpath("$.group.name");
        }
    }
}

Backend calls can also process each returned result with an @each pipeline, or require and process exactly one result with @once. These call-site pipelines expose the backend's result variables, making it possible to apply result-specific policy without storing temporary values in shared request state. @each supports continue and break when individual results should be skipped or iteration should stop.

RadiatorDB is currently the only backend that supports call arguments and result-processing pipelines. Its result variables are doc and key.

Existing backend calls and RadiatorDB query mappings continue to work without configuration changes.

See backend actions for argument and result-pipeline syntax, and RadiatorDB queries for result-processing behavior.

EAP-TTLS passwords are masked in policy output

EAP-TTLS User-Password attributes now render as **obscured** when accessed through eap-ttls.request.attr.* or eap-ttls.reply.attr.*. This prevents tunneled PAP credentials from being exposed accidentally in logs and other string output.

Policies can compare a masked password directly without revealing it. Policies that must pass the clear value to an operation that does not accept masked passwords must explicitly apply the reveal filter:

post "AUTHENTICATE" {
    path "/authenticate";

    bindings json {
        password eap-ttls.request.attr.user-password | reveal;
    }
}

Without reveal, the HTTP request body would contain "password": "**obscured**" instead of the clear credential.

Review policies that read an EAP-TTLS User-Password attribute and add reveal only where access to the clear credential is required. See Execution context and Filters for details.

EAP-TTLS PAP password padding is removed

Password getters also remove the trailing zero padding added by EAP-TTLS PAP. Password-aware operations, including LDAP bind queries, can consume the masked password directly:

bind "BIND_USER" {
    dn vars.dn;
    password eap-ttls.request.attr.user-password;
}

This prevents valid LDAP credentials from being rejected because the bind password contains EAP-TTLS transport padding. No configuration change is required.

Existing configurations that remove this padding in policy can remove that cleanup. For example, a policy that copies the password to a variable and uses the rewrite action to remove trailing zero bytes before an LDAP bind can pass eap-ttls.request.attr.user-password directly to the bind query instead. This simplifies the policy without changing the password sent to LDAP.

Faster startup with trace logging

Radiator now keeps trace logging and Rust backtrace capture independent. Setting RADIATOR_LOG_LEVEL=trace no longer enables RUST_BACKTRACE automatically. Set RUST_BACKTRACE explicitly when error backtraces are needed.

RADIUS dictionary loading also avoids unnecessary backtrace capture. This prevents a significant startup delay when RUST_BACKTRACE=1 is set.

See Logging and Built-in Environment Variables for details.

Rewrite masked passwords securely

The rewrite action now applies regular expression replacements to the actual value of a masked password instead of its display mask. Rewritten passwords remain masked in logs and other string output unless explicitly passed through the reveal filter. Existing configurations require no changes.

See rewrite for action syntax and examples.

TLS server CA certificate bundles

TLS clients using Radiator's shared TLS configuration now support X.509 certificate-chain bundles referenced by server_ca_certificate.

Configuration editor downloads

The configuration editor now offers Download, which includes unsaved edits without saving them to the server.

Use byte-valued passwords in LDAP bind queries

LDAP bind queries now accept password expressions that produce byte values. For example, use base64_decode when an LDAP password is available as Base64 text:

bind "BIND_USER" {
    dn vars.dn;
    password "AGJpbmFyeQ==" | base64_decode;
}

Radiator converts the decoded bytes to UTF-8 before sending the bind request. If the value is not valid UTF-8, Radiator rejects the request without attempting the bind and records the cause in the authentication reason. Existing LDAP bind configurations require no changes.

See LDAP bind operations for more information.

Convert masked passwords to strings securely

The string filter now converts masked password values to UTF-8 text while keeping them obscured in logs and other string output. The converted password remains available to password-aware actions and can still be passed through the reveal filter when plaintext access is explicitly required. Existing configurations require no changes.

See Filters for filter behavior and usage.

Template designer

The redesigned template designer makes nested forms easier to edit. Invalid metadata drafts remain recoverable, and saving preserves edits made while an earlier save is completing.

License expiry warnings

The dashboard and Licenses page warn one month before an active service license expires. For perpetual licenses, it warns when eligibility for newer releases is ending; the current version can continue running.

Fix multivalue template editing

Deleting a value immediately after editing a multivalue template field no longer allows it to reappear in the generated configuration.

Improve menu selection and session recovery

Right-click menus wait for an explicit selection before performing an action. The Retry action for a failed session check now responds immediately.

Improve form editing, log controls, and sign-in

Removing a repeated configuration group or template choice preserves the editing state of the remaining fields. Log columns can be sorted and resized with the keyboard, and the docked log panel can also be resized without a mouse.

After a new login, Radiator UI loads fresh account data instead of reusing results from an earlier session.

RadiatorDB document forms

Radiator UI now prevents saving incomplete documents, including required values inside lists, while preserving unchanged hidden values. Password editing works with both mouse and keyboard, and pending secret or password replacements can be restored before saving. Document forms warn before leaving with unsaved changes. New forms show validation errors only after interaction or an attempted save.

Select RADIUS requests by authentication method

The read-only radius.request.method field identifies the incoming authentication method before policy and handler actions execute. Compare it with radius.METHOD_PAP, radius.METHOD_CHAP, or radius.METHOD_EAP to select requests by method:

conditions all {
    radius.request.method == radius.METHOD_PAP;
}

Use radius.METHOD_NONE when no recognized incoming method is available. The constants can also be assigned to variables and used in pipeline conditions. aaa.method continues to describe the authentication action that executes.

See the execution context reference for details.

Log requests without a matching policy or handler

Radiator now logs when a server receives a request that matches no policy or handler. See No policy handler matched request.

Hidden content excluded from configuration backups

Restoring older backups preserves existing active hidden content instead of restoring archived versions. Ordinary hidden files remain editable in Radiator UI. Back up any intentionally hidden configuration content separately.

See Configuration Import and Export.

User-Name in RADIUS replies

Locally generated EAP Access-Accept replies no longer copy User-Name from the Access-Request. Set radius.reply.attr.User-Name in policy when the reply needs it. Proxied Access-Accept replies continue to forward upstream User-Name. Access-Reject and Access-Challenge replies omit User-Name.