# Signed Login

O transporte Signed Login pode ser usado por servidores que desejam personalizar a forma como atribuem clientes a islands, substituindo ou envolvendo Archipelago em sua arquitetura.

Em vez de conectar-se diretamente a um backend em tempo real, Signed Login faz um [signed fetch](https://github.com/decentraland/docs/blob/main/contributor/auth/signed_fetch/README.md) para obter a string de conexão. Esta etapa intermediária permite que servidores empreguem qualquer estratégia de atribuição que desejarem.

As URIs do Signed Login têm esta forma:

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

A porção após o `signed-login:` o prefixo pode ser qualquer URL válida.

### Uso

Uma requisição Signed Login é construída usando o [signed fetch](https://github.com/decentraland/docs/blob/main/contributor/auth/signed_fetch/README.md) mecanismo.

A resposta, se bem-sucedida, terá status `200` e um corpo JSON com *pelo menos* os seguintes campos:

| Campo          | Tipo     | Valor                                                         |
| -------------- | -------- | ------------------------------------------------------------- |
| `fixedAdapter` | `string` | A URI de transporte atribuída (ex.: `livekit:` ou `ws-room:`) |

Por exemplo:

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

Em caso de falha, a resposta pode ter qualquer código de status apropriado e um corpo JSON com *pelo menos* os seguintes campos:

| Campo     | Tipo     | Valor                                                     |
| --------- | -------- | --------------------------------------------------------- |
| `message` | `string` | (Opcional) uma explicação ou código de erro para a falha. |

Respostas com campos adicionais no corpo JSON são válidas, e o conteúdo do erro `message` permanece não especificado. Implementações podem usar essa flexibilidade para integrar `signed-login:` em suas aplicações conforme julgarem adequado.