SSRS-eksport fejler gennem en klientløs VPN-portal: hvad der er anderledes

Rapporten åbner i browseren, parametrene gengives, og eksportknappen giver en fejl, en tom download eller en fil, som regnearket nægter at åbne. Den kombination har en standardform. En fungerende rapportside har testet gengivelse og godkendelse og intet andet. Eksporten er en separat anmodning med sit eget svar, og gennem en klientløs portal passerer den også et omskrivningslag, som aldrig blev designet til fil-downloads.

To veje, én fungerende side

Gengivelse og eksport er forskellige operationer, selv når de starter fra den samme knap. Rapportserveren gengiver siden til en browser og gengiver eksporten gennem en anden outputudvidelse med sin egen indholdstype og sin egen fejladfærd, som eksportdokumentationen beskriver. En portal, der sender den første perfekt igennem, kan stadig ødelægge den anden, fordi den anden er et svar, som portalen ikke forventede at se. De to deler en session og en adresse og næsten intet andet.

Behandl den fungerende side som bevis for godkendelse og tilgængelighed alene. Den beviser, at kontoen kan nå rapportserveren, og at portalen videresender HTML. Den siger intet om filsvar, headere for indholdsplacering eller omdirigeringer, der ender i en download i stedet for i et dokument.

Det er den eneste grund til at sammenligne eksportvejen for sig selv i stedet for at teste den side, der allerede virker, igen. To anmodninger, der deler en session, er stadig to anmodninger.

Tre betingelser, der afgør, hvor eksporten knækker

Tre spørgsmål placerer fejlen hurtigt, og hvert svar peger på en forskellig ejer.

For det første, eksporteres den samme rapport, konto og det samme format korrekt fra det interne netværk? Hvis ja, er rapportserveren og dens renderer i orden, og forskellen ligger i adgangsvejen. For det andet, bærer det fejlende svar en filindholdstype, eller en HTML-side med en filendelse? Det adskiller en rendererfejl fra en substitution foretaget af portalen. For det tredje, omskriver portalen anmodningens URL eller fjerner headere fra svaret? En omskrevet URL kan lande på et helt andet endepunkt.

Besvar alle tre, før du ændrer en indstilling, fordi hver har en forskellig afhjælpning. En rendererfejl hører til rapportserveren, en substitueret body hører til portalen, og en fjernet header er et politikspørgsmål og ikke en fejl.

Skriv svarene ned. En supportsag bygget på de tre linjer er ti skærmbilleder værd.

Læs eksportsvaret i stedet for statuskoden

Et HTTP-successtatus beviser kun, at noget besvarede anmodningen. Undersøg body og headere sammen, fordi den interessante fejl er et vellykket svar med det forkerte indhold.

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

Header-dumpet viser indholdstypen og enhver indholdsplacering, som portalen returnerede. Kommandoen file identificerer, hvad body faktisk er, og en tekstfil, hvor et regneark var forventet, er den klassiske substituerede login-side. Kommandoen head viser nok til at genkende HTML uden at dumpe en hel rapport i en terminal.

Fjern sessionscookies og tokens, før du deler noget af det. En optagelse af en fungerende eksport er nyttigt bevis, og en optagelse af en session, der tilhører en anden, er en hændelse.

Afgræns undtagelsen til applikationen, ikke kontoen

Hvis portalen omskriver eller blokerer svaret, er den fristende reparation at fritage hele webstedet eller gøre rapporten anonym. Begge retter downloadet og fjerner grunden til, at portalen findes. En afgrænset undtagelse navngiver én applikationssti, én indholdstype og én retning, og den forbliver gennemgåelig for den, der ejer politikken.

Brug den gateway-version, du faktisk kører, og dens dokumenterede applikationsindstillinger. En mulighed, som en leverandør engang beskrev som at lade trafikken være uændret, er ikke en generel instruktion, og at kopiere den fra en gammel forumtråd er, hvordan en midlertidig undtagelse bliver permanent arkitektur.

Hvis undtagelsen ikke kan afgrænses så snævert, hører eksporten sandsynligvis til den interne vej med en anden adgangsmetode i stedet for bag portalen. En fritagelse for hele webstedet er en beslutning for portalejeren, ikke en omvej for én rapport.

Accepter eksporten, ikke Gem-dialogen

Den sidste kontrol er selve filen: den åbner, den indeholder de forventede kolonner, og dens totaler stemmer med den rapport, som brugeren godkendte.

At en Gem-dialog vises, er ikke succes, og en fil, der åbner med en reparationsadvarsel, er heller ikke succes. Sammenlign et rækkeantal og én kendt værdi med rapporten på skærmen, fordi en afkortet eksport består enhver test, der kun ser på filstørrelse. Eksporter derefter en anden gang, fordi et cachelag, der én gang leverer den forkerte body, måske leverer den rigtige ved næste forsøg.

Accepter den arbejdsgang, brugeren havde brug for, og intet mindre. En download, der åbner i det forkerte program, er stadig en mislykket eksport.