Пользовательские роли - почему бы не сохранить на сессии?

Единственный способ сделать безопасное соединение - использовать SSL. Все, что меньше этого, и вам просто нужно произвести оценку, когда это «достаточно безопасно».

Переменная сеанса отлично подходит для хранения значения, за исключением того, что веб-сервер может время от времени повторно использоваться, что приведет к сессия будет потеряна. Когда это произойдет, вам придется повторно аутентифицировать пользователя и снова установить переменную сеанса.

Рассматривали ли вы создание настраиваемого тега авторизации в MVC. Я привел пример этого в другом вопросе .

При начальной авторизации (экран входа в систему или начало сеанса) вы также можете заполнить значение сеанса IP-адресом. Затем в настраиваемой авторизации вы также можете убедиться, что IP-адреса также совпадают. Это поможет убедиться, что кто-то не «крадет» сеанс у человека. Каждый раз, когда вы получаете доступ к данным сеанса, просто убедитесь, что вы передали IP-адрес запрашивающей стороны, и проверьте его.

Сохранение информации о роли пользователя в сеансе на стороне сервера безопасно, если сеанс не может быть взломан. Говоря более широко, не имеет значения, где хранится информация о ролях пользователя, если аутентифицированный сеанс был взломан.

Я советую не слишком доверять статье, на которую вы ссылаетесь, но винтажный отчет 2002 года, на который ссылается ваша ссылка, является представляет интерес. Вот мои выводы:

1. Не принимайте идентификаторы сеансов, встроенные в URL-адреса.

2. Сосредоточьте свое время на устранении опасностей межсайтового скриптинга, например, просканируйте все предоставленные пользователем данные и проанализируйте исполняемый java-скрипт.

3. Выдавайте куки-файлы. для полных доменов (например, myapp.mydomain. com)

4. Разместите свой домен у высококлассного оператора DNS, например, у того, который разрешает изменение DNS только с предварительно установленного удаленного IP-адреса.

5. Не выпускайте постоянные файлы cookie сеанса.

6. Повторно выпускайте cookie сеанса, если кто-то приходит на страница входа в систему с идентификатором сеанса, уже связанным с сеансом, прошедшим проверку подлинности.

7. Еще лучше всегда создавать новый файл cookie сеанса при успешной аутентификации и отказываться от предыдущего сеанса. (Можно ли это настроить в IIS?)

Вы пытаетесь контролировать доступ к функциям на уровне клиента? Это единственная причина, по которой я бы раскрыл роли и элементы для управления функциями на стороне клиента.

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

4Guys , кажется, показывает, как управлять функциями с помощью ролей.

Раньше я использовал симметричное шифрование файлов cookie наряду с SSL. Зашифруйте информацию о пользователе в ответе и расшифруйте ее в запросе. Я не утверждаю, что это надежно или на 100% безопасно, и я не хотел бы делать это в банковском приложении, но этого достаточно для многих целей.

Основная проблема с переменными сеанса заключается в том, что если вы их сохраните inProc вместо того, чтобы сохранять их, вам необходимо применить «липкие» сеансы к балансировке нагрузки в среде веб-фермы. Гуффа прав в том, что без этой постоянства переменные сеанса иногда теряются, что ухудшает взаимодействие с пользователем.

Прикрепленные сеансы могут привести к неравномерной балансировке нагрузки, возможно, уменьшив ценность возможности масштабирования.

Мой очевидный вопрос заключается в том, почему вы хотите сохранить роль пользователей в сеансе?

Вот мой ответьте на ваш вопрос, как это помогает. Я приложил небольшое демонстрационное приложение, чтобы вы могли взглянуть и понять мои мысли. Когда вы открываете этот проект в Visual Studio, щелкните вкладку проекта вверху и выберите конфигурацию asp.net. На открывшейся странице вы можете выполнять действия по администрированию пользователей.

Вам нужно каким-то образом сохранить роли пользователя? Ответ на этот вопрос заключается в том, что вам не нужно беспокоиться о сохранении роли для любого пользователя, когда у нас есть членство в asp.net, профили и структура ролей, которые помогут нам в этом. Все, что вам нужно сделать, это создать роль в базе данных aspnet и назначить эту роль пользователю.

Затем вы хотите сохранить две строки безопасным способом. Я предлагаю вам профиль пользователя для хранения пользовательской информации. Таким образом, у вас всегда будет доступ к информации из класса profilecommon.

Также см. Прилагаемое демонстрационное приложение, размещенное в конце моего блога http://blogs.bootcampedu.com/blog/ post / Reply-to-httpstackoverflowcomquestions1672007user-roles-why-not-store-in-session.aspx

Просто предложение, вы можете подумать об использовании этой небольшой библиотеки:

http://www.codeproject.com/KB/aspnet/Univar.aspx

В нем есть реализация cookie на стороне сервера, посредством которой все файлы cookie могут храниться на сервере, в то время как аутентификация asp.net используется для идентификации пользователя. Он поддерживает шифрование, а также очень гибкий, что позволяет легко переключаться с одного типа хранилища на другой.