Фон приложения Безопасность: все приложения размещены в частной экстрасети (и / или локальной интрасети - в зависимости от экземпляра установки).Таким образом, хотя безопасность важна, она не так важна, как если бы она была приложением во внутренней сети.Однако, говоря, что важно, чтобы система не могла быть легко взломана или взломана.
Приложения: Приложение состоит из 2 частей: -
- Библиотека классов (dll)
- Аутентификация Front-end приложения ASP.NET
DLL является частью приложения аутентификации front-end и должна быть добавлена в другие приложения («потребительские приложения»), требующие пользователейбыть аутентифицированным.
Приложение аутентификации - это центральное хранилище всех пользователей, приложений, к которым у них есть доступ, и уровней разрешений на основе их имени пользователя.
Для потребительских приложений, в которых установлена dll, когда конечный пользователь переходит на страницу, требующую входа в него, потребительское приложение запускает их на странице login.aspx приложения аутентификации вместе с appid,пользователь входит в систему, если у него есть необходимые разрешения, то приложение auth отправляет их обратно в потребительское приложение (через форму с зашифрованными данными), которая включает базовые данные о том, кто пользователь, имя пользователя, реальное имя, должность, организация и т. д.... и, что важно, список их уровней разрешений для приложения-потребителя.
Затем приложение-потребитель берет эти данные, обрабатывает их, дешифрует и т. д. и создает файл cookie для проверки подлинности с помощью форм и заполняет класс пользователя.и пользовательский класс ролей - все это делается из самой библиотеки.
Проблема
Теперь все это прекрасно работает, и изначально все данные были сохранены вcookie-файл аутентификации в части cookie-файла с пользовательскими данными, однако вот в чем проблема ...
Приложение для потребителя (и есть один центральный, который мы написали собственными силами, у которого может быть много разрешений (ролей пользователей), связанных с одним пользователем (главным образом администраторами приложений), и поэтому нам нужно что-то, что может хранить много данных, больше чем 4 КБчто файл cookie аутентификации может содержать.
Итак, я попытался поместить это в переменные сеанса, ну, вначале, одну переменную со всеми переданными зашифрованными данными в одну переменную сеанса, называемую «userdata».Затем я проверяю, когда выполняется запрос.
Однако ...
Первая проблема, с которой я столкнулся, заключалась в том, что cookie-файл аутентификации, похоже, имеет более длительный срок службы, чем Session.Думаю, я исправил это, расширив сеанс до 35 минут (на 5 минут дольше, чем AuthCookie).
Но когда программист потребительского приложения вносит изменения в свой код (запускает localhost в режиме отладки через Visual Studio 2010) иобновляет браузер, AuthCookie остается, но сеанс исчезает.Сейчас изначально я использую режим сеанса InProc по умолчанию, который, я думаю, может быть проблемой.
Правильно ли мое предположение?И есть ли способ программной синхронизации сеанса и AuthCookie?
Есть еще какие-нибудь советы по решению этой проблемы?