SSRS-export misslyckas via en klientlös VPN-portal: vad som skiljer sig

Rapporten öppnas i webbläsaren, parametrarna renderas och exportknappen ger ett fel, en tom nedladdning eller en fil som kalkylarket vägrar öppna. Den kombinationen har en standardform. En fungerande rapportsida har testat rendering och autentisering och inget annat. Exporten är en separat begäran med sitt eget svar, och genom en klientlös portal passerar den också ett omskrivningslager som aldrig konstruerades för filnedladdningar.

Två vägar, en fungerande sida

Rendering och export är olika operationer även när de börjar från samma knapp. Rapportservern renderar sidan för en webbläsare och renderar exporten genom ett annat utdata-tillägg med egen innehållstyp och eget felbeteende, som exportdokumentationen beskriver. En portal som släpper igenom den första perfekt kan fortfarande fördärva den andra, eftersom den andra är ett svar som portalen inte förväntade sig se. De två delar en session och en adress, och nästan inget annat.

Behandla den fungerande sidan bara som bevis på autentisering och nåbarhet. Den bevisar att kontot kan nå rapportservern och att portalen vidarebefordrar HTML. Den säger inget om filsvar, rubriker för innehållsplacering eller omdirigeringar som slutar i en nedladdning i stället för i ett dokument.

Det är hela skälet att jämföra exportvägen för sig i stället för att testa sidan som redan fungerar igen. Två begäranden som delar en session är fortfarande två begäranden.

Tre villkor som avgör var exporten bryts

Tre frågor placerar felet snabbt, och varje svar pekar på en annan ägare.

För det första, exporteras samma rapport, konto och format korrekt från det interna nätet? Om ja är rapportservern och dess renderare i ordning och skillnaden ligger i åtkomstvägen. För det andra, bär det misslyckade svaret en filinnehållstyp, eller en HTML-sida med en filändelse? Det skiljer ett renderarfel från en ersättning från portalen. För det tredje, skriver portalen om begärans URL eller tar den bort rubriker från svaret? En omskriven URL kan landa på en helt annan slutpunkt.

Svara på alla tre innan du ändrar en inställning, eftersom var och en har en egen åtgärd. Ett renderarfel hör till rapportservern, en ersatt brödtext hör till portalen, och en borttagen rubrik är en policyfråga och inte en bugg.

Skriv ned svaren. Ett supportärende byggt på de tre raderna är värt tio skärmbilder.

Läs exportsvaret i stället för statuskoden

En lyckad HTTP-status bevisar bara att något besvarade begäran. Granska brödtexten och rubrikerna tillsammans, eftersom det intressanta felet är ett lyckat svar med fel innehåll.

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

Rubrikdumpen visar innehållstypen och varje innehållsplacering som portalen returnerade. Kommandot file identifierar vad brödtexten faktiskt är, och en textfil där ett kalkylark förväntades är den klassiska ersatta inloggningssidan. Kommandot head visar tillräckligt för att känna igen HTML utan att dumpa en hel rapport i en terminal.

Ta bort sessionscookies och tokens innan du delar något av det. En inspelning av en fungerande export är användbart bevis, och en inspelning av en session som tillhör någon annan är en incident.

Avgränsa undantaget till applikationen, inte kontot

Om portalen skriver om eller blockerar svaret är den frestande reparationen att undanta hela webbplatsen eller göra rapporten anonym. Båda åtgärdar nedladdningen och tar bort skälet till att portalen finns. Ett snävt undantag namnger en applikationsväg, en innehållstyp och en riktning, och det förblir granskningsbart för den som äger policyn.

Använd den gateway-version du faktiskt kör och dess dokumenterade applikationsinställningar. Ett alternativ som en leverantör en gång beskrev som att lämna trafiken oförändrad är ingen allmän instruktion, och att kopiera det från en gammal forumtråd är hur ett tillfälligt undantag blir permanent arkitektur.

Om undantaget inte kan avgränsas så snävt hör exporten förmodligen till den interna vägen med en annan åtkomstmetod i stället för bakom portalen. Ett undantag för hela webbplatsen är ett beslut för portalägaren, inte en omväg för en rapport.

Acceptera exporten, inte Spara-dialogen

Den sista kontrollen är filen själv: den öppnas, den innehåller de förväntade kolumnerna och summan stämmer med rapporten som användaren godkände.

Att en Spara-dialog visas är inte framgång, och en fil som öppnas med en reparationsvarning är inte heller framgång. Jämför ett radantal och ett känt värde med rapporten på skärmen, eftersom en avkortad export klarar varje test som bara tittar på filstorleken. Exportera sedan en gång till, eftersom ett cachelager som en gång levererar fel brödtext kanske levererar den rätta vid nästa försök.

Acceptera arbetsflödet som användaren behövde, och inget mindre. En nedladdning som öppnas i fel applikation är fortfarande en misslyckad export.