การส่งออก SSRS ล้มเหลวผ่านพอร์ทัล VPN ที่ไม่มีไคลเอนต์: อะไรที่ต่างออกไป

รายงานเปิดในเบราว์เซอร์ พารามิเตอร์ถูกเรนเดอร์ และปุ่มส่งออกสร้างข้อผิดพลาด การดาวน์โหลดว่างเปล่า หรือไฟล์ที่สเปรดชีตปฏิเสธที่จะเปิด การผสมกันนั้นมีรูปแบบมาตรฐาน หน้าแรปพอร์ตที่ใช้งานได้ทดสอบการเรนเดอร์และการยืนยันตัวตนเท่านั้น ไม่มีอย่างอื่น การส่งออกเป็นคำขอแยกต่างหากที่มีการตอบสนองของตัวเอง และผ่านพอร์ทัลที่ไม่มีไคลเอนต์ มันยังผ่านชั้นการเขียนใหม่ที่ไม่เคยออกแบบมาสำหรับการดาวน์โหลดไฟล์

สองเส้นทาง หนึ่งหน้าที่ใช้งานได้

การเรนเดอร์และการส่งออกเป็นการดำเนินการที่ต่างกัน แม้จะเริ่มจากปุ่มเดียวกัน เซิร์ฟเวอร์รายงานเรนเดอร์หน้าสำหรับเบราว์เซอร์ และเรนเดอร์การส่งออกผ่านส่วนขยายเอาต์พุตอื่นที่มีชนิดเนื้อหาของตัวเองและพฤติกรรมข้อผิดพลาดของตัวเอง ตามที่ เอกสารการส่งออก อธิบาย พอร์ทัลที่ปล่อยอันแรกผ่านอย่างสมบูรณ์แบบยังคงทำให้อันที่สองเสียหายได้ เพราะอันที่สองคือการตอบสนองที่พอร์ทัลไม่ได้คาดว่าจะเห็น ทั้งสองใช้เซสชันและที่อยู่ร่วมกัน และแทบไม่มีอย่างอื่น

ถือว่าหน้าที่ใช้งานได้เป็นหลักฐานของการยืนยันตัวตนและการเข้าถึงเท่านั้น มันพิสูจน์ว่าบัญชีเข้าถึงเซิร์ฟเวอร์รายงานได้และพอร์ทัลส่งต่อ HTML มันไม่ได้บอกอะไรเกี่ยวกับการตอบสนองไฟล์ เฮดเดอร์การจัดวางเนื้อหา หรือการเปลี่ยนเส้นทางที่จบด้วยการดาวน์โหลดแทนที่จะเป็นเอกสาร

นั่นคือเหตุผลทั้งหมดที่ต้องเปรียบเทียบเส้นทางการส่งออกแยกต่างหาก แทนที่จะทดสอบหน้าทำงานได้อีกครั้ง คำขอสองรายการที่ใช้เซสชันร่วมกันยังคงเป็นสองคำขอ

สามเงื่อนไขที่ตัดสินว่าการส่งออกพังตรงไหน

สามคำถามระบุตำแหน่งของปัญหาได้อย่างรวดเร็ว และแต่ละคำตอบชี้ไปยังเจ้าของที่แตกต่างกัน

ประการแรก รายงาน บัญชี และรูปแบบเดียวกันส่งออกจากเครือข่ายภายในได้ถูกต้องหรือไม่ ถ้าใช่ เซิร์ฟเวอร์รายงานและตัวเรนเดอร์อยู่ในสภาพดี และความแตกต่างอยู่ที่เส้นทางการเข้าถึง ประการที่สอง การตอบสนองที่ล้มเหลวมีชนิดเนื้อหาไฟล์ หรือหน้า HTML ที่สวมนามสกุลไฟล์หรือไม่ นั่นแยกข้อผิดพลาดของตัวเรนเดอร์ออกจากการแทนที่โดยพอร์ทัล ประการที่สาม พอร์ทัลเขียน URL ของคำขอใหม่หรือลบเฮดเดอร์ออกจากการตอบสนองหรือไม่ URL ที่เขียนใหม่สามารถลงเอยที่ปลายทางที่แตกต่างกันโดยสิ้นเชิง

ตอบทั้งสามข้อก่อนเปลี่ยนการตั้งค่าใด ๆ เพราะแต่ละข้อมีวิธีแก้ที่ต่างกัน ข้อผิดพลาดของตัวเรนเดอร์เป็นของเซิร์ฟเวอร์รายงาน บอดี้ที่ถูกแทนที่เป็นของพอร์ทัล และเฮดเดอร์ที่ถูกลบเป็นคำถามเชิงนโยบายไม่ใช่บั๊ก

เขียนคำตอบลงไป เคสสนับสนุนที่สร้างจากสามบรรทัดนั้นมีค่าเท่ากับภาพหน้าจอสิบภาพ

อ่านการตอบสนองการส่งออกแทนรหัสสถานะ

สถานะ HTTP ที่สำเร็จพิสูจน์เพียงว่ามีบางสิ่งตอบคำขอ ตรวจสอบบอดี้และเฮดเดอร์ร่วมกัน เพราะความล้มเหลวที่น่าสนใจคือการตอบสนองที่สำเร็จซึ่งนำเนื้อหาที่ผิดมา

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

การดัมพ์เฮดเดอร์แสดงชนิดเนื้อหาและการจัดวางเนื้อหาใด ๆ ที่พอร์ทัลส่งกลับ คำสั่ง file ระบุว่าบอดี้คืออะไรจริง ๆ และไฟล์ข้อความในที่ที่คาดว่าควรเป็นสเปรดชีตคือหน้าเข้าสู่ระบบที่ถูกแทนที่แบบคลาสสิก คำสั่ง head แสดงข้อมูลเพียงพอที่จะจดจำ HTML โดยไม่ต้องเทรายงานทั้งฉบับลงในเทอร์มินัล

ลบคุกกี้เซสชันและโทเคนก่อนแชร์ส่วนใด ๆ ของมัน การบันทึกการส่งออกที่ใช้งานได้เป็นหลักฐานที่มีประโยชน์ และการบันทึกเซสชันของคนอื่นเป็นเหตุการณ์

จำกัดข้อยกเว้นที่แอปพลิเคชัน ไม่ใช่ที่บัญชี

หากพอร์ทัลเขียนหรือบล็อกการตอบสนอง การซ่อมที่ล่อใจคือการยกเว้นทั้งไซต์หรือทำให้รายงานไม่ระบุตัวตน ทั้งสองอย่างแก้การดาวน์โหลดและลบเหตุผลที่พอร์ทัลมีอยู่ ข้อยกเว้นที่จำกัดระบุเส้นทางแอปพลิเคชันหนึ่ง ชนิดเนื้อหาหนึ่ง และทิศทางหนึ่ง และยังคงตรวจสอบได้โดยผู้ที่เป็นเจ้าของนโยบาย

ใช้เวอร์ชันเกตเวย์ที่คุณใช้งานจริงและการตั้งค่าแอปพลิเคชันที่มีเอกสารกำกับ ตัวเลือกที่ผู้ขายเคยอธิบายว่าปล่อยทราฟฟิกไว้ไม่เปลี่ยนแปลงไม่ใช่คำแนะนำทั่วไป และการคัดลอกจากกระทู้ฟอรัมเก่า ๆ คือหนทางที่ข้อยกเว้นชั่วคราวกลายเป็นสถาปัตยกรรมถาวร

หากข้อยกเว้นไม่สามารถจำกัดให้แคบขนาดนั้นได้ การส่งออกน่าจะอยู่ในเส้นทางภายในด้วยวิธีเข้าถึงอื่นแทนที่จะอยู่หลังพอร์ทัล การยกเว้นทั้งไซต์เป็นการตัดสินใจของเจ้าของพอร์ทัล ไม่ใช่ทางอ้อมสำหรับรายงานเดียว

ยอมรับการส่งออก ไม่ใช่กล่องบันทึก

การตรวจสอบสุดท้ายคือไฟล์เอง มันเปิดได้ มีคอลัมน์ที่คาดไว้ และยอดรวมตรงกับรายงานที่ผู้ใช้อนุมัติ

การปรากฏของกล่องบันทึกไม่ใช่ความสำเร็จ และไฟล์ที่เปิดพร้อมคำเตือนการซ่อมก็ไม่ใช่ความสำเร็จเช่นกัน เปรียบเทียบจำนวนแถวและค่าที่รู้จักหนึ่งค่ากับรายงานบนหน้าจอ เพราะการส่งออกที่ถูกตัดทอนผ่านทุกการทดสอบที่ดูแค่ขนาดไฟล์ จากนั้นส่งออกอีกครั้ง เพราะชั้นแคชที่ให้บอดี้ผิดครั้งหนึ่งอาจให้บอดี้ที่ถูกในการลองครั้งถัดไป

ยอมรับเวิร์กโฟลว์ที่ผู้ใช้ต้องการ และไม่น้อยกว่านั้น การดาวน์โหลดที่เปิดในแอปพลิเคชันผิดยังคงเป็นการส่งออกที่ล้มเหลว