• 🚨 29 мая стартует курс «Пентест Active Directory: от теории к практике» от Академии Кодебай

    🔍 Изучите реальные техники атак на инфраструктуру Active Directory: от первоначального доступа до полной компрометации.
    🛠️ Освойте инструменты, такие как BloodHound, Mimikatz, CrackMapExec и другие.
    🧪 Пройдите практические лабораторные работы, имитирующие реальные сценарии атак.
    🧠 Получите знания, которые помогут вам стать востребованным специалистом в области информационной безопасности.

    После старта курса запись открыта еще 10 дней Подробнее о курсе ...

  • Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

Решено Одновременное редактирование полей сервером и пользователем

Gandliar

Lotus Team
16.02.2004
584
26
Пользователи могут редактировать документ на сервере либо в локальной реплике.
Агенты на сервере могут менять ряд полей документа.
Задача избежать конфликтов репликации и сохранить корректность данных.
Предлагаемое решение
1. Установить для документа $ConflictAction = "3" merge\no conflicts
2. Условно разделить поля документа на 2 части: а) поля пользователя (формы) и б) поля сервера (например с префиксом s_ )
3. Поля формы показываются и могут редактироваться пользователем, поля сервера показываются только через CFD поля и редактируются сервером.
4. Документ создается как обычно.
5. При редактировании документа, при его сохранении, документ не сохраняется как обычно, а находится через вид его документ в базе и туда перезаписываются все поля документа, за исключением полей сервера "s_"
Таким образом исключаются конфликты репликации, кто позже сохранил (пользовательские поля) тот и прав, поля измененные сервером автоматически остаются нетронутыми.
Что вы думаете об этой идее?

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

Заранее благодарю.
 
Какие могут быть подводные камни?
Пользователи могут редактировать документ на сервере либо в локальной реплике.
я изменил цену продукта и ты изменил цену продукта, оба в локальной реплике, оба реплицируют на сервер
кто в этой ситуации прав? ;)
 
Кто последний поменял тот и прав, его изменения сохранятся

Меня больше морочит создавать теневые/дополнительные документы когда база как веб-сайт используется и сервер постоянно что то пишет в доки. Может с таким подходом получится оставить 1 документ и все.
 
То есть для уменьшения последствий одновременного редактирования
надо при сохранении изменений пользователя проверять значения полей и сохранять только изменившиеся поля.

Ну и в принципе сверив дату изменения документа можно выдать, что пока вы редактировали, кто то уже успел поредактировать ...

а реплицируется с сервером постоянно база
 
Для некоторых страниц необходимо вести подсчет просмотров уникальными пользователями.
применять фронтэнд и к ним есть туевахуча средств подсчета чего угодно (это не доминошная задача)
 
применять фронтэнд и к ним есть туевахуча средств подсчета чего угодно (это не доминошная задача)

Тут речь идет не о глобальной статистике сайта а о просмотре конкретной страничке клиента пользователями.
Например есть каталог услуг и в есть странички услуг конкретных клиентов.
Поэтому я думаю что простой +1 с проверкой на уникальность ip в течение часа достаточно
идея в том и состоит, чтобы не делать дополнительные документы, а все хранить в одном, не смотря на то что изменять этот документ будут и сервер и пользователи
и чтобы это происходило безконфликтно.
также сервер время от времени (например исходя из наступления определенного периода или его окончания) изменяет признаки отображения документа.
при этом, другие поля могут редактироваться пользователем.
сейчас в моей программе сервер меняет связанные документы, чтобы разграничить изменения пользователя и сервера
но это стало совсем неудобно, приходится таскать за собой практически копию всех данных и обновлять ее.
вот решил переделать на иной подход.
однако это глобальная переделка и боюсь что все гдалко на бумаге, не напороться бы на овраги...
 
вопрос был про подводные камни :)

1 камень уже нашелся -> при сохранении сохранять только измененные поля.
непонятно правда как проверить изменилось ли ричтекствое поле.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!

Курс AD