Execution Pipelines

Handling incoming requests

Execution pipelines in Radiator Server define how the server reacts to incoming requests.

An execution pipeline executes a series of steps against the execution context. Each step performs a specific action, such as validating the request, authenticating the user, processing the request data, or updating the reply attributes.

Request Processing Flow

Every request goes through a series of execution pipelines in sequence:

The primary execution pipeline is @execute, which handles the main request processing including authentication and authorization. After the response has been sent to the client, @final-execute runs for logging and optional database operations.

For backward compatibility and specialized use cases, Radiator Server also supports separate pipelines: @authentication, @authorization, and @accounting. However, using @execute for the main processing flow is the recommended approach.

Pipelines can also include conditional logic to branch execution based on request attributes or user properties. Execution pipelines can be configured for different stages and types of requests.

It is also possible to have multiple handlers for different kinds of requests based on rules.

Best practices example

Here's an example of authentication request processing using the @execute pipeline in a policy handler:

policy "POLICY" {
    handler "HANDLER" {
        @execute {
            # Look up the user in the LDAP directory
            backend "SQL";

            # Verify that values in the request match the values in the DB
            if any {
                radius.request.attr.DSLForum-Agent-Circuit-Id != vars.dsl_agent_circuit;
                radius.request.attr.DSLForum-Agent-Remote-Id  != vars.dsl_agent_remote;
            } then {
                reason "Mismatched DSL IDs";
                reject;
            }

            # Authenticate user with PAP
            pap;

            # Modify the reply attributes based on the backend results
            modify {
                radius.reply.attr.Alc-Subsc-ID-Str = vars.alc_id;
                radius.reply.attr.Alc-SLA-Prof-Str = vars.alc_sla;
                radius.reply.attr.Alc-Subsc-Prof-Str = vars.alc_prof;
            }

            # Accept the request
            accept;
        }

        @final-execute {
            # Log the request details after response has been sent
            log "Request completed for user: {radius.request.attr.User-Name}";

            # Optional: Store session details in database
            backend "ACCOUNTING_DB";
        }
    }
}

Execution stops immediately if an action rejects. For example, the backend call rejects if it fails or returns no results, and the pap rejects if the provided credentials are invalid. reject is an explicit rejection. Some actions can only have side effects; for example, modify cannot reject.

See Also

Navigation
Home