임베디드 문서 보기는 애플리케이션의 일부처럼 느껴져야 하며, 오래된 브라우저 확장이나 로컬에 설치된 데스크톱 프로그램으로 넘겨주는 것이 아닙니다. Windows 기반 ASP.NET 및 .NET 프로젝트의 경우, Doconut은 비즈니스 문서를 웹 애플리케이션 내부에서 렌더링할 수 있는 문서 뷰어 SDK를 제공합니다.
이 가이드는 문서화되지 않은 Doconut 소스 코드를 제시하지 않으면서 플러그인 없는 보기 환경에 대한 아키텍처를 설명합니다.
“플러그인 없는” 의미
플러그인 없는 뷰어는 문서를 열기 전에 최종 사용자에게 ActiveX, Flash, Silverlight 또는 맞춤형 브라우저 확장과 같은 기술을 설치하도록 요구하지 않습니다.
이는 여러 가지 마찰 요인을 감소시킵니다:
- 사용자는 로컬 설치 권한이 필요하지 않습니다.
- IT 팀은 클라이언트 측 플러그인을 배포하고 업데이트할 필요가 없습니다.
- 애플리케이션은 자체 인터페이스 내에서 보기 워크플로우를 유지합니다.
- 레거시 플러그인 의존성이 파일 열기의 조건이 되지 않습니다.
플러그인 없다고 해서 의존성이 없는 것은 아닙니다. 서버는 여전히 올바른 SDK, 런타임, 폰트, 스토리지 접근, 구성 및 라이선스가 필요합니다. 또한 애플리케이션은 인증, 권한 부여, 보존 및 모니터링에 대한 책임을 유지합니다.
서버 측 문서 렌더링이 도움이 되는 이유
비즈니스 문서는 일반 웹 콘텐츠보다 복잡합니다. Office 파일, CAD 도면, 이메일 메시지 및 고해상도 이미지는 각각 형식에 맞는 처리가 필요합니다.
서버 측 .NET 구성 요소가 해당 처리를 담당하고 웹 애플리케이션은 결과적인 보기 경험을 제공할 수 있습니다. 이를 통해 각 사용자에게 원본 작성 소프트웨어 설치를 요구하지 않게 됩니다.
Doconut은 이 역할을 위해 설계되었습니다. 현재 제품 정보에는 PDF, Office 문서, CAD 도면, 이메일 파일 및 이미지 등 문서 유형에 대한 지원이 설명되어 있습니다. 애플리케이션에 필요한 정확한 형식과 기능은 Doconut 뷰어 페이지에서 확인하십시오.
보기 워크플로우 계획
보안 문서 요청은 일반적으로 다음 단계로 진행됩니다:
- 사용자는 애플리케이션 식별자를 사용하여 문서를 선택합니다.
- ASP.NET이 요청을 인증합니다.
- 서버가 해당 특정 문서에 대한 접근 권한을 확인합니다.
- 애플리케이션이 보호된 스토리지 위치를 확인합니다.
- 문서는 지원되는 통합 방식을 사용하여 보기 레이어에 전달됩니다.
- 애플리케이션이 결과를 기록하고 임시 리소스를 해제합니다.
클라이언트는 스토리지 자격 증명, 무제한 서버 경로, 또는 권한이 부여된 세션이 요구하는 것보다 더 많은 문서 정보를 절대 받아서는 안 됩니다.
표준 ASP.NET 보안 경계 사용
보기 페이지는 다른 민감한 리소스와 마찬가지로 보호되어야 합니다.
표준 .NET 메커니즘에는 다음이 포함될 수 있습니다:
- 인증 미들웨어
[Authorize]특성- 권한 부여 정책 및 클레임
- 리소스 기반 권한 부여
- 스토리지 및 보기 서비스를 위한 의존성 주입
- 민감 데이터 필터링이 포함된 구조화된 로깅
권한 부여는 서버에서 평가되어야 합니다. 사용자 인터페이스에서 툴바 동작이나 라우트를 숨긴다고 해서 의도적인 클라이언트가 직접 요청하는 것을 방지할 수는 없습니다.
SDK 접근을 애플리케이션 서비스 뒤에 두기
컨트롤러와 페이지 전반에 뷰어 전용 호출을 퍼뜨리는 것을 피하십시오. 전용 애플리케이션 서비스는 다음을 수행할 수 있습니다:
- 권한이 부여된 문서 식별자를 해결
- 제어된
Stream열기 - 설치된 SDK 버전에 대한 구성을 적용
- 파일 및 스트림 리소스 해제
- 기술적 실패를 안전한 애플리케이션 오류로 변환
- 타이밍 및 정제된 진단 기록
이 경계는 애플리케이션 테스트를 용이하게 하고 향후 SDK 업그레이드의 영향을 감소시킵니다.
패키지 설치 및 버전별 API 안내를 위해 공식 Doconut 다운로드 및 문서 리소스를 사용하십시오.
유용한 뷰어 호스트 구축
애플리케이션이 소유한 뷰어 컨테이너는 실제 문서를 위한 충분한 공간을 확보해야 합니다. 좁은 카드와 고정된 데스크톱 너비를 피하십시오.
.viewer-workspace {
display: grid;
grid-template-rows: auto minmax(0, 1fr);
width: 100%;
min-height: 36rem;
height: calc(100dvh - 4rem);
}
.viewer-host {
min-width: 0;
min-height: 0;
overflow: hidden;
}
이는 주변 페이지를 위한 표준 CSS이며, Doconut 구성은 아닙니다. 문서화되지 않은 내부 선택자를 대상으로 하거나 SDK 옵션을 만들지 마십시오.
페이지는 또한 다음을 제공해야 합니다:
- 명확한 로딩 상태
- 안전한 오류 메시지
- 보이는 문서 제목
- 상위 워크플로우로 돌아가는 방법
- 접근 가능한 애플리케이션 제어
- 넓은 스프레드시트와 상세 도면을 위한 충분한 공간
렌더링 전 문서 검증
사용자가 파일을 업로드할 경우, 다음을 확인하십시오:
- 파일 크기
- 확장자 및 파일 서명
- 지원되는 형식
- 비밀번호 또는 암호화 요구 사항
- 비즈니스별 제한
- 서버에서 생성된 스토리지 이름
원본 파일명으로 서버 경로를 직접 구성하지 마십시오. 안전한 애플리케이션 식별자를 저장하고 권한이 부여된 서버 측 서비스를 통해 해결하십시오.
Windows 서버 준비
렌더링 동작은 서버 환경에 따라 달라질 수 있습니다. 확인하십시오:
- 지원되는 Windows 및 .NET 버전
- 필요한 폰트
- 임시 스토리지 위치 및 권한
- 사용 가능한 CPU, 메모리 및 디스크 용량
- 최대 문서 크기 및 동시 세션 수
- 라이선스 구성
- 정리 절차
프로덕션과 일치하는 환경에서 대표적인 고객 문서를 테스트하십시오.
보안 및 개인정보 체크리스트
배포 전:
- 필요한 경우 보기 요청을 인증합니다.
- 특정 문서에 대해 사용자를 권한 부여합니다.
- 스토리지 경로와 자격 증명을 서버에 보관합니다.
- 임시 파일 권한을 제한합니다.
- 원본, 임시 데이터 및 내보내기에 대한 보존 정책을 정의합니다.
- 사용자에게 표시되는 오류를 정제합니다.
- 로그에서 문서 내용 및 비밀 정보를 제외합니다.
- 업로드 및 동시성 제한을 적용합니다.
- SDK와 애플리케이션 의존성을 최신 상태로 유지합니다.
규정 준수에 대한 주장은 단일 UI 구성 요소가 아니라 전체 배포 시스템과 조직의 프로세스를 반영해야 합니다.
정상 경로 외 테스트
테스트 라이브러리에는 다음이 포함되어야 합니다:
- 다중 페이지 PDF
- 대형 스프레드시트
- 상세 CAD 도면
- 드문 폰트를 사용하는 프레젠테이션
- 첨부 파일이 있는 이메일 파일
- 대형 이미지
- 손상되거나 지원되지 않는 파일
- 권한 없는 요청
- 동시 보기 세션
- 중단된 요청 및 애플리케이션 재시작
실패 시 서버 경로, 스택 트레이스 또는 스토리지 URL이 노출되지 않도록 확인하십시오.
Doconut의 위치
Doconut은 .NET 웹 애플리케이션 내부에 임베디드 문서 보기 기능을 제공합니다. 애플리케이션은 주변 보안, 스토리지, 워크플로우, 반응형 레이아웃 및 운영 제어를 담당합니다.
이러한 분리를 통해 팀은 레거시 플러그인 의존 워크플로우를 교체할 수 있지만, 문서 처리가 손쉬워지거나 책임이 없어지는 것처럼 착각하지 않게 됩니다.
검증된 Doconut .NET 문서 뷰어 SDK를 살펴보고, 선택한 버전에 맞는 지침을 얻으려면 공식 다운로드 페이지를 사용하십시오.
결론
플러그인 없는 문서 경험은 설치 마찰을 줄이고 사용자를 애플리케이션 내부에 머무르게 합니다. 서버에서 권한 부여된 문서 흐름을 기반으로 구축하고, SDK 접근을 격리하며, 넓은 뷰어 호스트를 제공하고, 실제 파일을 프로덕션과 유사한 부하에서 테스트하십시오.
Windows 기반 ASP.NET 및 .NET 애플리케이션의 경우, Doconut은 문서 보기 레이어를 제공하면서 팀이 애플리케이션 및 문서 수명 주기를 제어할 수 있도록 합니다.