Autenticação do administrador

SubLane usa identidades globais de logins locais e subscrições de espaços de trabalho com funções de proprietário, administrador ou membro. O administrador de primeira execução possui o espaço de trabalho inicial. As sessões são compartilhadas entre espaços de trabalho, enquanto as permissões são exploradas para o espaço de trabalho selecionado. Veja acesso dos membros para permissões, links de convite e ciclo de vida da conta. Chaves de gateway pessoais estão disponíveis através do separado API workflow chave. Password ciclo de vida eo comando de recuperação local são descritos em Controlos de equipa.

Configuração inicial

Iniciar SubLane normalmente e abrir a UI. Se o banco de dados não tiver administrador, /setup mostra uma página de boas- vindas explicando o fluxo de configuração. Selecione Iniciar a configuração para abrir /setup/admin. Primeiro insira o nome de usuário e senha do administrador, em seguida, continue a um passo separado para nomear o primeiro espaço de trabalho. Submeter o segundo passo cria ambos os registros e assina você dentro Nenhuma chave de inicialização separada é necessária.

O assistente de configuração usa /setup/admin; refrescando-o retorna à etapa de administrador. Ambas as rotas de configuração estão indisponíveis após a inicialização: os visitantes de saída foram ao login e os usuários de entrada foram para o espaço de trabalho apropriado para o papel. Nenhum estado de integração ou credenciais de conta são armazenados no armazenamento do navegador.

Completar a configuração localmente antes de abrir a instância para outros usuários. Até que a inicialização termine, qualquer pessoa que possa acessar a página de configuração pode criar o primeiro administrador. O ouvinte padrão e Compose a porta da máquina permanece ligada ao loopback.

Os nomes de usuário usam letras, números, sublinhas ou hífens ASCII 3–32, começando com uma letra ou número. Eles são insensíveis a casos e armazenados em minúsculas. Novas senhas usam caracteres Unicode 8–20 e não são aparados. O login continua a aceitar senhas existentes até o limite de 128 caracteres anterior.

O administrador, a primeira área de trabalho, a associação de propriedade e a primeira sessão são comprometidas em uma transação. Uma inserção guardada garante que as solicitações de configuração simultâneas não podem substituir o primeiro administrador. A inicialização fecha após o sucesso da transação e o reinício do serviço não reabri-la.

As bases de dados de desenvolvimento legado de antes do esquema de pré- lançamento consolidado não são atualizadas automaticamente. Preservar o diretório antigo antes de iniciar uma nova instância. As bases de dados já no esquema consolidado recebem a migração de convites aditivos. Uma sobra setup.key a partir de uma compilação de desenvolvimento anterior é não utilizada pela nova instância.

Excluir ou substituir o banco de dados não é um procedimento de recuperação de senhas. Use o local reset-admin-password --password-stdin comando para um administrador existente, ou os fluxos de alteração/redefinição autenticados descritos em Controlos de equipa.

Sessões

• Login usa um token de 256 bits opaco criptograficamente aleatório em um HttpOnly, SameSite=Lax, path-root cookie.
• SQLite armazena apenas a digest SHA-256 do token.
• As sessões expiram após 12 horas, sem renovação deslizante.
• No máximo cinco sessões são mantidas por usuário. Um novo login substitui apenas o excesso de sessão mais antigo do usuário.
• O encerramento revoga a sessão actual SQLite antes de relatar o sucesso e limpar o cookie.
• Sessões sobrevivem a um processo normal reiniciado.
• O navegador armazena as preferências de tema e idioma localmente, mas nunca os tokens de sessão.

A UI espera pelo estado da sessão do servidor antes de mostrar as páginas protegidas. Ele verifica novamente o estado em foco e periodicamente, e retorna ao login quando um protegido API request informa uma sessão expirada. O encerramento cancela as consultas pendentes e limpa os dados em cache privados. As verificações de fundo também limpam os dados privados quando o ID do utilizador ou as alterações de funções.

Proxies reversas e HTTPS

Para uma implantação de rede, terminar HTTPS no seu proxy reverso e defina a origem externamente visível:

SUBLANE_PUBLIC_URL=https://sublane.example.com ./bin/sublane

A origem deve conter apenas o esquema, host e porta opcional. Caminhos, credenciais, parâmetros de consulta e fragmentos são rejeitados. HTTPS A origem pública permite cookies seguros mesmo quando a conexão interna do proxy usa HTTP.

Sem esta configuração, as verificações de origem do mesmo usam o estado Host da requisição e o estado real do TLS. Os cabeçalhos de host, protocolo e peer enviados não são implicitamente confiáveis. Vite explicitamente preserva a Host original na sua API proxy para desenvolvimento local.

Manter a infra- estrutura ligada ao loopback ou a uma rede privada por detrás do proxy. Use HTTPS para acesso à rede; o local HTTP o padrão é para o desenvolvimento.

Pedido de protecção e limites de recursos

Todas as vias de gestão abrangidas /api/ requer uma sessão de administrador ativada válida por padrão, exceto os parâmetros de autenticação explícitos. /api/keys e o explícito /api/me/requests, /api/me/password, /api/me/limits e /api/me/usage os endpoints são protegidos por sessão para ambos os papéis e impor a propriedade. Os membros podem ler o seu próprio estado de sessão e sair, mas não podem acessar as APIs de gerenciamento de administradores. Os ativos do SPA estático permanecem públicos; renderizar o pacote de aplicativos não concede acesso a dados de gerenciamento.

Mutações requerem um cabeçalho de origem exata, rejeitam metadados de busca de sites cruzados e aceitam JSON apenas. Os corpos de Auth são limitados a 4 KiB e têm um prazo de leitura de cinco segundos.

O registro de configuração, login e convite compartilham um limite de cinco tentativas por minuto por par de conexão e um limite global de sessenta tentativas por minuto. Responses Inclui o Retry-After quando acelerado. O estado do limitador é limitado a 1.024 pares e é local do processo, então reiniciar reinicia os contadores. Atrás de um proxy reverso, os clientes compartilham o orçamento do proxy até que o suporte de proxy confiável explícito seja introduzido.

A derivação de senha é limitada a duas operações simultâneas. Argon2id usa 19 MiB, duas iterações, e uma pista, seguindo o OWASP senha de armazenamento linha de baseEstes limites não são uma garantia de memória de processo total.

API

Configuração e aceitação de login username e password; o formulário de configuração verifica a confirmação da senha antes de enviar. JSON objeto. As respostas autenticadas do estado incluem o ID do usuário persistente, nome de usuário e admin ou member role, e nunca contém tokens ou hashes de senha. As respostas de erro contêm códigos estáveis para as mensagens de frontend localizadas.

Para linha de comando HTTP clientes, forneça o cabeçalho de origem correto e JSON tipo de conteúdo explicitamente. Não coloque credenciais no histórico da shell ou compartilhe- as em relatórios de erros.

Autenticação de dois fatores · Chaves de acesso

/preferences

Adiciona um código do aplicativo autenticador ao login com senha. Aplica-se à sua conta em todos os espaços. Entre sem senha usando impressão digital, rosto ou PIN do dispositivo. Uma chave verificada também atende à autenticação de dois fatores. Você pode adicionar até 10.

Guarde estes códigos em local seguro. Cada um substitui o código do autenticador uma única vez. Eles não serão exibidos novamente. A substituição invalida todos os códigos anteriores.

As chaves exigem HTTPS ou localhost e um navegador com suporte a WebAuthn JSON.