Registar Novo Sistema
Sistemas mapeados
| Sistema / setor | Resp. | Link | Ciclo | Franquia | Crit. | Seg. | IA | Status | Ações |
|---|
Nenhum sistema encontrado com os filtros selecionados.
Esteira de validação e segurança
Fluxo manual guiado com gates, OWASP Top 10 e decisão final.
Sem análise
1) Triagem e notas de gestão
2) Mapeamento técnico
3) Vulnerabilidades
4) OWASP Top 10 (manual guiado)
5) Decisão final
Permissões e ligação à API
Diagnóstico do que o front envia ao backend (token + e-mail Bitrix) e do papel no portal.
Bitrix24 (iframe)
- BX24.js
- —
- ID / nome
- —
- E-mail usado na API
- —
- LOGIN (Bitrix)
- —
Backend (REST)
- URL base
- —
- Token webhook
- —
- Papel no portal (último /users/me)
- —
- Estado API
- —
Se o seu utilizador não fica administrador
- No Bitrix24, o perfil deve ter e-mail de trabalho preenchido (o REST
user.currentpor vezes não devolve e-mail; o portal tentauser.getpara completar). - No servidor,
BITRIX_ADMIN_EMAILS(em.env) deve incluir exactamente o mesmo e-mail (minúsculas) que aparece acima em «E-mail usado na API» — estes utilizadores ficam sempre com papel admin (acesso à central de utilizadores e à esteira). - Arranque sem admins na BD: com
BITRIX_ADMIN_EMAILSvazio, pode definirPORTAL_BOOTSTRAP_ADMIN_WHEN_EMPTY=truepara o primeiro login receber admin; depois desligue e preenchaBITRIX_ADMIN_EMAILS. BITRIX_WEBHOOK_TOKENno servidor deve coincidir comAPI_CONFIG.webhookTokenneste HTML.
Central de permissões (utilizadores)
Visível apenas para administradores. Papéis: admin — esta central, inventário completo e esteira; analyst — esteira e leitura do inventário; user — apenas novos registos (rascunho).
| Nome | Papel | Último acesso |
|---|