#c# #session #servicestack
#c# #сеанс #servicestack
Вопрос:
Приложение ServiceStack использует Angular (но проблема возникает и с /auth * см. Ниже)
Браузеры, в которых я определенно сталкиваюсь с проблемой: Chrome, Safari
Возникает проблема, при которой пользователь теряет сеанс сразу после перенаправления входа. Я также тестировал использование /auth?имя пользователя и пароль, я отлично получаю идентификатор сеанса, но возврат к /auth показывает меня как несанкционированный.
Очистка кэша помогает решить проблему, как и использование режима инкогнито.
Я попытался добавить управление версиями в файлы CSS и JS на всякий случай, если это было проблемой при нажатии, но это не решает проблему.
Шаги для воспроизведения
- Нажимные библиотеки dll, файлы js
- перейдите на промежуточный веб-сайт
- попытка входа в систему…успех
- перенаправление и сеанс пропали
Есть идеи о том, где искать / решить эту проблему, не заставляя пользователей приложений очищать кеш? Любые идеи / направления были бы очень полезны.
Комментарии:
1. Остается ли пользователь в том же домене при перенаправлении? Используете ли вы файлы cookie сеанса или сервер состояния сеанса? Проверил значения / настройки / cookie сеанса / сервера?
2. Спасибо за предложение, это заставило меня взглянуть на домены cookie, которые приводят к решению
Ответ №1:
Если вы используете MemoryCacheClient , то добавление файлов в папку вашего веб-приложения приведет к перезапуску ASP.NET Домен приложения, который перезапускает ваше веб-приложение, очищая всю существующую память.
Вам нужно будет использовать любого другого поставщика распределенного кэширования, чтобы сохранить ваш кэш и сеансы после перезапуска домена приложения.
Ответ №2:
Хорошо, разобрался с проблемой! Это было весело.
Настройка: у нас есть два сайта servicestack
- example.com //при постановке это был SSL
- sub.example.com //при постановке это был не SSL
Вот как проблема воспроизводится при тестировании, которое мы бы сделали….
- войдите в example.com в какой — то момент предшествующий , который привел бы к .example.com домен cookie-файлов
- Мы бы отправили изменения файлов в sub.example.com который уничтожил бы файлы cookie для этого поддомена
- Мы попытаемся войти в sub.example.com и потерпеть неудачу
- Если я удален.example.com файлы cookie из example.com , вход в систему sub.example.com было бы прекрасно
Чтобы исправить, мы сделали sub.example.com А также SSL, который устранил проблему. В долгосрочной перспективе мы сделаем все подстановочные знаки для файлов cookie и добавим поставщика, не являющегося memcache, согласно предложению Mythz.