클라이언트 없는 VPN 포털을 통한 SSRS 내보내기 실패: 무엇이 다른가

보고서는 브라우저에서 열리고, 매개변수는 렌더링되며, 내보내기 버튼은 오류, 빈 다운로드 또는 스프레드시트가 열기를 거부하는 파일을 만들어 낸다. 그 조합에는 표준적인 형태가 있다. 작동하는 보고서 페이지는 렌더링과 인증을 검증했을 뿐 그 밖의 것은 검증하지 않았다. 내보내기는 자체 응답을 가진 별도의 요청이며, 클라이언트 없는 포털을 통과할 때는 파일 다운로드를 염두에 두고 설계된 적 없는 재작성 계층도 지나간다.

두 경로, 하나의 작동하는 페이지

렌더링과 내보내기는 같은 버튼에서 시작하더라도 서로 다른 작업이다. 보고서 서버는 브라우저용으로 페이지를 렌더링하고, 내보내기는 자체 콘텐츠 형식과 자체 오류 동작을 가진 다른 출력 확장을 통해 렌더링한다. 이는 내보내기 설명서가 기술하는 바와 같다. 첫 번째를 완벽하게 통과시키는 포털도 두 번째는 망가뜨릴 수 있는데, 두 번째는 포털이 보기를 예상하지 못한 응답이고, 둘은 세션과 주소를 공유할 뿐 그 밖의 것은 거의 공유하지 않는다.

작동하는 페이지는 인증과 도달 가능성의 증거로만 취급하라. 계정이 보고서 서버에 도달할 수 있고 포털이 HTML을 전달한다는 것만 증명한다. 파일 응답, 콘텐츠 배치 헤더, 또는 문서가 아니라 다운로드로 끝나는 리디렉션에 대해서는 아무것도 말하지 않는다.

이미 작동하는 페이지를 다시 테스트하는 대신 내보내기 경로를 따로 비교해야 하는 이유가 바로 여기에 있다. 세션을 공유하는 두 요청은 여전히 두 요청이다.

내보내기가 어디서 끊기는지 결정하는 세 가지 조건

세 가지 질문이 결함의 위치를 빠르게 정하고, 각 답은 서로 다른 소유자를 가리킨다.

첫째, 같은 보고서, 계정, 형식이 내부 네트워크에서 올바르게 내보내지는가? 그렇다면 보고서 서버와 렌더러는 정상이고 차이는 접근 경로에 있다. 둘째, 실패한 응답이 파일 콘텐츠 형식을 담고 있는가, 아니면 파일 확장자를 쓴 HTML 페이지인가? 이것이 렌더러 오류와 포털의 대체를 구분한다. 셋째, 포털이 요청 URL을 다시 쓰는가, 아니면 응답에서 헤더를 제거하는가? 다시 쓰인 URL은 전혀 다른 엔드포인트에 도착할 수 있다.

설정을 바꾸기 전에 세 가지 모두에 답해야 하는데, 각기 다른 해결책이 있기 때문이다. 렌더러 결함은 보고서 서버의 몫이고, 대체된 본문은 포털의 몫이며, 제거된 헤더는 버그가 아니라 정책 문제다.

답을 적어 두라. 그 세 줄로 구성한 지원 사례는 스크린숏 열 장의 가치가 있다.

상태 코드가 아니라 내보내기 응답을 읽어라

HTTP 성공 상태는 무언가가 요청에 응답했다는 것만 증명한다. 본문과 헤더를 함께 검사해야 하는데, 흥미로운 실패는 잘못된 콘텐츠를 담은 성공 응답이기 때문이다.

curl -sS -D export.headers -o export.bin --location "https://portal.example.com/reports/export?format=xlsx"
file export.bin
head -c 300 export.bin

헤더 덤프는 콘텐츠 형식과 포털이 반환한 모든 콘텐츠 배치를 보여 준다. file 명령은 본문이 실제로 무엇인지 식별하고, 스프레드시트가 기대되는 자리의 텍스트 파일은 전형적인 대체된 로그인 페이지다. head 명령은 보고서 전체를 터미널에 쏟지 않고도 HTML을 알아볼 만큼 보여 준다.

그 일부를 공유하기 전에 세션 쿠키와 토큰을 제거하라. 작동하는 내보내기의 캡처는 유용한 증거이고, 다른 사람의 세션 캡처는 사고다.

예외를 계정이 아니라 애플리케이션으로 한정하라

포털이 응답을 다시 쓰거나 차단한다면, 유혹적인 수리는 사이트 전체를 예외로 두거나 보고서를 익명으로 만드는 것이다. 둘 다 다운로드를 고치면서 포털이 존재하는 이유를 없앤다. 범위가 좁은 예외는 하나의 애플리케이션 경로, 하나의 콘텐츠 형식, 하나의 방향을 지정하며, 정책을 소유한 사람이 계속 검토할 수 있다.

실제로 운영하는 게이트웨이 버전과 그 문서화된 애플리케이션 설정을 사용하라. 공급업체가 한때 트래픽을 변경하지 않는다고 설명한 옵션은 일반 지침이 아니며, 오래된 포럼 스레드에서 그것을 복사하는 것이 임시 예외를 영구 아키텍처로 만드는 길이다.

예외를 그렇게 좁게 한정할 수 없다면, 내보내기는 포털 뒤가 아니라 다른 접근 방식의 내부 경로에 속할 가능성이 크다. 사이트 전체 예외는 포털 소유자의 결정이며, 보고서 하나를 위한 우회로가 아니다.

저장 대화상자가 아니라 내보내기를 받아들여라

마지막 확인은 파일 자체로, 파일이 열리고 예상한 열을 담고 있으며 합계가 사용자가 승인한 보고서와 일치하는지다.

저장 대화상자가 나타나는 것은 성공이 아니고, 복구 경고와 함께 열리는 파일도 성공이 아니다. 화면의 보고서와 행 수 및 알려진 값 하나를 비교해야 하는데, 잘린 내보내기는 파일 크기만 보는 모든 테스트를 통과하기 때문이다. 그다음 다시 한 번 내보내되, 잘못된 본문을 한 번 제공한 캐시 계층이 다음 시도에서는 올바른 본문을 제공할 수 있기 때문이다.

사용자가 필요로 한 워크플로를 받아들여라, 그보다 적지 않게. 잘못된 애플리케이션에서 열리는 다운로드도 여전히 실패한 내보내기다.