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-ის ამოსაცნობად მთელი ანგარიშის ტერმინალში გადაყრის გარეშე.

წაშალეთ სესიის ქუქიები და ტოკენები, სანამ რომელიმე ნაწილს გააზიარებთ. მუშა ექსპორტის ჩანაწერი სასარგებლო მტკიცებულებაა, ხოლო სხვისი სესიის ჩანაწერი ინციდენტია.

შემოსაზღვრეთ გამონაკლისი აპლიკაციით და არა ანგარიშით

თუ პორტალი პასუხს გადაწერს ან ბლოკავს, მაცდური შესწორებაა მთელი საიტის გამოქვეყნება ან ანგარიშის ანონიმურად გახდომა. ორივე ასწორებს ჩამოტვირთვას და აშორებს პორტალის არსებობის მიზეზს. შემოსაზღვრული გამონაკლისი ასახელებს ერთ აპლიკაციის გზას, ერთ შიგთავსის ტიპს და ერთ მიმართულებას და რჩება განსახილველად მას, ვინც პოლიტიკას ფლობს.

გამოიყენეთ ის კარიბჭის ვერსია, რომელსაც რეალურად ამუშავებთ, და მისი დოკუმენტირებული აპლიკაციის პარამეტრები. ვარიანტი, რომელიც მომწოდებელმა ერთხელ აღწერა როგორც ტრაფიკის უცვლელად დატოვება, ზოგადი ინსტრუქცია არ არის, და მისი ძველი ფორუმის თემიდან კოპირება ის გზაა, რომლითაც დროებითი გამონაკლისი მუდმივ არქიტექტურად იქცევა.

თუ გამონაკლისს ასე ვიწროდ ვერ შემოვსაზღვრავთ, ექსპორტი ალბათ შიდა გზას ეკუთვნის სხვა წვდომის მეთოდით და არა პორტალის უკან. მთელი საიტის გამოკვლევა პორტალის მფლობელის გადაწყვეტილებაა და არა ერთი ანგარიშის გვერდულად გავლა.

მიიღეთ ექსპორტი და არა შენახვის დიალოგი

ბოლო შემოწმება თავად ფაილია: ის იხსნება, შეიცავს მოსალოდნელ სვეტებს და მისი ჯამები ემთხვევა იმ ანგარიშს, რომელიც მომხმარებელმა დაამტკიცა.

შენახვის დიალოგის გამოჩენა წარმატება არ არის, და შეკეთების გაფრთხილებით გახსნილი ფაილიც წარმატება არ არის. შეადარეთ მწკრივების რაოდენობა და ერთი ცნობილი მნიშვნელობა ეკრანზე არსებულ ანგარიშს, რადგან შეკვეცილი ექსპორტი გადის ყველა ტესტს, რომელიც მხოლოდ ფაილის ზომას უყურებს. შემდეგ კიდევ ერთხელ გააკეთეთ ექსპორტი, რადგან ქეშის შრემ, რომელმაც ერთხელ არასწორი სხეული მოგვაწოდა, შეიძლება შემდეგ ცდაზე სწორი მოგვაწოდოს.

მიიღეთ ის სამუშაო პროცესი, რომელიც მომხმარებელს სჭირდებოდა და არანაკლები. არასწორ აპლიკაციაში გახსნილი ჩამოტვირთვა მაინც წარუმატებელი ექსპორტია.