--- title: Controle de acesso description: "Escolha como os leitores acessam sua documentação: pública, protegida por senha, mista, com login próprio via JWT ou SSO, conforme seu público." --- > **For AI agents:** the complete documentation index is at [llms.txt](https://jamdesk.com/docs/llms.txt). Append `.md` to any page URL for its markdown version. O Jamdesk oferece cinco maneiras de controlar quem pode ler sua documentação. A maioria das equipes escolhe uma e mantém essa opção; algumas combinam diferentes abordagens. ## Escolha a abordagem certa | Abordagem | Quando usar | Configuração | |---|---|---| | **Totalmente pública** | Documentação de produtos voltada ao público externo, projetos de código aberto e qualquer conteúdo que você queira tornar pesquisável e fácil de compartilhar. | Padrão; nenhuma configuração necessária. | | **Senha para todo o site** | Todo o conteúdo é interno: runbooks de engenharia, documentação exclusiva para parceiros ou um produto ainda não lançado. Uma única senha protege o site inteiro. | `auth.password.enabled: true` em `docs.json` + defina a senha no dashboard. Consulte [Proteção por senha](https://jamdesk.com/docs/pt/setup/password-protection). | | **Mista (algumas páginas privadas)** | A maior parte da documentação é pública, mas algumas páginas são internas (um runbook, um recurso beta ou uma referência de API interna). | Adicione `private: true` ao frontmatter das páginas internas ou liste-as em `auth.password.private[]`. Consulte [Proteção por senha](https://jamdesk.com/docs/pt/setup/password-protection). | | **Login próprio (JWT)** | Os leitores já fazem login no seu produto. Seu backend assina um token de curta duração para cada pessoa, o Jamdesk o transforma em uma sessão e você pode restringir páginas a grupos especificados no token. | `auth.jwt.enabled: true` e um `loginUrl` em `docs.json`, além de uma chave de assinatura do dashboard. Incluído em todos os planos. Consulte [Autenticação JWT](https://jamdesk.com/docs/pt/setup/jwt-authentication). | | **SSO (Enterprise)** | Os leitores devem fazer login com seu provedor de identidade atual: sem senhas compartilhadas, com um registro de auditoria e possibilidade de revogar o acesso removendo o usuário. | Plano Enterprise. Consulte [SSO](https://jamdesk.com/docs/pt/setup/sso). | Você pode alternar entre as abordagens a qualquer momento editando `docs.json` e enviando as alterações. A mudança de todo o site para o modo misto (ou vice-versa) requer apenas um build. ## Padrões comuns ### Documentação interna e externa no mesmo projeto A maioria das equipes quer manter uma documentação interna abrangente protegida por login, junto com um site público menor para clientes. Você não precisa de dois projetos. Use o **modo misto** em um único projeto Jamdesk: ```yaml --- title: Incident Runbook private: true --- ``` As páginas com `private: true` ficam protegidas; todo o restante continua público. Tudo fica em um único repositório, com um build e um dashboard. A tela de desbloqueio só aparece quando alguém acessa uma página protegida. Para seções internas maiores, liste os caminhos em `docs.json` em vez de marcar cada arquivo. Observação: `auth.password.private[]` ativa automaticamente o modo de páginas específicas. Não adicione `enabled: true` junto com essa opção (isso ativa o modo para todo o site, o oposto do que você quer aqui). ```json docs.json { "auth": { "password": { "hint": "Ask the on-call engineer", "private": ["/internal/**", "/admin/runbook"] } } } ``` ### Dois projetos separados Use dois projetos somente quando os públicos precisarem de identidade visual completamente diferente, domínios personalizados separados, análises independentes ou planos distintos. Por exemplo: um site de documentação público em `docs.acme.com` e uma wiki interna separada em `internal.acme.com`. O custo de manutenção é maior: dois builds, dois dashboards e dois domínios. ### Acesso por usuário usando seu próprio login Se seus clientes já têm contas com você, uma senha compartilhada é um retrocesso: ela pode ser repassada, nunca expira por conta própria e não permite distinguir um cliente do outro. Com a [autenticação JWT](https://jamdesk.com/docs/pt/setup/jwt-authentication), quando uma pessoa autenticada abre sua documentação, ela é redirecionada para uma URL do seu sistema, seu backend assina um token e o Jamdesk cria uma sessão para essa pessoa. Os leitores não precisam de uma conta Jamdesk e não há um segredo compartilhado para repassar. O token também pode incluir grupos. Adicione `groups: ["admin"]` ao frontmatter de uma página; somente visitantes cujo token inclua `admin` poderão acessá-la ou vê-la na navegação. Para todos os demais, a página retorna um 404, sem revelar que ela existe. ```yaml --- title: Enterprise audit log API groups: ["enterprise"] --- ``` Combine isso com caminhos `public` para as partes do site que devem permanecer abertas, como um registro de alterações ou uma página de status. ### SSO para o site de documentação Nos planos Enterprise, os leitores fazem login com seu provedor de identidade (Okta, Google Workspace, Azure AD etc.) em vez de digitar uma senha compartilhada. Essa opção é ideal quando você precisa de um registro de auditoria de quem leu o quê ou quando o desligamento de um usuário precisa revogar imediatamente o acesso à documentação. Consulte [SSO](https://jamdesk.com/docs/pt/setup/sso) para ver uma visão geral e saber como iniciar uma conversa com a equipe de vendas. ## Editores e leitores Às vezes, as pessoas confundem três conceitos diferentes de acesso: | Função | O que fazem | Como o acesso é concedido | |---|---|---| | **Editores** | Escrevem e atualizam conteúdo MDX. | A documentação é editada por meio de commits de MDX no repositório GitHub conectado. Portanto, **as permissões do seu repositório GitHub determinam quem pode fazer commits**. Um push só gera um build se quem o enviou for membro do projeto Jamdesk (identificado pela conta GitHub vinculada ou pelo e-mail) ou uma conta de automação autorizada por você. Um push de qualquer outra pessoa aparece como um build com falha, e o proprietário do projeto recebe um e-mail. Consulte [GitHub](https://jamdesk.com/docs/pt/integrations/github#builds-arent-triggering). | | **Leitores** | Acessam o site de documentação publicado. | Qualquer pessoa (site público), qualquer pessoa com a senha (modo de senha), qualquer pessoa para quem seu fluxo de login assine um token (JWT) ou qualquer pessoa autenticada pelo seu provedor de identidade (SSO). | | **Membros da equipe do dashboard** | Gerenciam builds, análises e configurações do projeto no dashboard do Jamdesk. | Convidados em **Project Settings → Members** no dashboard. A associação à equipe também permite que os pushes da pessoa gerem builds. Consulte [Membros da equipe](https://jamdesk.com/docs/pt/help/projects/team-members). | Uma pessoa da equipe pode acumular qualquer combinação dessas três funções, com uma ligação entre elas: os pushes de um editor só geram builds depois que ele também se torna membro da equipe. ## O que vem a seguir? Proteção por senha para todo o site ou por página, com dicas, rotação e controles de sessão. Proteja a documentação com seu próprio login, sessões individuais e páginas restritas por grupo. Login com seu provedor de identidade para acessar o dashboard e a documentação.