Клиент вошёл по ссылке на заказ, а попал на главную: как сохранять маршрут после авторизации

1. Клиент получает уведомление с переходом к своему заказу.
2. Сессия закончилась, приложение показывает вход.
3. После входа открывается главная, а номер заказа приходится искать заново.

Такой путь формально работает, но заставляет пользователя повторять действия. Исправление — сохранить намерение перехода на время авторизации. При этом нельзя просто принять любой адрес из параметра return_url: вместе с удобным возвратом можно случайно открыть перенаправление на чужой сайт.

Сохраняйте маршрут как проверяемые данные

Вместо произвольной строки URL удобно хранить тип экрана и валидированные параметры: например, просмотр заказа с определённым внутренним ID. После успешного входа приложение снова проверяет, что текущему пользователю разрешён этот объект. Истёкшая сессия и наличие ссылки не являются разрешением на чтение заказа.

Если используется строка пути, задайте разрешённые маршруты и процедуру нормализации. Адреса с другим доменом, схемой, обратными слешами или неоднозначным кодированием нельзя автоматически считать локальными. Не проверяйте безопасность только условием «содержит наш домен»: похожая строка может иметь совершенно другой смысл для URL-парсера.

Переход и команда — не одно и то же

Ссылка может открывать экран оплаты или подтверждения, но вход в аккаунт не должен сам по себе выполнять финансовое действие. Восстановите контекст и покажите актуальные условия. Пользователь отдельно подтверждает команду, а сервер проверяет её по обычным правилам.

То же относится к ссылкам из старых уведомлений. Заказ мог изменить статус, цена — стать недействительной, а роль сотрудника — быть отозвана. Старый маршрут помогает найти объект, но не замораживает его состояние. После входа загружается актуальная версия.

Что произойдёт при смене аккаунта

На общем компьютере ссылку может открыть другой человек. Сохранённое намерение должно иметь ограниченный срок и корректную привязку к потоку входа. При смене пользователя нельзя подмешивать прежние черновики и доступы. Если нужен выбор организации внутри аккаунта, сначала проверьте членство, затем доступ к объекту в выбранной организации.

Не переносите секреты в query-параметры без необходимости: URL попадает в историю, журналы и иногда заголовки переходов. Для одноразовых ссылок действует отдельная модель токенов и срока жизни. Обычный параметр возврата не стоит превращать в неограниченный способ обхода авторизации.

Префикс проверяют на границе сегмента

Разрешение пути /orders не должно автоматически разрешать /orders-other. Это другая часть адреса, хотя строка начинается одинаково. В модели ниже допустим сам путь или продолжение через слеш, например /orders/42. Такой тест полезно сохранить рядом с проверкой внешнего URL: обе ошибки появляются при слишком простом сравнении строк, но приводят к разным последствиям.

Приёмка с потерянной сессией

Проверьте нужный экран с действующей сессией, после её завершения и после входа другим тестовым пользователем. Добавьте старую ссылку на недоступный объект и учебный внешний адрес возврата. В каждом случае должен быть понятный исход, а не бесконечный цикл входа или неожиданное открытие чужой страницы.

Встроенный инструмент демонстрирует строгую локальную политику: только обычные пути без query и fragment, из разрешённых префиксов с границей сегмента. Кодирование процентов и обратные слеши отклоняются для ручного разбора. Это намеренно узкая модель, а не полноценная реализация маршрутизатора. Реальное приложение может поддерживать больше форматов после отдельного проектирования.

Даже разрешённый путь в результате инструмента не означает, что конкретному человеку разрешён заказ. Проверка маршрута, авторизация пользователя и права на объект остаются независимыми. Хороший возврат после входа сохраняет удобство, не стирая этих границ.