Как заблокировать страницу asp.net из многопользовательского редактирования?

Question

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

Я подумал о ссылке на страницу редактирования и ссылку на страницу только для чтения (все элементы управления отключены), а затем установите флаг базы данных, если пользователь входит в режим редактирования, но моя забота - я не знаю, изменил ли пользователь что-то, затем просто x'd из браузера/приложения, блокируя всех остальных.

Это внутреннее приложение для компании. Кто-нибудь сделал что-то подобное?

Любые идеи или мысли или предложения?

Благодаря

Answer 1

У нас есть эта функция в более старом приложении ASP. Пользователь будет загружать данные с помощью некоторого типа первичного ключа. Мы помещаем запись в БД для блокировки этой страницы. Если они правильно перемещаются по сайту, он откроет ресурсы в это время.

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

Было бы довольно тривиально кодировать вызов unPageUnload AJAX для сброса блокировки закрытия браузера. Мы не находим, что это большая проблема, и старые замки просто очищаются вечерним процессом, если ему больше 4 часов.

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

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

Answer 2

Вы делаете то, что вы сказали, но добавить на стороне клиента таймер, который будет пинг сервера и сказать вам, что они все еще там. Если вы не получите пинг в течение x минут, вы можете позволить новому пользователю перейти в режим редактирования, но, возможно, предупредить его (или нет).

Answer 3

Как насчет альтернативы расширенному замку?

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

Answer 4

Как насчет того, чтобы позволить всем пользователям редактировать эту страницу и как ваш скрипт регистрируется на обновления страниц? Точно так же, как SO делает, когда вы вводите ответ, появляется оранжевое сообщение, говорящее «По крайней мере, один новый ответ был опубликован». Вы можете отобразить что-то вроде «Страница была изменена с момента последнего ее открытия».

В ASP.NET AJAX было что-то вроде таймера. Вы можете использовать это, чтобы поговорить с сервером, чтобы отправить обновления статуса «IN EDIT». Вы даже можете пойти дальше. Скажем, вы отправляете запрос «LOCKOUT REQUEST» каждые 15 секунд асинхронно, и вы ожидаете получить ответ «LOCKOUT GRANTED» с сервера.Если ответ не получен, вы отключите все элементы управления на странице, пока, возможно, следующий запрос не получит подтверждение (предыдущее сообщение могло быть потеряно в сети). Таким образом, если один пользователь закрывает браузер, другой не должен ждать много минут или часов, пока не получит разрешение на редактирование.

По существу, вам нужна распределенная реализация для концепции критического раздела. Это вызов для реализации этого по HTTP. Но это очень интересная задача, не так ли?

Answer 5

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

Итак, когда один пользователь нажимает на редактирование, добавьте запись в AppVariable Map или Dictionary, при этом ключ установлен в первичный идентификатор редактируемого поля. Затем для всех последующих запросов, когда они меняются между записями, выполните проверку идентификатора на карте и, если его отредактировать, переведите все кнопки обновления. Если вы хотите сделать это AJAXy, добавьте таймер и UpdatePanel и опрос, чтобы увидеть, когда блокировка будет выпущена, а затем обновите страницу с обновленными данными и снова включите кнопки обновления.

Или, как немного больший пользовательский интерфейс, разрешите пользователям редактировать, ожидая освобождения блокировки (элемент карты, который нужно удалить), затем, когда он будет удален, сравните поля, над которыми они работали, с обновленные значения базы данных и позволяют им перезаписывать/объединять свои изменения.

Единственный реальный недостаток: 1) Вам нужно будет создать один словарь уровня приложения или карту для каждой таблицы, которую вы хотите заблокировать/разблокировать. 2) Если вы попадаете в среду webfarm, она ломается, и вам придется использовать другую систему.

Это имеет смысл?

Answer 6

Если вы пытаетесь запретить двум пользователям обновлять запись db и переписывать друг друга, возможно, было бы легче обнаружить это, чем предотвратить это.

О стратегии для этого является включение поля «версия» в запись и сохранение этого в скрытом поле при рендеринге страницы.

Затем вы просто включаете это как условие своего обновления (то есть UPDATE ... WHERE ID = myID AND VERSION = myversion) - если ваше обновление возвращает 0 строк, вы знаете, что кто-то еще изменил данные, и вы можете решить, что делать - перезагрузить новые данные, предложите пользователю возможность их сравнить и т. д.