Переменные сеанса ASP.NET

У меня есть переменная сеанса: ID. Существует ли вероятность того, что два браузера на одном ПК могут использовать одну и ту же переменную сеанса и обновлять ее, что приводит к случайным результатам? Я ожидаю, что всегда будет два отдельных сеанса с двумя отдельными наборами переменных сеанса.

Я исследовал это и наткнулся на следующую веб-страницу, которая предполагает, что существуют блокировки сеанса, чтобы предотвратить это: http://odetocode.com/blogs/scott/archive/2006/05/20/session-state -uses-a-reader-write-lock.aspx. У меня есть приложение ASP.NET, и есть случайные результаты, предполагающие, что это может происходить.

Я создам некоторый код, если потребуется.

ОБНОВЛЕНИЕ 19:51 Тим Медора говорит: «два экземпляра одного и того же типа браузера, использующие один и тот же идентификатор сеанса». Означает ли это, что если пользователь открывает один браузер, а затем закрывает его (потому что открытие занимает слишком много времени), а затем открывает другой браузер (в другом окне), то может использоваться тот же идентификатор сеанса, а переменные сеанса в окне 1 копируются для окна 2?

ОБНОВЛЕНИЕ 19:35 24/10/2012 Тим Медора говорит: «Однако существует вполне реальная возможность наличия двух вкладок в одном и том же браузере или двух экземпляров одного и того же типа браузера с использованием одного и того же идентификатора сеанса». Будет ли в этих случаях информация о сеансе раздельной. Например, если пользователь открывает браузер, а затем закрывает его (до загрузки ответа), а затем открывает то же окно с другим набором переменных сеанса, существует ли риск того, что сеансы A и сеансы B имеют одни и те же переменные сеанса.


person w0051977    schedule 23.10.2012    source источник
comment
Просто чтобы получить некоторую регулярную путаницу: два разных браузера не должны иметь возможность совместно использовать сеанс, но две разные вкладки или окна одного и того же браузера будут совместно использовать сеанс, если вы не используете какой-то специальный частный режим. (Теперь доступно в большинстве браузеров).   -  person madth3    schedule 23.10.2012


Ответы (2)


Вероятность случайного столкновения крайне мала.

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

Означает ли это, что если пользователь открывает один браузер, а затем закрывает его (потому что открытие занимает слишком много времени), а затем открывает другой браузер (в другом окне), то может использоваться тот же идентификатор сеанса, а переменные сеанса в окне 1 копируются для окна 2?

Да, идентификатор сеанса можно использовать повторно, и один и тот же сеанс может быть активен. Я провел быстрый эксперимент с Chrome и смог скопировать URL-адрес (который использует сеанс) на новые вкладки и новые экземпляры браузера, и тот же сеанс остался активным.

Однако переменные сеанса не копируются для нового окна; это одни и те же значения.

Блокировка сеанса

Блокировка сеанса означает только то, что два модуля записи не могут обновлять его одновременно. Более конкретно, блокировка устанавливается на сеанс с начала запроса до конца запроса; только одна запись может изменить его в течение этого периода. Но этот период времени обычно очень мал, и (хотя блокировка предотвращает некоторые проблемы) он не мешает двум разным источникам изменять одни и те же данные в разное время.

Предотвращение столкновения

Один из способов минимизировать коллизии — использовать уникальные сеансовые ключи. Допустим, пользователь (в одном и том же сеансе) открывает две разные записи для редактирования. Если у вас есть сеансовый ключ «ActiveRecord», вероятность повреждения/несоответствия данных очень высока. Однако, если каждая страница хранит уникальный ключ в скрытом поле, этот уникальный ключ можно затем использовать для извлечения соответствующего значения из сеанса, и каждым значением можно манипулировать по отдельности.

Другими словами, уникальные ключи позволяют безопасно открывать два разных экземпляра одного и того же предмета одновременно. Это не предотвращает проблемы с одновременным редактированием одного и того же элемента в двух окнах. Хотя у них будут отдельные ключи, конечный результат, вероятно, будет нежелательным, когда данные будут зафиксированы.

1 — вроде бы так во всех современных браузерах, но я не могу окончательно сказать, что это всегда так. Буду признателен за ссылку.

person Tim Medora    schedule 23.10.2012
comment
Спасибо. Я добавил к моему вопросу на основе вашего ответа. Не могли бы вы взглянуть? - person w0051977; 23.10.2012
comment
Обновлено, чтобы ответить на ваш вопрос. - person Tim Medora; 24.10.2012
comment
Спасибо. Я почти готов принять. Я обновил вопрос. Пожалуйста, не могли бы вы просмотреть его? - person w0051977; 24.10.2012
comment
В ответ на ваш последний вопрос: если ответ вообще не загрузился, в браузер не будет записан файл cookie с идентификатором сеанса. Поскольку файл cookie — это единственный способ, с помощью которого сервер может идентифицировать сеанс, вам вероятно будет выдан новый идентификатор сеанса и новый сеанс. Однако это делает много предположений, самое большое из которых заключается в том, что файл cookie не был записан. - person Tim Medora; 24.10.2012
comment
Я не уверен, что я совершенно прав, потому что страница все еще пытается загрузиться, если браузер закрыт? - person w0051977; 24.10.2012
comment
Сервер, вероятно, продолжит попытки выполнить запрос, поэтому он может начать сеанс. Если браузер будет закрыт до того, как до него дойдет первый ответ, cookie, вероятно, не будет записан. Но помните, что ASP.Net немедленно записывает файл cookie сеанса, поэтому это сработает только в том случае, если первый запрос был длительным. Как я уже сказал, все это делает много предположений. У вас есть конкретный случай, который вы пытаетесь учесть? - person Tim Medora; 24.10.2012
comment
Да, несколько дней назад я задал следующий вопрос: stackoverflow.com/questions/12980123/. Рассматриваемая страница очень большая. - person w0051977; 24.10.2012
comment
Хорошо, это немного проясняет. Принятый ответ правильный - вы не можете обновить сеанс с одной страницы, пока он заблокирован на другой странице. Но запросы ставятся в очередь, поэтому, как только первая страница снимает блокировку, вторая страница может обновить переменные сеанса. Это может быть нежелательным поведением. Опять же, если первая страница не получила файл cookie сеанса, вторая страница может начать новый сеанс. Я полагаю, что даже немного возможно, что первая страница может закончиться сеансом второй страницы. Учитывая все обстоятельства, это, вероятно, не то поведение, на которое вы хотите полагаться. - person Tim Medora; 24.10.2012
comment
Кстати, если вам нужна синхронизация всего приложения, вы можете использовать именованную блокировку приложения SQL Server. Их следует использовать с осторожностью, но вы можете синхронизировать доступ между несколькими сеансами и даже несколькими серверами. - person Tim Medora; 24.10.2012
comment
Я просто пытаюсь доказать, что то, что вы говорите в своем четвертом комментарии, может произойти. Это неприемлемо. Когда первая страница снимает блокировку? Спасибо. - person w0051977; 24.10.2012
comment
Блокировка устанавливается очень близко к началу любого запроса, использующего сеанс, и снимается очень близко к концу запроса. Для практических целей это на время запроса... на самом деле, я думаю, что есть несколько быстрых шагов, которые происходят до/после блокировки. Входящий запрос проходит несколько уровней, прежде чем попасть к обработчику, который указывает, нужны ли ему данные сеанса. - person Tim Medora; 24.10.2012
comment
В идеале было бы полезно увидеть пример, в котором состояние сеанса передается, возможно, по ошибке. - person w0051977; 25.10.2012
comment
Что произойдет, если процесс ASP.NET перезапустится во время запроса? Извините за все вопросы. Я все еще неясен. - person w0051977; 25.10.2012
comment
Повторное использование процесса завершит все активные запросы и сеанс. Если это потенциальная проблема, вы можете либо отключить перезапуск, либо запланировать его на определенное время. - person Tim Medora; 25.10.2012
comment
Я задал связанный с этим вопрос здесь: stackoverflow.com/questions/13057357/. Можешь взглянуть? - person w0051977; 25.10.2012

Недавно столкнулся с похожей ситуацией. На экране создания пользователя можно ввести несколько адресов для пользователя. Первоначально я использовал сеанс для хранения адресов. Поскольку сессия разделяется между вкладками браузера, функциональность не работала должным образом. А также я понял, что хранение данных в сеансе не является хорошим подходом из-за различных причин, таких как накладные расходы на поддержание состояния сеанса в сценарии веб-фермы и т. д. Итак, мне пришлось вернуться к манипулированию DOM (начиная с его приложения mvc) для хранения адресов. Если это веб-формы, состояние просмотра может быть альтернативой сеансу.

Как упоминалось в уже опубликованном ответе, это может быть достигнуто с помощью сеансов с использованием уникального ключа для каждого запроса, то есть, в моем случае, хранения адресов в сеансе [userid] или вы можете использовать любой случайный ключ для хранения значений и иметь скрытые поля для сохранения этого ключ через веб-запросы. Однако по другой причине я не был убежден, что они не будут очищаться автоматически, когда пользователь закрывает вкладку.

person Sunny    schedule 23.10.2012