Когда я работал с классическим ASP.NET или даже со старыми веб-формами, HttpContext.Current.Session был специфичным для пользователя. Поэтому, когда пользователь делает запрос, он получает файл cookie сеанса, а затем этот сеанс принадлежит только этому пользователю. Таким образом, два разных пользователя могут иметь ключ сеанса с тем же именем в своем соответствующем сеансе.Является ли сессия asp.net основной не специфичной для пользователя?
Я читаю документацию по сеансу в ASP.NET Core и, похоже, имеет ту же концепцию, что и старый asp.net, но записи в документации в документации сбивают с толку.
here это говорит
хранения Session основан на идентификаторе куки на основе доступа к данным , связанные с данной сессии браузера (серия запросов от конкретного браузера и машины). Вы не можете не предполагать, что сеанс ограничен одним пользователем, поэтому будьте осторожны, какую информацию вы сохраняете в Сессите . Это хорошее место для хранения состояния приложения, специфичные для конкретной сессии, но не нужен сохранялся постоянно
также here он говорит
сессия не является замком, поэтому, если два запроса попытаются изменить содержимое сеанса , последний выиграет. Кроме того, сеанс реализован как последовательный сеанс, что означает, что все содержимое хранится вместе. Это означает, что если два запроса: , изменяющие разные части сеанса (разные ключи), они могут все еще влияют друг на друга.
так что позволяет сказать, у меня есть User1 войти в систему и на какое-то действие я установить
`Session.SetInt32("key1", 123)`
Теперь Пользователь2 входит в с другой машине и на какое-то действие я установить
`Session.SetInt32("key1", 999)`
Вопрос 1
Будет ли это перезаписывать ключ User1?
отметить также here говорит
ASP.NET поставляется с несколькими реализациями IDistributedCache, включая опции в памяти (для использования в процессе разработки и тестирования только)
Вопрос 2
Какова другая реализация IDistributedCache, которую я могу использовать в процессе производства?
для # 1 как это отличается от классического asp.net? сессия в классическом asp.net работает так же, как я думаю. Кроме того, если сеанс не рекомендуется, то какой вариант я должен хранить для пользовательских данных – LP13
Я не сказал, что его не рекомендуется, зависит от того, где вы его используете (в WebAPI его довольно плохая идея, поскольку служба WebAPI/REST должна быть апатридом) , для MVC его довольно хорошо использовать. Если вы хотите привязать его к пользователю, сохраните идентификатор пользователя и ip в нем, сравните его по каждому запросу (т. Е. Напишите промежуточное программное обеспечение, которое его проверит и, если необходимо, аннулирует сеанс, если пользователь и сохраненный идентификатор пользователя не совпадают) – Tseng
Это не отличается от классики, но люди, особенно раздражающие инструменты сканирования безопасности, иногда предполагают, что сеанс связан с пользователем, поэтому мы называем его понятным. – blowdart