Eksport SSRS zawodzi przez portal VPN bez klienta: co się różni

Raport otwiera się w przeglądarce, parametry są renderowane, a przycisk eksportu daje błąd, puste pobranie albo plik, którego arkusz kalkulacyjny nie chce otworzyć. Ta kombinacja ma standardowy kształt. Działająca strona raportu przetestowała renderowanie i uwierzytelnianie i nic więcej. Eksport to osobne żądanie z własną odpowiedzią, a przez portal bez klienta przechodzi także przez warstwę przepisywania, która nigdy nie była projektowana pod pobieranie plików.

Dwie ścieżki, jedna działająca strona

Renderowanie i eksport to różne operacje, nawet gdy zaczynają się od tego samego przycisku. Serwer raportów renderuje stronę dla przeglądarki i renderuje eksport przez inne rozszerzenie wyjściowe z własnym typem zawartości i własnym zachowaniem przy błędzie, jak opisuje dokumentacja eksportu. Portal, który przepuszcza pierwsze bezbłędnie, wciąż może zepsuć drugie, bo drugie jest odpowiedzią, której portal nie spodziewał się zobaczyć. Oba dzielą sesję i adres, i prawie nic więcej.

Traktuj działającą stronę wyłącznie jako dowód uwierzytelnienia i osiągalności. Dowodzi ona, że konto może dotrzeć do serwera raportów i że portal przekazuje HTML. Nie mówi nic o odpowiedziach z plikami, nagłówkach rozmieszczenia zawartości ani przekierowaniach, które kończą się pobraniem, a nie dokumentem.

To cały powód, by porównywać ścieżkę eksportu osobno, zamiast ponownie testować stronę, która już działa. Dwa żądania dzielące sesję nadal są dwoma żądaniami.

Trzy warunki, które decydują, gdzie eksport się psuje

Trzy pytania szybko lokują usterkę, a każda odpowiedź wskazuje innego właściciela.

Po pierwsze, czy ten sam raport, konto i format eksportują się poprawnie z sieci wewnętrznej? Jeśli tak, serwer raportów i jego renderer są w porządku, a różnica tkwi w ścieżce dostępu. Po drugie, czy nieudana odpowiedź niesie typ zawartości pliku, czy stronę HTML z rozszerzeniem pliku? To oddziela błąd renderera od podstawienia przez portal. Po trzecie, czy portal przepisuje URL żądania albo usuwa nagłówki z odpowiedzi? Przepisany URL może wylądować na zupełnie innym punkcie końcowym.

Odpowiedz na wszystkie trzy, zanim zmienisz jakiekolwiek ustawienie, bo każde ma inne lekarstwo. Błąd renderera należy do serwera raportów, podstawiona treść należy do portalu, a usunięty nagłówek to kwestia polityki, nie błąd.

Zapisz odpowiedzi. Zgłoszenie do wsparcia zbudowane z tych trzech linii jest warte dziesięciu zrzutów ekranu.

Czytaj odpowiedź eksportu, a nie kod statusu

Udany status HTTP dowodzi tylko, że coś odpowiedziało na żądanie. Sprawdź treść i nagłówki razem, bo ciekawa usterka to udana odpowiedź z niewłaściwą zawartością.

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

Zrzut nagłówków pokazuje typ zawartości i wszelkie rozmieszczenie zawartości zwrócone przez portal. Polecenie file identyfikuje, czym treść naprawdę jest, a plik tekstowy tam, gdzie oczekiwano arkusza, to klasyczna podstawiona strona logowania. Polecenie head pokazuje dość, by rozpoznać HTML bez wylewania całego raportu do terminala.

Usuń ciasteczka sesji i tokeny, zanim podzielisz się czymkolwiek z tego. Zapis działającego eksportu jest przydatnym dowodem, a zapis sesji należącej do kogoś innego to incydent.

Ogranicz wyjątek do aplikacji, nie do konta

Jeśli portal przepisuje lub blokuje odpowiedź, kuszącą naprawą jest wyłączenie całej witryny albo uczynienie raportu anonimowym. Oba rozwiązania naprawiają pobieranie i usuwają powód, dla którego portal istnieje. Wąski wyjątek nazywa jedną ścieżkę aplikacji, jeden typ zawartości i jeden kierunek, i pozostaje weryfikowalny przez tego, kto posiada politykę.

Użyj tej wersji bramy, którą naprawdę uruchamiasz, i jej udokumentowanych ustawień aplikacji. Opcja, którą dostawca kiedyś opisał jako pozostawiającą ruch bez zmian, nie jest ogólnym zaleceniem, a kopiowanie jej ze starego wątku forum to sposób, w jaki tymczasowy wyjątek staje się trwałą architekturą.

Jeśli wyjątku nie da się ograniczyć tak wąsko, eksport prawdopodobnie należy do ścieżki wewnętrznej z inną metodą dostępu, a nie za portalem. Wyłączenie całej witryny to decyzja właściciela portalu, a nie obejście dla jednego raportu.

Zaakceptuj eksport, a nie okno Zapisz

Ostatnią kontrolą jest sam plik: otwiera się, zawiera oczekiwane kolumny, a jego sumy zgadzają się z raportem zatwierdzonym przez użytkownika.

Pojawienie się okna Zapisz nie jest sukcesem, a plik otwierający się z ostrzeżeniem o naprawie też nie jest sukcesem. Porównaj liczbę wierszy i jedną znaną wartość z raportem na ekranie, bo obcięty eksport przechodzi każdy test, który patrzy tylko na rozmiar pliku. Potem wyeksportuj drugi raz, bo warstwa pamięci podręcznej, która raz podała złą treść, może następnym razem podać właściwą.

Zaakceptuj przepływ pracy, którego potrzebował użytkownik, i nic mniej. Pobranie, które otwiera się w niewłaściwej aplikacji, nadal jest nieudanym eksportem.