Projetando um fluxo de trabalho de documento somente visualização com Doconut
7/31/2026

Projetando um fluxo de trabalho de documento somente visualização com Doconut

Aprenda como projetar um fluxo de trabalho de documento somente visualização no ASP.NET usando autorização do lado do servidor, armazenamento controlado, auditoria e configurações documentadas do visualizador Doconut.

Remover um botão de download pode apoiar um fluxo de trabalho somente visualização, mas não torna um documento visível impossível de copiar. Uma implementação segura requer autorização do lado do servidor, armazenamento protegido, sessões de curta duração, registro cuidadoso e uma compreensão honesta do que as restrições da interface do usuário podem alcançar.

Doconut fornece um visualizador de documentos .NET incorporado para aplicações empresariais. Este tutorial explica o design de segurança ao redor sem publicar propriedades de configuração adivinhadas ou outro código-fonte não documentado do Doconut.

Controles de defesa em profundidade protegendo um visualizador de documentos incorporado e limitando ações de exportação
Controles de defesa em profundidade protegendo um visualizador de documentos incorporado e limitando ações de exportação

1. Defina o que significa “Somente Visualização”

Comece com uma política precisa. Diferentes equipes podem usar “somente visualização” para significar:

  • Não oferecer o arquivo original como download.
  • Não mostrar uma ação de exportação.
  • Não permitir impressão.
  • Permitir visualização apenas durante uma sessão autorizada.
  • Impedir que os usuários acessem diretamente o local de armazenamento.
  • Adicionar registros de auditoria quando um documento for aberto.

Esses são controles separados. Decida quais são necessários e verifique se o produto Doconut selecionado, plugins e licença suportam o comportamento do visualizador que você precisa.

Nunca prometa que um documento visível não pode ser capturado. Capturas de tela, câmeras, ferramentas de acessibilidade, capacidades do navegador e acesso autorizado aos pixels exibidos tornam a prevenção absoluta irrealista.


2. Proteja o Arquivo Original

O documento original deve permanecer em armazenamento protegido no servidor.

Use:

  • Identificadores de documento gerados pelo servidor
  • Permissões de armazenamento restritas
  • Criptografia em repouso quando necessário
  • Uma política de retenção documentada
  • Permissões separadas para upload, visualização, exportação e administração

Não envie credenciais de armazenamento, caminhos de arquivo sem restrição ou URLs públicas permanentes ao cliente.


3. Autorize Cada Solicitação de Documento

No ASP.NET Core, proteja a rota do visualizador com os mecanismos padrão de autenticação e autorização.

O servidor deve verificar:

  1. O usuário está autenticado.
  2. O documento existe.
  3. O usuário tem permissão para visualizar esse documento específico.
  4. A ação solicitada é permitida para a função do usuário e o estado atual do fluxo de trabalho.

O atributo [Authorize] pode proteger uma rota, enquanto políticas, reivindicações ou autorização baseada em recurso podem tomar a decisão específica ao documento.

A autorização também deve cobrir qualquer endpoint que retorne dados do documento, páginas, exportações, anotações ou saída de impressão. Proteger apenas a página inicial deixa rotas alternativas expostas.


4. Separe as Permissões de Visualização e Download

Modele as permissões explicitamente em vez de inferi‑las a partir de um botão oculto.

Por exemplo:

  • CanViewDocument
  • CanDownloadOriginal
  • CanExportDocument
  • CanPrintDocument
  • CanManageDocument

Esses nomes descrevem políticas da aplicação, não APIs do Doconut. Sua camada de autorização deve avaliá‑los no servidor antes de executar a ação correspondente.

Um administrador pode ter permissão de download enquanto outro usuário autenticado tem apenas permissão de visualização. Ambos os usuários podem compartilhar a mesma página da aplicação recebendo capacidades autorizadas diferentes.


5. Configure o Visualizador a partir da Documentação Oficial

Use apenas os nomes de configuração e etapas de integração documentados para a versão exata do Doconut instalada em sua aplicação.

A verificada página do visualizador Doconut fornece informações atuais do produto. A página de download e documentação do Doconut fornece recursos de instalação e exemplos específicos de versão.

Se o produto instalado expõe uma configuração suportada para ocultar ou desativar uma ação de download:

  1. Aplique‑a de acordo com a documentação oficial.
  2. Considere‑a como um controle de interface do usuário e de fluxo de trabalho.
  3. Mantenha o endpoint do servidor relacionado protegido.
  4. Teste se usuários não autorizados não podem contorná‑la com uma solicitação direta.

Não copie propriedades de configuração adivinhadas de um artigo não relacionado e presuma que são suportadas.


6. Mantenha a Integração do Visualizador por trás de um Serviço

Um serviço de aplicação dedicado pode:

  • Resolver o documento autorizado
  • Abri‑lo através de uma abstração de armazenamento aprovada
  • Aplicar a configuração de visualizador suportada
  • Liberar streams e recursos temporários
  • Registrar eventos de auditoria sanitizados
  • Retornar erros seguros ao controlador

Isso mantém detalhes específicos do SDK fora das políticas de autorização e do código de apresentação.

Tipos padrão do .NET como Stream, FileStream, CancellationToken e serviços injetados por dependência podem formar a fronteira da aplicação ao redor. Siga a própria documentação do Doconut para chamadas ao SDK.


7. Aplique Defesa em Profundidade

Um fluxo de trabalho somente visualização pode incluir:

  • Autenticação e autorização em nível de recurso
  • Isolamento de rede e armazenamento
  • Duração curta da sessão
  • Rotas restritas de exportação e impressão
  • Marcação d’água quando suportada e apropriada
  • Eventos de auditoria para acesso ao documento
  • Limites de taxa e controles de simultaneidade
  • Regras claras de retenção e limpeza
  • Monitoramento de segurança para padrões de acesso incomuns

Nenhum controle único é suficiente. Um botão oculto sem proteção no servidor é especialmente fácil de contornar.


8. Registre o Acesso sem Vazar Dados

Campos úteis de auditoria incluem:

  • Identificador do documento na aplicação
  • Identificador do usuário autorizado
  • Marca temporal
  • Ação solicitada
  • Resultado
  • Identificador de correlação
  • Motivo sanitizado para negação ou falha

Evite registrar:

  • Conteúdo do documento
  • Credenciais de armazenamento
  • Tokens de acesso
  • URLs sensíveis
  • Caminhos completos do servidor
  • Informações pessoais desnecessárias

Proteja os logs de auditoria de acordo com sua sensibilidade e requisitos de retenção.


9. Teste Tentativas de Contornar a UI

Não pare após confirmar que um botão da barra de ferramentas está ausente.

Teste se um usuário somente visualização pode:

  • Solicitar diretamente a rota do arquivo original
  • Chamar uma rota de exportação ou impressão
  • Alterar um identificador de documento
  • Reutilizar uma sessão expirada
  • Acessar o documento de outro usuário
  • Descobrir URLs de armazenamento no markup ou nas respostas de rede
  • Disparar erros verbosos que revelem caminhos internos
  • Manter acesso após sua permissão ser revogada

Inclua tanto testes automatizados de autorização quanto testes manuais no navegador.


10. Defina Expectativas Precisas do Usuário

Explique o que a política faz:

  • Limita fluxos de download ou exportação fornecidos pela aplicação.
  • Restringe o acesso a usuários autorizados.
  • Pode registrar eventos de visualização.
  • Mantém o arquivo original sob controle do servidor.

Também explique o que ela não pode garantir:

  • Não pode impedir fotografia ou capturas de tela em todos os ambientes.
  • Não pode revogar informações já vistas e lembradas.
  • Não substitui controles contratuais, organizacionais ou de segurança de endpoint.

Essa distinção torna o produto mais confiável e ajuda as partes interessadas a escolher controles adequados para material altamente sensível.


Lista de Verificação

  • Visualização e download usam permissões de servidor separadas.
  • Cada solicitação de documento realiza autorização em nível de recurso.
  • O arquivo original não possui URL pública permanente.
  • As configurações do visualizador vêm da documentação para a versão instalada do Doconut.
  • Ações ocultas têm endpoints de servidor protegidos.
  • Dados temporários têm um processo de limpeza definido.
  • Logs de auditoria evitam conteúdo de documento e segredos.
  • Solicitações diretas não autorizadas são cobertas por testes.
  • Respostas de erro não expõem detalhes internos de armazenamento.
  • A cópia do produto não afirma prevenção absoluta de cópia.

Onde o Doconut se Encaixa

Doconut fornece a camada de visualização incorporada dentro da aplicação .NET. Sua aplicação continua responsável por identidade, autorização, permissões, armazenamento, retenção, auditoria e pela veracidade da promessa “somente visualização”.

Avalie o SDK do visualizador de documentos .NET Doconut com seus requisitos de segurança e documentos representativos. Use os recursos oficiais para configurações suportadas em vez de depender de código‑fonte adivinhado.


Conclusão

Um fluxo de trabalho de documento somente visualização é um design de defesa em profundidade, não uma bandeira booleana. Proteja o arquivo original, autorize cada solicitação, separe permissões de visualização e download, valide as configurações do visualizador suportadas, audite o acesso e teste tentativas diretas de contornar a interface.

Com esses controles em vigor, Doconut pode fornecer a experiência de documento incorporado enquanto sua aplicação ASP.NET impõe a política de segurança ao seu redor.