Visualizador Doconut é uma biblioteca .NET de visualização de documentos projetada para colocar PDFs, Office, CAD, imagens e outras famílias de documentos suportados dentro de uma aplicação. Uma integração sólida do Doconut tem menos a ver com encontrar o trecho mais curto e mais a ver com escolher uma fronteira limpa entre sua aplicação, o visualizador e o navegador.

Uma pré-visualização de documento incorporada organizada dentro de um espaço de trabalho estruturado de aplicação web

O hub de documentação Doconut aponta para os caminhos de configuração mantidos para os tipos de projeto .NET suportados. Use o guia que corresponde à versão instalada em sua aplicação e trate a página circundante, as verificações de identidade e o fluxo de acesso como código da aplicação que sua equipe possui.

Comece com a Fronteira de Integração

Existem três maneiras comuns de colocar uma pré‑visualização de documento em um produto. A escolha correta depende de quem controla a navegação, a autenticação e o ciclo de vida do visualizador.

Padrão	Melhor ajuste	Principal compromisso
Visão da aplicação	Uma página .NET que renderiza o visualizador ao lado dos controles do produto	Integração apertada, mas a página e o ciclo de vida do visualizador estão acoplados
Iframe de propriedade da aplicação	Um portal que precisa de isolamento entre a UI host e a rota de pré‑visualização	Fronteira clara, mas a comunicação deve ser projetada explicitamente
Componente de framework ao redor de uma rota de servidor	Um shell React, Angular ou Vue suportado por uma aplicação .NET	Composição front‑end familiar, com mais estados de ciclo de vida para gerenciar

O padrão de iframe não precisa apontar para uma URL pública de documento. Ele pode apontar para uma rota autenticada em sua própria aplicação. Essa rota pode verificar o acesso e renderizar a página do visualizador sem expor um caminho de armazenamento à página host.

Construa uma Superfície de Pré‑visualização Estável e Responsiva

Não reconstrua a marcação ou a inicialização do visualizador a partir de um trecho ilustrativo de blog. Doconut publica os arquivos, etapas de middleware, namespaces e configuração do visualizador adequados a cada linha .NET suportada. Por exemplo, o oficial Guia de configuração .NET 6 ou superior explica o middleware do servidor, o objeto visualizador, as opções de documento, a configuração de renderização e os ativos cliente necessários.

Use esses materiais versionados para criar o visualizador e, em seguida, dê à sua região host uma largura e altura estáveis em seu próprio layout. Reserve espaço suficiente antes do carregamento para que a página circundante não “pule”, e teste a barra de ferramentas e a primeira página nos pontos de interrupção reais suportados por seu produto.

Antes de se comprometer com uma composição, compare-a com as oficiais demonstrações ao vivo do Doconut. As demonstrações cobrem múltiplos estilos de integração .NET e front‑end, incluindo um exemplo dedicado de iframe, e ajudam a distinguir um caminho oficialmente suportado de um trecho que parece plausível.

Mantenha as Decisões de Acesso no Servidor

A página host nunca deve decidir se um usuário pode visualizar um documento. Antes de renderizar a rota de pré‑visualização, a aplicação deve:

Autenticar a requisição.
Autorizar o usuário para o documento e locatário solicitados.
Resolver o documento por meio de um identificador controlado pelo servidor.
Abrir o visualizador somente após essas verificações serem aprovadas.
Retornar um estado genérico de não encontrado ou proibido sem vazar detalhes de armazenamento.

Um identificador opaco melhora a higiene da URL, mas não é autorização. Aplique as mesmas verificações a solicitações de página, miniatura, busca, anotação, exportação e impressão que você expõe.

Decida Como o Host e o Visualizador Comunicam

Uma visão de aplicação pode chamar seus próprios componentes diretamente. Um iframe precisa de um contrato mais restrito. Defina apenas os eventos que o host realmente necessita, como:

Pré‑visualização pronta
Falha ao abrir o documento
Página atual alterada
Sessão expirada
Usuário solicitou fechar a pré‑visualização

Se você usar postMessage, valide tanto event.origin quanto a estrutura da mensagem. Não aceite origens coringa em produção e nunca passe credenciais, locais de armazenamento ou conteúdo bruto do documento através de mensagens.

Trate as Restrições do Navegador como Defesa em Profundidade

Um iframe não está automaticamente isolado. O atributo sandbox pode reduzir capacidades, mas um valor excessivamente restrito também pode quebrar scripts do visualizador, downloads ou comportamento de mesma origem. Comece com o menor conjunto de capacidades documentado para sua integração e teste-o com sua Política de Segurança de Conteúdo.

Também revise:

frame-ancestors ou X-Frame-Options para a rota de pré‑visualização
frame-src para a página host
Comportamento de cookies SameSite se o iframe exigir uma sessão
Política de referenciador para URLs que contenham identificadores de roteamento
Cabeçalhos de cache para páginas que exibam material sensível

Esses controles pertencem à aplicação e à infraestrutura circundantes. Um componente de visualizador não pode escolher a política correta para sua locação e modelo de ameaça.

Projete Estados de Carregamento, Erro e Expiração

Um retângulo em branco não é uma mensagem de erro útil. Forneça à página host estados explícitos para falha de autorização, entrada não suportada, arquivos danificados, tempos limite e sessões expiradas. Mantenha a redação acionável sem revelar caminhos internos ou detalhes de exceção.

Para documentos longos, preserve o contêiner do visualizador enquanto a primeira página é preparada. Se os usuários puderem trocar documentos sem deixar a página, cancele solicitações obsoletas e redefina o título visível, a contagem de páginas e o foco antes de carregar o próximo item.

Acessibilidade e Comportamento do Teclado

Dê a cada iframe um title útil. Torne a pré‑visualização acessível via teclado, forneça um caminho visível para devolver o foco à página host e não prenda o foco dentro de sobreposições personalizadas. Se o visualizador possuir seus próprios atalhos de teclado, documente conflitos com os atalhos usados pelo seu shell de produto.

Um fallback acessível pode oferecer um download controlado ou uma representação alternativa quando as regras de negócio permitirem. Não adicione um link público de arquivo apenas como fallback.

Lista de Verificação Prática

Antes do lançamento, verifique todo o caminho da requisição e não apenas o carregamento inicial da página:

Um usuário autorizado pode abrir um documento permitido.
Um usuário de outro locatário não pode reutilizar a URL de pré‑visualização.
Solicitações diretas a endpoints relacionados ao visualizador recebem as mesmas verificações de autorização.
Atualização, navegação para trás e expiração de sessão produzem estados compreensíveis.
A pré‑visualização permanece utilizável em tamanhos de viewport e níveis de zoom suportados.
Erros no console do navegador e solicitações de rede falhas são visíveis no monitoramento.
Logs de armazenamento e aplicação não registram segredos ou URLs completos de documentos.

Conclusão

O embed Doconut mais sustentável é aquele com um contrato pequeno e explícito. Deixe o Doconut lidar com o papel de visualização de documentos descrito em sua documentação versionada, enquanto sua aplicação controla identidade, autorização, roteamento, retenção, política de navegador e feedback ao usuário. Quando estiver pronto para avaliar os exemplos empacotados localmente, use os oficiais recursos de download do Doconut em vez de copiar código de um artigo não relacionado.