Icecast 2.5.0’s shipped configuration introduces authentication roles alongside compatibility handling for older password and mount-authentication layouts. The web manual still describes many older forms. Use the actual release example and parser when deciding how a new role policy should work.
Separate selection from permission
A role can select requests by HTTP method and other filters. The authenticator then checks the request. The associated access policy decides what a successfully authenticated client may do. Matching a role is not itself permission to use every administration command.
| Element or attribute | Purpose |
|---|---|
role type | Selects the authenticator, for example static, htpasswd, url or anonymous |
name | Names a role for identification |
match-method | Restricts which request methods the role considers |
allow-method / deny-method | Controls permitted methods |
allow-web / deny-web | Controls access to web resources |
allow-admin / deny-admin | Controls administration operations |
connections-per-user | Role policy’s per-user connection control |
option | Supplies settings specific to the selected authenticator |
Read a restricted example
This role fragment is for a mount’s existing <authentication> element in 2.5.0. The path must be replaced. It illustrates listener methods and explicitly denies administration; it is not a complete server policy:
<role type="htpasswd" name="listeners"
match-method="get,head" allow-method="get,head"
allow-web="*" deny-admin="*" connections-per-user="1">
<option name="filename" value="/ABSOLUTE/PRIVATE/PATH/listeners"/>
</role>
<role type="anonymous" match-method="get,head" deny-all="*"/>Keep the source and administrator paths separately configured. Do not place an unrestricted anonymous role ahead of a required listener check. Equally, do not assume a matching block replaces every legacy account: the 2.5.0 parser constructs and combines compatibility roles for older global credentials.
Verify a policy as a matrix
Test anonymous, wrong-password and valid-user requests against the listening resource. Separately test the source connection, administration and web assets with the exact intended accounts and methods. Verify both accepted and denied operations. Read configuration warnings before treating a reload as success.
The XML excerpt has a source-code basis and can be syntax-checked. Its complete access-control behaviour still needs a test on your exact server configuration. A working listener account must not be reported as evidence that unrelated administration rights are restricted.