L’export SSRS échoue via un portail VPN sans client : ce qui change

Le rapport s’ouvre dans le navigateur, les paramètres s’affichent et le bouton d’export produit une erreur, un téléchargement vide ou un fichier que le tableur refuse d’ouvrir. Cette combinaison a une forme standard. Une page de rapport qui fonctionne a testé le rendu et l’authentification, et rien d’autre. L’export est une requête distincte avec sa propre réponse, et à travers un portail sans client il traverse aussi une couche de réécriture qui n’a jamais été conçue pour les téléchargements de fichiers.

Deux chemins, une page qui fonctionne

Le rendu et l’export sont des opérations différentes même lorsqu’elles partent du même bouton. Le serveur de rapports rend la page pour un navigateur et rend l’export via une autre extension de sortie dotée de son propre type de contenu et de son propre comportement en cas d’erreur, comme le décrit la documentation d’export. Un portail qui laisse parfaitement passer la première peut encore abîmer la seconde, car la seconde est une réponse que le portail ne s’attendait pas à voir. Les deux partagent une session et une adresse, et presque rien d’autre.

Traitez la page qui fonctionne uniquement comme une preuve d’authentification et d’accessibilité. Elle prouve que le compte atteint le serveur de rapports et que le portail transmet le HTML. Elle ne dit rien sur les réponses de fichiers, les en-têtes de disposition du contenu ou les redirections qui finissent en téléchargement plutôt qu’en document.

C’est toute la raison de comparer le chemin d’export séparément au lieu de retester la page qui fonctionne déjà. Deux requêtes qui partagent une session restent deux requêtes.

Trois conditions qui décident où l’export casse

Trois questions situent la panne rapidement, et chaque réponse désigne un propriétaire différent.

Premièrement, le même rapport, le même compte et le même format s’exportent-ils correctement depuis le réseau interne ? Si oui, le serveur de rapports et son moteur de rendu vont bien et la différence est dans le chemin d’accès. Deuxièmement, la réponse en échec porte-t-elle un type de contenu de fichier, ou une page HTML portant une extension de fichier ? Cela sépare une erreur du moteur de rendu d’une substitution par le portail. Troisièmement, le portail réécrit-il l’URL de la requête ou retire-t-il des en-têtes de la réponse ? Une URL réécrite peut atterrir sur un point de terminaison complètement différent.

Répondez aux trois avant de changer un paramètre, car chacune a un remède différent. Une panne du moteur de rendu appartient au serveur de rapports, un corps substitué appartient au portail, et un en-tête retiré est une question de politique, pas un bug.

Notez les réponses. Un cas de support construit à partir de ces trois lignes vaut dix captures d’écran.

Lisez la réponse d’export plutôt que le code de statut

Un statut HTTP réussi prouve seulement que quelque chose a répondu à la requête. Inspectez le corps et les en-têtes ensemble, car la panne intéressante est une réponse réussie portant le mauvais contenu.

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

Le vidage des en-têtes montre le type de contenu et toute disposition de contenu renvoyée par le portail. La commande file identifie ce qu’est réellement le corps, et un fichier texte là où un tableur était attendu est la classique page de connexion substituée. La commande head montre assez pour reconnaître du HTML sans déverser un rapport entier dans un terminal.

Supprimez les cookies de session et les jetons avant de partager quoi que ce soit. Une capture d’un export qui fonctionne est une preuve utile, et une capture d’une session appartenant à quelqu’un d’autre est un incident.

Limitez l’exception à l’application, pas au compte

Si le portail réécrit ou bloque la réponse, la réparation tentante est d’exempter tout le site ou de rendre le rapport anonyme. Les deux corrigent le téléchargement et suppriment la raison d’être du portail. Une exception ciblée nomme un chemin d’application, un type de contenu et une direction, et elle reste révisable par celui qui possède la politique.

Utilisez la version de la passerelle que vous exploitez réellement et ses paramètres d’application documentés. Une option qu’un fournisseur a un jour décrite comme laissant le trafic inchangé n’est pas une instruction générale, et la copier depuis un vieux fil de forum est la façon dont une exception temporaire devient une architecture permanente.

Si l’exception ne peut pas être limitée aussi étroitement, l’export appartient probablement au chemin interne avec une autre méthode d’accès plutôt que derrière le portail. Une exemption pour tout le site est une décision du propriétaire du portail, pas un contournement pour un rapport.

Acceptez l’export, pas la boîte de dialogue Enregistrer

La dernière vérification est le fichier lui-même : il s’ouvre, il contient les colonnes attendues et ses totaux correspondent au rapport que l’utilisateur a validé.

L’apparition d’une boîte de dialogue Enregistrer n’est pas un succès, et un fichier qui s’ouvre avec un avertissement de réparation n’en est pas un non plus. Comparez un nombre de lignes et une valeur connue au rapport à l’écran, car un export tronqué passe tous les tests qui ne regardent que la taille du fichier. Exportez ensuite une seconde fois, car une couche de cache qui sert une fois le mauvais corps peut servir le bon à l’essai suivant.

Acceptez le flux de travail dont l’utilisateur avait besoin, et rien de moins. Un téléchargement qui s’ouvre dans la mauvaise application reste un export raté.