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

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

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

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Откат Документов

  • Автор темы Chron
  • Дата начала
C

Chron

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

Мыш

Lotus Team
12.02.2008
1 213
29
BIT
43
Chron, а в свойствах док-та что - кто и когда его модифицировал посл. раз?
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
177
несинхрон во времени, на компах с реплик-копиями, вполне может дать такой эффект
 
C

Chron

А вот как быстро определить, есть ли реплики у базы.. будь то локальные, на этом же сервере или на другом... Пробую при помощи аналайзера, он ругается на отсутствие файла dba4.nsf
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 933
609
BIT
177
на сервере - открыть catalog.nsf

Добавлено: но главное м.б. не сами реплики - а различие времени
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
открыть свойство БД - история репликации
 
C

Chron

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

Chron

Дико извиняюсь, но вынужден апнуть тему. Проблема то не решилась, просто подзабил на нее, но с ростом количества пользователей проблема возникает все чаще. Уверен в одном, база в единственном экземпляре, репликации базы запрещена. Документы каким-то чудесным образом продолжают откатываться. Что за чертовщина творится, не понимаю...
 

Darkhan

Green Team
14.12.2012
99
2
BIT
0
Может народ одновременно исполняет документ? Через УИ или в бэкенде
 

savl

Lotus Team
28.10.2011
2 597
310
BIT
159
@Chron, точно запрещена репликация?
История репликации между серверами пустая?
 

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
3
С фантомными репликами вполне справляется pirc
 

garrick

Lotus Team
26.10.2009
1 349
151
BIT
164
Реплик может и не быть, но документы с конфликтами могут быть вполне. Один пользователь открыл документ и что-то там делает, второй пользователь тоже открыл документ, но немного позже первого... первый завершил своё дело и сохранил документ, в истории сохранилась запись об этом, после этого второй пользователь завершил своё дело и тоже сохранил документ, в его версии в истории нет записи о действиях первого пользователя, но появилась запись об его истории и т.к. его действия последние и в итоге сохранилась его версия документа, то в истории документа "пропадёт" запись о действиях первого пользователя.

Способы борьбы
  1. Хранить историю по каждому действию в отдельном респонз документе и показывать всю историю в эмбедед вью. Недостаток - большое количество документов в базе.
  2. При открытии документа на редактирование делать его копию (можно не сохранять), а при сохранении считывать новую копию документа с диска из базы и проверять не изменились ли какие-то поля уже после открытия. Ну хотя бы как минимум проверить время последнего изменения. Если что-то изменилось предпринять соответствующие действия на ваш вкус - сообщить пользователю, что оно не прав и не дать сохранить документ, втихоря скопировать историю с более новой версией и т.п. Недостаток - много всяких действий и кода с проверками.
Следует учесть, что в качестве "второго пользователя" вполне может выступать какой-нибудь агент на сервере, работающий по расписанию.
 

savl

Lotus Team
28.10.2011
2 597
310
BIT
159
Хранить историю по каждому действию в отдельном респонз документе и показывать всю историю в эмбедед вью. Недостаток - большое количество документов в базе.
я бы в отдельной базе хранил, а путь/реплику прописывал бы в документ при создании.
Плюсы: всегда знаешь в какой базе история к документу, баз может быть over 9000, при критическом количестве - создаем новую базу и меняем настройку.

При открытии документа на редактирование делать его копию (можно не сохранять), а при сохранении считывать новую копию документа с диска из базы и проверять не изменились ли какие-то поля уже после открытия.
Можно чуть проще:
При открытии писать в глобальную переменную текущий документ.
При сохранении переполучить документ из базы в другую переменную, затем проверить у документов $UpdateBY.
Если размер не совпадает, то кто-то пересохранил документ.

Третий вариант - самописная блокировка.
Делается база, в которой при открытии на редактирование создается документ, при попытке отредактировать другим пользователем - проверяем наличие этого документа, если документ есть - запретить редактирование второму пользователю.
Но от агентов не сильно спасет.
 
Мы в соцсетях:

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