شکست خروجی 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 را تشخیص دهید بدون ریختن یک گزارش کامل در پایانه.
کوکی‌های نشست و نشانه‌ها را پیش از به اشتراک گذاشتن هر بخشی از آن حذف کنید. ضبط یک خروجی سالم شاهد سودمندی است، و ضبط نشستی که به کس دیگری تعلق دارد یک رخداد است.
استثنا را به برنامه محدود کنید، نه به حساب
اگر درگاه پاسخ را بازنویسی یا مسدود می‌کند، تعمیر وسوسه‌انگیز معاف کردن کل سایت یا ناشناس کردن گزارش است. هر دو دانلود را درست می‌کنند و دلیل وجود درگاه را برمی‌دارند. استثنای محدود یک مسیر برنامه، یک نوع محتوا و یک جهت را نام می‌برد، و برای کسی که سیاست را در اختیار دارد قابل بازبینی می‌ماند.
از نسخه دروازه‌ای که واقعاً اجرا می‌کنید و تنظیمات برنامه مستندش استفاده کنید. گزینه‌ای که فروشنده‌ای زمانی آن را بی‌تغییر گذاشتن ترافیک توصیف کرد دستورالعمل عمومی نیست، و کپی کردنش از یک رشته انجمن قدیمی راهی است که یک استثنای موقت به معماری دائمی تبدیل شود.
اگر استثنا را نمی‌توان این‌قدر تنگ محدود کرد، خروجی احتمالاً به مسیر داخلی با روش دسترسی متفاوت تعلق دارد نه پشت درگاه. معافیت کل سایت تصمیمی برای مالک درگاه است، نه راه‌حل دورزننده برای یک گزارش.
خروجی را بپذیرید، نه کادر ذخیره را
آخرین بررسی خود فایل است: باز می‌شود، ستون‌های مورد انتظار را دارد، و جمع‌هایش با گزارشی که کاربر تأیید کرده مطابقت دارد.
ظاهر شدن کادر ذخیره موفقیت نیست، و فایلی که با هشدار تعمیر باز می‌شود هم موفقیت نیست. تعداد سطر و یک مقدار شناخته‌شده را با گزارش روی صفحه مقایسه کنید، چون خروجی بریده از هر آزمونی که فقط به اندازه فایل نگاه می‌کند می‌گذرد. سپس بار دوم خروجی بگیرید، چون لایه کشی که یک بار بدنه نادرست را سرو می‌کند ممکن است در تلاش بعدی درست را سرو کند.
گردش کاری را که کاربر لازم داشت بپذیرید، و نه کمتر از آن. دانلودی که در برنامه نادرست باز می‌شود هنوز خروجی ناموفق است.