# Signed Login

El transporte Signed Login puede ser usado por servidores que desean personalizar la forma en que asignan clientes a islands, reemplazando o envolviendo Archipelago en su arquitectura.

En lugar de conectarse directamente a un backend en tiempo real, Signed Login realiza un [signed fetch](https://github.com/decentraland/docs/blob/main/contributor/auth/signed_fetch/README.md) para obtener la cadena de conexión. Este paso intermedio permite a los servidores emplear la estrategia de asignación que deseen.

Los URIs de Signed Login tienen esta forma:

```
signed-login:https://comms.example.com/auth&param=value
```

La porción después de `signed-login:` el prefijo puede ser cualquier URL válida.

### Uso

Una solicitud de Signed Login se construye usando el [signed fetch](https://github.com/decentraland/docs/blob/main/contributor/auth/signed_fetch/README.md) mecanismo.

La respuesta, si tiene éxito, tendrá el estado `200` y un cuerpo JSON con *al menos* los siguientes campos:

| Campo          | Tipo     | Valor                                                          |
| -------------- | -------- | -------------------------------------------------------------- |
| `fixedAdapter` | `string` | El URI de transporte asignado (p. ej. `livekit:` o `ws-room:`) |

Por ejemplo:

```
{ 
  fixedAdapter: "ws-room:wss://comms.example.com/rooms/17"
}
```

En caso de fallo, la respuesta puede tener cualquier código de estado apropiado y un cuerpo JSON con *al menos* los siguientes campos:

| Campo     | Tipo     | Valor                                                   |
| --------- | -------- | ------------------------------------------------------- |
| `message` | `string` | (Opcional) una explicación o código de error del fallo. |

Las respuestas con campos adicionales en el cuerpo JSON son válidas, y el contenido del error `message` se deja sin especificar. Las implementaciones pueden usar esta flexibilidad para integrar `signed-login:` en sus aplicaciones según lo consideren apropiado.