Πρόσβαση μέσω πύλης APM: σε ποιον ανήκει η συνεδρία της εφαρμογής;
Πέντε έλεγχοι για μια απόφαση δημοσίευσης με BIG-IP Portal Access: εύρος πόρου, συνεδρία backend, δύο χρονόμετρα, έννοια αποσύνδεσης και όρια της επανεγγραφής.
Η δημοσίευση μιας εφαρμογής intranet μέσω BIG-IP APM Portal Access είναι απόφαση για συνεδρίες, όχι για αντιγραφή ενός εικονικού διακομιστή. Η πύλη δέχεται τον χρήστη, το προφίλ επανεγγραφής κρατά επιλεγμένα αιτήματα στη διαδρομή της πύλης και η εφαρμογή εξακολουθεί να έχει τη δική της συνεδρία. Πέντε έλεγχοι χωρίζουν ένα σχέδιο που συμπεριφέρεται προβλέψιμα από ένα όπου η υπηρεσία υποστήριξης μαθαίνει για τα timeouts χρήστη-χρήστη. Εκτελέστε τους με σειρά και σταματήστε στον πρώτο που δεν ισχύει.
Έλεγχος 1: ο πόρος δημοσιεύεται, δεν συνδέεται απλώς
Ένας σελιδοδείκτης στο webtop αποδεικνύει ότι ο χρήστης βλέπει μια καταχώριση. Δεν αποδεικνύει ότι η εφαρμογή έχει δημοσιευτεί. Αναζητήστε το προφίλ πρόσβασης, το προφίλ επανεγγραφής και τον εικονικό διακομιστή που τα συνδυάζει, και επιβεβαιώστε ότι η ανάθεση πόρου δείχνει στην εφαρμογή που νομίζετε. Αν λείπει ή είναι ασυνεπές ένα από τα τρία, η υπόλοιπη λίστα είναι άνευ σημασίας.
Η μισοδημοσιευμένη περίπτωση φαίνεται υγιής στο σημείο εισόδου. Ο εικονικός διακομιστής φέρει το προφίλ πρόσβασης, ενώ το προφίλ επανεγγραφής περιορίζεται σε άλλο resource URI, οπότε η καταχώριση webtop εμφανίζεται και η πρώτη σελίδα φορτώνει, έπειτα τα αιτήματα της υποδιαδρομής εγκαταλείπουν τη διαδρομή της πύλης και φτάνουν στο backend απευθείας. Το κατοπτρικό είδωλο είναι πόρος ανατεθειμένος σε λάθος εφαρμογή: ο σελιδοδείκτης ανοίγει και ανοίγει κάτι που κανείς δεν ενέκρινε.
Έλεγχος 2: η συνεδρία του backend είναι ξεχωριστή κατάσταση
Το backend μπορεί να απαιτεί δική του αυθεντικοποίηση ακόμη και όταν το APM θεωρεί τον χρήστη συνδεδεμένο. Η υποστηριζόμενη ενσωμάτωση SSO καθορίζει αυτή τη σχέση για εσάς, αλλά η αποδοχή της σύνδεσης στην πύλη δεν κάνει κάθε εφαρμογή να δέχεται τα ίδια διαπιστευτήρια ή το ίδιο cookie συνεδρίας. Αν το SSO δεν έχει ρυθμιστεί για τον πόρο, η εφαρμογή θα ζητήσει τη δική της σύνδεση μέσα σε μια ήδη αυθεντικοποιημένη πύλη.
Η απενεργοποίηση του SSO για να αλλάξει το ορατό μήνυμα είναι κοινή και κακή συντόμευση: αλλάζει τον σχεδιασμό αυθεντικοποίησης χωρίς να αγγίξει τον κύκλο ζωής που παρήγαγε το μήνυμα. Αποφασίστε αντ' αυτού αν η σύνδεση στο backend πρέπει να εμφανίζεται καθόλου, και αν πρέπει, κάντε την ρητό μέρος της δημοσιευμένης ροής.
Έλεγχος 3: υπάρχουν δύο ρολόγια και δεν είναι το ίδιο ρολόι
Το προφίλ πρόσβασης του APM φέρει timeout αδράνειας και μέγιστη διάρκεια ζωής συνεδρίας. Η εφαρμογή φέρει το δικό της χρονόμετρο αδράνειας και τη λήξη του 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 είναι το έγγραφο που πρέπει να διαβάσετε πριν δεσμευτείτε, γιατί τα όρια εξαρτώνται από την έκδοση.
Δοκιμάστε τις ροές που μετράνε και όχι τη σελίδα υποδοχής: συνδεθείτε, πλοηγηθείτε σε κάθε απαιτούμενη λειτουργία, μεταφορτώστε αν η εφαρμογή μεταφορτώνει, αφήστε τη σκοπούμενη συνεδρία να λήξει και ακολουθήστε κάθε διαδρομή αποσύνδεσης. Μια σελίδα που αποδίδεται μία φορά δεν είναι απόδειξη ότι η εφαρμογή λειτουργεί.
Όταν μια απαιτούμενη ροή δεν μπορεί να επανεγγραφεί, μεταβείτε σε τεκμηριωμένο σχέδιο ομοσπονδίας, αντίστροφου διακομιστή μεσολάβησης ή πρόσβασης δικτύου. Μια πύλη προγράμματος περιήγησης που της ζητείται να συμπεριφέρεται σαν γενική σήραγγα θα περάσει το demo και θα αποτύχει στον έλεγχο.