წვდომა APM პორტალით: ვის ეკუთვნის აპლიკაციის სესია?
ხუთი შემოწმება BIG-IP Portal Access-ით გამოქვეყნების გადაწყვეტილებისთვის: რესურსის ფარგლები, backend-ის სესია, ორი ტაიმერი, გასვლის მნიშვნელობა და გადაწერის საზღვრები.
ინტრანეტის აპლიკაციის გამოქვეყნება BIG-IP APM Portal Access-ით სესიებზე მიღებული გადაწყვეტილებაა და არა ვირტუალური სერვერის კოპირება. პორტალი ატარებს მომხმარებელს შიგნით, გადაწერის პროფილი შერჩეულ მოთხოვნებს კარიბჭის გზაზე ინახავს, ხოლო აპლიკაციას კვლავ საკუთარი სესია აქვს. ხუთი შემოწმება ჰყოფს პროგნოზირებად ქცევის დიზაინს იმისგან, სადაც დახმარების სამსახური ტაიმაუტებზე მომხმარებელ-მომხმარებელ იგებს. შეასრულეთ ისინი რიგით და შეჩერდით პირველზე, რომელიც არ არის მართალი.
შემოწმება 1: რესურსი გამოქვეყნებულია და არა მხოლოდ დაკავშირებული
webtop-ის სანიშნე ამტკიცებს, რომ მომხმარებელი ხედავს ჩანაწერს. ის არ ამტკიცებს, რომ აპლიკაცია გამოქვეყნებულია. მოძებნეთ წვდომის პროფილი, გადაწერის პროფილი და ვირტუალური სერვერი, რომელიც მათ აერთიანებს, შემდეგ დაადასტურეთ, რომ რესურსის მინიჭება მიუთითებს იმ აპლიკაციაზე, რომელსაც ფიქრობთ. თუ ამ სამიდან რომელიმე აკლია ან შეუთავსებელია, დანარჩენი სია უაზროა.
ნახევრად გამოქვეყნებული შემთხვევა შესასვლელში ჯანსაღად გამოიყურება. ვირტუალური სერვერი წვდომის პროფილს ატარებს, ხოლო გადაწერის პროფილი სხვა რესურსის URI-ით შემოიფარგლება, ამიტომ webtop-ის ჩანაწერი ჩნდება და პირველი გვერდი იტვირთება, შემდეგ ქვეგზის მოთხოვნები კარიბჭის გზას ტოვებენ და backend-ს პირდაპირ აღწევენ. სარკისებური სურათი არასწორ აპლიკაციაზე მინიჭებული რესურსია: სანიშნე იხსნება და ხსნის იმას, რაც არავის დაუმტკიცებია.
შემოწმება 2: backend-ის სესია ცალკე მდგომარეობაა
backend-ს შეიძლება საკუთარი ავთენტიფიკაცია მოითხოვოს მაშინაც, როცა APM მომხმარებელს შესული მიაჩნია. მხარდაჭერილი SSO ინტეგრაცია ამ კავშირს თქვენთვის ამყარებს, მაგრამ პორტალში შესვლის მიღება არ ნიშნავს, რომ ყველა აპლიკაცია ერთსა და იმავე მონაცემებს ან იმავე სესიის cookie-ს მიიღებს. თუ რესურსისთვის SSO არ არის კონფიგურირებული, აპლიკაცია საკუთარ შესვლას მოითხოვს უკვე ავთენტიფიცირებულ პორტალში.
SSO-ს გამორთვა ხილული მინიშნების შესაცვლელად გავრცელებული და ცუდი მოკლე გზაა: ის ცვლის ავთენტიფიკაციის დიზაინს იმ სასიცოცხლო ციკლზე ხელის შეუხებლად, რომელმაც მინიშნება შექმნა. ნაცვლად ამისა გადაწყვიტეთ, საერთოდ უნდა გამოჩნდეს backend-ის შესვლა, და თუ უნდა, გახადეთ ის გამოქვეყნებული ნაკადის ცხადი ნაწილი.
შემოწმება 3: ორი საათია და ისინი ერთი საათი არ არის
APM-ის წვდომის პროფილი უმოქმედობის ტაიმაუტს და სესიის მაქსიმალურ ხანგრძლივობას ატარებს. აპლიკაცია საკუთარ უმოქმედობის ტაიმერს და cookie-ს ვადის გასვლას ატარებს. პორტალის ტაიმერის გაზრდა აპლიკაციის სესიას არ აგრძელებს, ხოლო აპლიკაციის სესიის შემოკლება მომხმარებელს პორტალიდან არ აგდებს.
| Timer | Owner | What it ends |
|---|---|---|
| Inactivity timeout | APM access profile | the portal session after idle time |
| Maximum lifetime | APM access profile | the portal session regardless of activity |
| Application cookie | Backend application | the application session inside a live portal |
კლასიკური დახმარების ზარი შეუთავსებელი წყვილიდან მოდის: პორტალი ჯერ კიდევ ძალაშია, აპლიკაციის სესია არა, და მომხმარებელი ხედავს შესვლის ფორმას, რომელიც თითქოს პორტალს ეწინააღმდეგება. ეს სწორი ქცევაა და არა გაუმართაობა, ხოლო გადაწყვეტა იმაშია, რომ აირჩიოთ, რომელი საათი უნდა გავიდეს ვადაში პირველი ამ აპლიკაციისთვის.
შემოწმება 4: გასვლას განსაზღვრული ფარგლები აქვს
ჩაწერეთ, რა უნდა დაასრულოს აპლიკაციის გასვლის ღილაკმა: მხოლოდ ის აპლიკაცია, მთელი APM სესია, თუ იდენტობის მომწოდებლის უფრო ფართო სესია. წვდომის პროფილი მხარს უჭერს გასვლის URI-ების სიას სურვილისამებრ დაყოვნებით, და სწორედ ასე აქცევთ აპლიკაციის გასვლას პორტალის სესიის დამამთავრებლად, როცა ეს არის მოთხოვნა. ამის გარეშე აპლიკაციის გასვლა პორტალს ცოცხლად ტოვებს და შემდეგი მოთხოვნა შეიძლება მომხმარებელი ჩუმად ისევ შეიყვანოს.
გაითვალისწინეთ გავლენა იმავე პორტალის სხვა რესურსებზე. თუ ერთი აპლიკაციიდან გასვლა კიდევ ექვსის სესიას ამთავრებს, მომხმარებლები ამას ხარვეზს უწოდებენ, თუ ქცევა წინასწარ არ იყო შეთანხმებული აპლიკაციის მფლობელთან. ჩანართის დახურვა და webtop-ზე დაბრუნება იმის მტკიცებულება არ არის, რომ რაღაც დასრულდა.
შემოწმება 5: აპლიკაცია გადაწერას გადაურჩება
Portal Access შერჩეულ ვებ-კონტენტს გადაწერს და გადაწერას საზღვრები აქვს. თანამედროვე კლიენტის მხარის ფუნქციები, ფონური პროცესები, ატვირთვის ნაკადები და ფედერაციული შესვლა შეიძლება გასცდეს იმას, რასაც კონკრეტული გამოშვება უმკლავდება. F5-ის ვერსიებით განსაზღვრული თავსებადობის მატრიცა ის დოკუმენტია, რომელიც ვალდებულების აღებამდე უნდა წაიკითხოთ, რადგან საზღვრები გამოშვებაზეა დამოკიდებული.
გამოსცადეთ მნიშვნელოვანი ნაკადები და არა სადესანტო გვერდი: შედით, გაიარეთ ყოველი საჭირო ფუნქცია, ატვირთეთ თუ აპლიკაცია ტვირთავს, მიეცით განზრახ სესიას ვადის გასვლის საშუალება და მიჰყევით გასვლის ყველა გზას. ერთხელ ნაჩვენები გვერდი იმის მტკიცებულება არ არის, რომ აპლიკაცია მუშაობს.
როცა საჭირო ნაკადის გადაწერა შეუძლებელია, გადადით დოკუმენტირებულ ფედერაციის, შებრუნებული პროქსის ან ქსელური წვდომის დიზაინზე. ბრაუზერის პორტალი, რომელსაც ზოგადი გვირაბივით ქცევას სთხოვენ, დემოს გაივლის და აუდიტში ჩავარდება.