Путь вокруг сеанса ASP.NET для общего доступа к нескольким вкладкам

Ответ 1

Я понял решение:

• Используя Javascript, присвойте уникальный идентификатор, например guid, в окно браузера/вкладку, назначив значение guid для свойства window.name. Свойство window.name уникально для каждого окна браузера/вкладки и не будет использоваться в разных окнах.

• Используя guid в качестве ключа, читайте и записывайте данные на ваш сеанс ASP.NET через веб-сервис. Поскольку javascript не имеет доступа к сеансу asp.net, вам нужно будет использовать веб-сервис и вызвать его методом через javascript.

Данные могут передаваться между javascript и webservice через JSON.

Ответ 2

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

Это похоже на то, что ViewState делает автоматически.

EDIT

Комментарий комментария

Я не думаю, что это возможно, как вы описали его.

В вашем вопросе вы указали страницу с 1 по 2 навигации. Если пользователь вводит URL-адрес для страницы 2 в браузере, то как вы связываете текущую страницу с предыдущей страницей 1?

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

Комментарий отклика 2

Вы можете найти все ссылки на странице и изменить их, но он намекает, что что-то не так (на мой взгляд). Но...

http://www.extremeexperts.com/Net/Articles/LoopingthroughControls.aspx

Предоставляет вам простой способ обработки всех элементов управления на странице. Вы можете проверить, легко ли управление является гиперссылкой. Не для того, чтобы все ссылки нуждались в том, что параметр runat = "server" установлен для этого.

Ответ 3

Не могли бы вы использовать ViewState вместо SessionState?

Update:

Или, возможно, сочетание ViewState и SessionState.

Здесь пример последовательности:

• На странице 1 пользователь выбирает "Красный". Значение сохраняется в SessionState.
• Пользователь переходит на страницу 2. Значение считывается из SessionState и сохраняется в ViewState страницы.
• Пользователь открывает вторую страницу 1 на новой вкладке и выбирает "Синий" . Значение сохраняется в SessionState, поэтому "Красный" заменяется на "Синий" .
• Пользователь переходит на страницу 2. Снова значение считывается из SessionState и сохраняется в ViewState.
• Пользователь возвращается к исходной странице 2 (первая на первой вкладке) и выполняет PostBack. Значение считывается из ViewState. Значение по-прежнему "красное".
• Пользователь возвращается на вторую страницу (вторая вкладка) и выполняет PostBack. Значение считывается из ViewState. Значение по-прежнему "Синий" .

Другими словами, используйте SessionState для переходов между страницами. Используйте ViewState для PostBacks той же страницы.

Помогает ли это?

Ответ 4

Похоже, вы хотите, чтобы каждая страница сохранила свои собственные значения, отделенные друг от друга.

• Если вы можете использовать Post (например: вы можете не манипулировать URL-адресом на клиенте), скрытые теги ввода могут хорошо выполнять эту работу. Вы, конечно, захотите инкапсулировать это, так как делать это вручную было бы огромной болью. В противном случае:
• Если вы используете ViewState, вы можете использовать это. В противном случае:
• Вы получаете значения или идентификатор (который будет лучше, см. ниже) в URL. Последнее средство, потому что человек сможет это испортить. Или они могут пометить его и вызвать путаницу, когда они вернутся через неделю.

Если значения не могут быть отправлены клиенту, вам необходимо передать "PageSessionID" или что-то еще для клиента. Этот идентификатор является либо ориентиром (лучше, если безопасность является проблемой), либо некоторой ценностью, которую вы получаете, чтобы гарантировать уникальность. Отправьте клиенту скрытый тег ввода или в ViewState (или url, если нет другого выбора), и сохраните связанные данные на сервере на основе этого идентификатора.

Cookies не будут работать для вас.

Ответ 5

Другой способ сделать это - использовать Server.Transfer или CrossPagePostBack. Затем вы можете получить доступ ко всем предыдущим переменным страницы, используя Page.PreviousPage. Если Page.PreviousPage имеет значение NULL, вы знаете, что пользователь сразу попал на страницу, и вы должны обработать страницу 2 с учетом этого.

Я не могу это по-настоящему рекомендовать, потому что с Server.Transfer вы не обновляете URL-адрес в браузере, а CrossPagePostBack делает все после обратной связи, что может привести к таким проблемам, как кнопка "Назад", которая не работает "нормально".

Ответ 6

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

Я планирую использовать ключ guid для создания/заявки объекта блокировки, хранящегося в appstate. Объект блокировки также имеет идентификатор пользователя /timestamp/PageToken. Маркер страницы является ориентиром, но может быть нулевым, если объект сеанса на основе токена страницы предварительно создан для другой страницы в том же сеансе [так что может передавать больше данных на новую страницу], или токен может быть оценен, если создан объект сеанса для текущей страницы. Когда объект сеанса создается на основе ключа, его можно использовать для хранения данных типа обычного сеанса, который теперь уникален для этого ключа, а не используется на протяжении всего сеанса.

Таким образом, первая страница создает ключевой объект в состоянии приложения w/oa pagetoken, а затем ссылается на новую страницу, которая выполняет ключевой объект из appstate, используя его запрос с ключом, и сопоставляя идентификатор пользователя /timestamp/PageToken с нулевым или ценный токен. Если он совпадает и является нулевым токеном, токен создается и сохраняется в ключевом объекте и в представлении.

Если другая страница входит с той же строкой запроса, соответствующей ключевому ключу, она может попытаться потребовать объект-объект appstate, но будет терпеть неудачу, если не имеет тот же идентификатор пользователя /timestamp/PageToken в ключевом объекте, который получил маркер страницы, ViewState. И если все согласовано, обновляется метка времени. Если отметка времени слишком старая, 15 минут, ключевой объект можно украсть. и если старая страница вернется к поиску, токен страницы больше не будет соответствовать, и запрос будет терпеть неудачу из-за слишком старой отметки времени или маркера страницы, не соответствующего.

Токен может быть нулем или оценен при создании ключевого объекта. Если он начинается с нуля при создании, то любой может претендовать с новым токеном, но должен точно соответствовать отметке времени.

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

Таким образом, мы можем заблокировать данные по всему веб-приложению всем пользователям, и мы можем истечь и вернуть блокировки после 15 минут неиспользования и иметь данные на основе ключевых слов для вкладок, страниц, новых сеансов и разных браузеров.