L’esportazione di SSRS fallisce attraverso un portale VPN senza client: cosa cambia

Il report si apre nel browser, i parametri vengono renderizzati e il pulsante di esportazione produce un errore, un download vuoto o un file che il foglio di calcolo rifiuta di aprire. Questa combinazione ha una forma standard. Una pagina di report funzionante ha testato il rendering e l’autenticazione, e nient’altro. L’esportazione è una richiesta separata con la propria risposta, e attraverso un portale senza client attraversa anche uno strato di riscrittura che non è mai stato progettato per i download di file.

Due percorsi, una pagina che funziona

Rendering ed esportazione sono operazioni diverse anche quando partono dallo stesso pulsante. Il server dei report esegue il rendering della pagina per un browser e prepara l’esportazione tramite un’altra estensione di output con il proprio tipo di contenuto e il proprio comportamento in caso di errore, come descrive la documentazione di esportazione. Un portale che lascia passare perfettamente la prima può comunque rovinare la seconda, perché la seconda è una risposta che il portale non si aspettava di vedere. Le due condividono una sessione e un indirizzo, e quasi nient’altro.

Trattate la pagina funzionante solo come prova di autenticazione e raggiungibilità. Dimostra che l’account può raggiungere il server dei report e che il portale inoltra HTML. Non dice nulla sulle risposte di file, sulle intestazioni di disposizione del contenuto o sui reindirizzamenti che finiscono in un download anziché in un documento.

È l’intero motivo per confrontare il percorso di esportazione separatamente invece di ritestare la pagina che già funziona. Due richieste che condividono una sessione restano due richieste.

Tre condizioni che decidono dove si rompe l’esportazione

Tre domande collocano rapidamente il guasto, e ogni risposta indica un proprietario diverso.

Primo, lo stesso report, lo stesso account e lo stesso formato si esportano correttamente dalla rete interna? Se sì, il server dei report e il suo motore di rendering stanno bene e la differenza è nel percorso di accesso. Secondo, la risposta fallita porta un tipo di contenuto di file, o una pagina HTML con un’estensione di file? Questo separa un errore del motore di rendering da una sostituzione del portale. Terzo, il portale riscrive l’URL della richiesta o rimuove intestazioni dalla risposta? Un URL riscritto può finire su un endpoint completamente diverso.

Rispondete a tutte e tre prima di cambiare un’impostazione, perché ciascuna ha un rimedio diverso. Un guasto del motore di rendering appartiene al server dei report, un corpo sostituito appartiene al portale, e un’intestazione rimossa è una questione di policy, non un bug.

Annotate le risposte. Un caso di supporto costruito su quelle tre righe vale dieci screenshot.

Leggete la risposta di esportazione invece del codice di stato

Uno stato HTTP riuscito dimostra solo che qualcosa ha risposto alla richiesta. Ispezionate il corpo e le intestazioni insieme, perché il guasto interessante è una risposta riuscita che porta il contenuto sbagliato.

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

Il dump delle intestazioni mostra il tipo di contenuto e qualsiasi disposizione del contenuto restituita dal portale. Il comando file identifica che cosa è realmente il corpo, e un file di testo dove ci si aspettava un foglio di calcolo è la classica pagina di accesso sostituita. Il comando head mostra abbastanza per riconoscere l’HTML senza scaricare un intero report in un terminale.

Rimuovete i cookie di sessione e i token prima di condividere qualsiasi parte. Una cattura di un’esportazione funzionante è una prova utile, e una cattura di una sessione che appartiene a qualcun altro è un incidente.

Limitate l’eccezione all’applicazione, non all’account

Se il portale riscrive o blocca la risposta, la riparazione tentatrice è esentare l’intero sito o rendere il report anonimo. Entrambe correggono il download e rimuovono la ragione per cui il portale esiste. Un’eccezione mirata nomina un percorso applicativo, un tipo di contenuto e una direzione, e resta riesaminabile da chi possiede la policy.

Usate la versione del gateway che eseguite davvero e le sue impostazioni applicative documentate. Un’opzione che un fornitore una volta ha descritto come lasciare il traffico invariato non è un’istruzione generale, e copiarla da un vecchio thread del forum è il modo in cui un’eccezione temporanea diventa architettura permanente.

Se l’eccezione non può essere limitata così strettamente, l’esportazione appartiene probabilmente al percorso interno con un metodo di accesso diverso invece che dietro il portale. Un’esenzione per l’intero sito è una decisione del proprietario del portale, non un aggiramento per un report.

Accettate l’esportazione, non la finestra Salva

L’ultima verifica è il file stesso: si apre, contiene le colonne attese e i suoi totali corrispondono al report che l’utente ha approvato.

La comparsa di una finestra Salva non è un successo, e un file che si apre con un avviso di riparazione non lo è neppure. Confrontate un conteggio di righe e un valore noto con il report sullo schermo, perché un’esportazione troncata supera ogni test che guarda solo la dimensione del file. Poi esportate una seconda volta, perché uno strato di cache che una volta serve il corpo sbagliato può servire quello giusto al tentativo successivo.

Accettate il flusso di lavoro di cui l’utente aveva bisogno, e nulla di meno. Un download che si apre nell’applicazione sbagliata resta un’esportazione fallita.