Прив язка проксі-сесії: один запит чи весь робочий процес?
Вирішіть, чи прив язка проксі стосується одного запиту, одного автентифікованого робочого процесу або довговічнішого облікового запису, перш ніж увімкнути автоматичну ротацію.
Вхід, переспрямування та завантаження звіту — це три запити. Для користувача вони одна задача. Ротація виходу між кожним запитом може ускладнити розуміння цієї задачі, навіть коли кожен проксі працює.
Почніть з визначення одиниці, якій належить маршрут. Вибір на рівні запиту підходить для незалежних операцій. Для цих публічних операцій безкоштовний список проксі пропонує кандидатів, коли публічні посередники дозволені; він не надає жодного договору про липку сесію. Вибір на рівні робочого процесу утримує пов язані кроки на навмисно обраному шляху, доки процес не завершиться або доки його не замінить визначене рішення про відновлення.
Cookie і прив язка проксі — це різні стани
Cookie застосунку належить до правил сесії сайту. Ідентифікатор липкої сесії постачальника, коли він пропонується, належить до його проксі-сервісу та задокументованої політики з єднання або облікового запису. Вони не стають одним налаштуванням лише тому, що обидва використовують слово сесія.
Звичайний посередник CONNECT не може прочитати зашифрований заголовок Cookie сайту і використати його як ключ маршрутизації. Якщо сервіс обіцяє поведінку на основі cookie, з ясуйте, який видимий інтерфейс несе цей cookie і чи завершується там TLS. Не припускайте, що приватний cookie сайту автоматично доступний тунельному шлюзу.
Ведіть невеликий запис робочого процесу: обрана кінцева точка, ідентифікатор сесії постачальника, якщо використовується, ідентифікатор сесії застосунку та умова, що завершує прив язку. Уникайте розміщення секретів облікового запису у звичайних ключах запису.
Сплануйте незручний випадок
Якщо обраний маршрут відмовить на півдорозі, вирішіть, чи може процес безпечно продовжитися на іншому виході, чи має він заново встановити сесію застосунку, чи мусить зупинитися. Невдала відповідь не завжди означає, що надіслана операція ніколи не оброблялася.
Ані постійна липкість, ані постійна ротація не є універсально правильними. Виберіть обсяг з вимог узгодженості застосунку, а потім застосуйте темп запитів і обмеження сервісу до всього процесу. Більша кількість виходів не знімає цих вимог.