Origin and subprotocols

Explicitly configure allowed Origins and Lily v2 protocol selection for browser and service clients.

Origin policy identifies which web pages may open a connection. Subprotocol negotiation determines which application protocol the client and server use. Both decisions are separate from authentication.

Browser profile#

use lilyrs::websocket::ServerConfig;
let policy = ServerConfig {
    allowed_origins: vec!["https://app.example.com".into()],
    supported_protocols: vec!["lily.v2".into()],
    require_subprotocol: true,
    ..ServerConfig::default()
};

Pass the policy to the builder with .config(policy). Remember that this selects the entire ServerConfig object instead of merging fields with central configuration. An Origin contains a scheme, host, and optional port; it contains no path, query, fragment, or credentials. Comparison is exact.

Defaults and explicit permissions#

Field	Default	Meaning
`allowed_origins`	Empty	Does not automatically accept browser requests carrying an Origin
`allow_any_origin`	false	Explicit choice to accept every present Origin
`allow_missing_origin`	false	Separate permission for clients without an Origin
`supported_protocols`	`lily.v2`	Server support list
`require_subprotocol`	false	Whether selecting a common subprotocol is required

allowed_origins = ["*"] is invalid. The separate allow_any_origin option allows any Origin; it does not allow a missing Origin. For CLI/Rust clients that do not send Origin, choose allow_missing_origin = true. A present but disallowed Origin remains grounds for rejection.

Protocol selection#

The client proposes a protocol with new WebSocket(url, "lily.v2"). The server selects a common value in its own preference order. Adding another name to the support list does not automatically change the codec. Support for the Lily v2 envelope and requiring the subprotocol header are separate settings.

supports_protocol(name) in the connection context compares only the selected protocol exactly; it does not search the client's entire offered list. When opening the first connection, also preserve the namespace and envelope fields in the client example.

Relationship to CORS and authentication#

This mechanism is not the HTTP crate's CORS middleware, preflight, or response-header contract. Adding an HTTP CORS example to the WS builder does not configure Origin policy. Origin alone is not proof of identity either; custom clients can claim an accepted Origin.

Design session verification together with authentication, and cookie-based cross-site access together with the sessions and CSRF flow. User/object authorization belongs in message guards.