Signed Login Transport
The Signed Login transport can be used by servers that want to customize the way they assign clients to islands, replacing or wrapping Archipelago in their architecture.
Instead of connecting directly to a real-time backend, Signed Login makes a signed fetch to obtain the connection string. This intermediate step allows servers to employ whatever assignment strategy they want.
Signed Login URIs have this shape:
signed-login:https://comms.example.com/auth¶m=value
The portion after the signed-login:
prefix can be any valid URL.
Usage #
A Signed Login request is constructed using the signed fetch mechanism.
The response, if successful, will have status 200
and a JSON body with at least the following fields:
Field | Type | Value |
---|---|---|
fixedAdapter |
string |
The assigned transport URI (e.g. livekit: or ws-room: ) |
For example:
{
fixedAdapter: "ws-room:wss://comms.example.com/rooms/17"
}
In case of failure, the response can have any appropriate status code and a JSON body with at least the following fields:
Field | Type | Value |
---|---|---|
message |
string |
(Optional) an explanation or error code for the failure. |
Responses with additional fields in the JSON body are valid, and the contents of the error message
left unspecified. Implementations can use this flexibility to integrate signed-login:
into their applications as they see fit.