6.2 KiB
Utilização e recuperação local
Contexto e permissões
Tenant é o cliente contratante, empresa é a entidade empresarial e unidade é uma subdivisão dessa empresa. Pertença ao tenant não autoriza as suas empresas. Pertença à empresa, por si só, também não concede operações: as permissões são linhas em permission_grants.
| Concessão | Âmbito | Efeito |
|---|---|---|
| company.view | Empresa | Consultar e seleccionar empresa |
| company.edit | Empresa | Editar apenas o nome da empresa |
| unit.create | Empresa | Criar unidade; receber consulta/edição explícitas apenas da unidade criada |
| access.manage | Empresa | Gerir concessões nesta empresa, limitado pelos próprios direitos |
| unit.view | Unidade concreta | Consultar e seleccionar essa unidade |
| unit.edit | Unidade concreta | Editar o nome dessa unidade, exigindo consulta e selecção dela |
Não existem papéis universais, privilégios por email ou acesso implícito a todas as unidades. Para conceder a edição de unidade é necessário conceder primeiro a consulta dessa unidade; para outros direitos é necessária consulta da empresa. Um gestor só pode conceder ou revogar direitos que possui no mesmo âmbito. A revogação de consulta de empresa remove os seus direitos dependentes apenas se o gestor tiver autoridade sobre todos eles; caso contrário é recusada. A revogação de consulta de uma unidade remove também a sua edição nas mesmas condições. Estas dependências são registadas na auditoria.
A mudança de empresa limpa a unidade anterior. Cada selecção gera um token de contexto; um pedido de gravação com o token anterior é recusado com 409. Os formulários visíveis são recarregados quando o contexto muda. Identificadores recebidos são sempre revalidados no servidor. Mudanças de direitos aplicam-se no pedido seguinte; cada alteração revalida direitos dentro da transacção e partilha um bloqueio da empresa com as alterações de acessos.
Preparar outro utilizador, sem acessos automáticos
Substituir os campos pelos dados expressamente autorizados. A execução sem --apply é apenas pré-visualização:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\sgf.ps1 php artisan identity:provision --email="EMAIL" --name="NOME" --operator="RESPONSAVEL" --reason="MOTIVO"
Depois da confirmação da operação concreta, repetir com --apply num terminal interactivo. A palavra-passe é introduzida de forma oculta, duas vezes. Requer pelo menos 12 caracteres e até 72 bytes, respeitando o algoritmo bcrypt existente. A conta fica sem empresa e sem permissões até um gestor autorizado conceder os direitos pela interface, começando por company.view.
Para os primeiros acessos de uma empresa sem gestor, o mesmo comando aceita --company=ID, --company-permission=PERMISSAO repetido e --unit-permission=ID:PERMISSAO repetido. Não existe concessão por omissão. Para novo âmbito inicial, --tenant-name e --company-name são explícitos, exclusivos de --company, e não há reutilização por inferência. Se já houver gestor na empresa, a concessão deve ser feita pela interface dentro dos direitos desse gestor.
Todos os procedimentos locais recusam ambientes ou bases diferentes de local / sgf_tempo_dev, e exigem o papel de aplicação sgf_dev_app, não o administrador PostgreSQL.
Recuperar palavra-passe
Verificar primeiro a identidade da pessoa e a autorização do responsável local. Não solicitar a credencial no chat. Pré-visualizar:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\sgf.ps1 php artisan identity:recover --email="EMAIL" --operator="RESPONSAVEL" --reason="MOTIVO"
Só depois da confirmação da operação, repetir com --apply e definir a nova credencial nos dois pedidos ocultos do terminal. A alteração é transaccional, aumenta a versão de autenticação e invalida as sessões anteriores no pedido seguinte. As concessões são preservadas. O operador e o motivo ficam na auditoria; palavras-passe, hashes, cookies e tokens não são incluídos nela. Não colocar segredos no motivo.
Recuperar gestão quando não resta gestor
Não há excepção automática nem administrador universal. O operador local deve pré-visualizar e obter confirmação de concessões exactas para uma empresa existente e utilizador existente:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\sgf.ps1 php artisan identity:provision --existing-user --email="EMAIL" --name="NOME_EXISTENTE" --company=ID --company-permission=company.view --company-permission=access.manage --operator="RESPONSAVEL" --reason="MOTIVO"
A recuperação só é permitida se não existir concessão access.manage nessa empresa. Não altera a credencial, não cria outro tenant/empresa e não acrescenta direitos além dos explicitamente apresentados. --apply exige confirmação no terminal. Não usar SQL directo como procedimento habitual de recuperação.
Prova de navegador com dados sintéticos
Nunca preparar contas de demonstração em desenvolvimento. Depois de parar outras provas e com as tabelas de teste vazias, iniciar:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\browser-proof.ps1 start
A prova usa sgf_tempo_test, endereço 127.0.0.1:8001, cookie, sessões e cache próprios. O ambiente browser-testing mantém CSRF activo e aplica o mesmo guard do destino de testes. O script recusa uma base não vazia e não apaga dados. A credencial aleatória sintética fica apenas num ficheiro local com ACL restrita, nunca no relatório. Não executar a suite enquanto esta prova está activa.
C:\laragon\tools\sgf-tempo\node-v24.22.1-win-arm64\node.exe .\scripts\http-proof.mjs
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\browser-proof.ps1 stop
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\sgf.ps1 test
Parar elimina o ficheiro temporário da credencial; o último teste recria apenas a base de testes e elimina os dados sintéticos da prova. Não apresentar esse ficheiro, palavras-passe, cookies ou tokens. As capturas guardadas em docs/proofs mostram apenas entidades sintéticas.