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

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

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

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

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

Изменение значений в бекэнде

NickProstoNick

Статус как статус :)
Lotus Team
22.08.2008
1 851
27
BIT
0
Всем привет!
Вот задался вопросом.. нужно проследить изменение документа в бекэнде.
Ситуация такая:
Пользователь 1 открывает документ... держит его какое-то время t.
За это время t другой 2 пользователь открывает этот же документ.. правит его... и сохраняет.
Далее пользователь 1 решает что-то сделать с документом (точнее нажать на кнопку в документе).
При нажатии надо проверить были ли изменения документа за время t.
Пытаюсь сделать так...
По UNID открытого документа ищу в базе документ и сравниваю определенные поля.
Но вот не задача... таким способом получаю текущий открытый документ без изменений :gigi:
Как бы это обойти? или может я что-то не так делаю?
 
M

morpheus

NickProstoNick
возможнос закрыть документ 1

взять его по униду заново ( "скинув" перед этим сессию и базу )
и открыть уже с новыми значениями
 

NickProstoNick

Статус как статус :)
Lotus Team
22.08.2008
1 851
27
BIT
0
NickProstoNick
возможнос закрыть документ 1

взять его по униду заново ( "скинув" перед этим сессию и базу )
и открыть уже с новыми значениями
Закрыть - не вариант. Документ мог и не измениться.
 
M

morpheus

NickProstoNick
пробуйте просто , как написал ув.kizarek Delete сессия\база\док

ещё как вариант
зделать вьюшку с ключевыми полями , с категорией УНИД
с АвтоАпдейтом = 1(тру)
и делать ГетВьюЕнтриБайКей по Униду

у найденного энтриса проверять значение колонки
.. но это совсем изврат

Добавлено: NickProstoNick
а к чему такая необходимость чтобы одновременно можно было править один документ?
 
H

hosm

Закрыть - не вариант. Документ мог и не измениться.
Мб, стоит сделать кнопку Обновить, переоткрывающую док?
Так исторически сложилось
хорошая отмазка, только иногда стоит решаться и менять историю - вынести поля для правки в отдельные доки-респонсы и т.п.
а то иногда потом такой головняк может вылазить(
Можно сделать на кнопку запуск агента, который считает док заново по ид или из вьюхи.
 

NickProstoNick

Статус как статус :)
Lotus Team
22.08.2008
1 851
27
BIT
0
Добавлено: вообще обычно достаточно "delete doc"
Действительно помогло! спасибо!

Добавлено:
NickProstoNick
пробуйте просто , как написал ув.kizarek Delete сессия\база\док

ещё как вариант
зделать вьюшку с ключевыми полями , с категорией УНИД
с АвтоАпдейтом = 1(тру)
и делать ГетВьюЕнтриБайКей по Униду

у найденного энтриса проверять значение колонки
.. но это совсем изврат
Так тоже работает :gigi:

Добавлено:
Мб, стоит сделать кнопку Обновить, переоткрывающую док?
Не вариант. Чем больше кнопок - тем больше путается юзер. Это же надо помнить и думать что над документом могут работать несколько человек.

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

А про агент я как-то не подумал... спасибо
Но с агентом тоже не вариант... без документа-посредника результат не вернешь в основной код. Все тот же головняк.
 

VladSh

начинающий
Lotus Team
11.12.2009
1 783
157
BIT
53
Пользователь 1 открывает документ... держит его какое-то время t.
За это время t другой 2 пользователь открывает этот же документ.. правит его... и сохраняет.
Понимаю, что "так исторически сложилось", но подход идеологически неверен, т.к. определить кто и что менял очень трудоёмко.. поэтому часто эту задачу бросают, что для контроля и разбора полётов по важным докам неприемлемо; для доков, типа справочников, это не существенно, чтобы им заморачиваться.

Добавил: у меня всё сведено к бэкэндным изменениям.. в коде беру последнюю дату модификации из текущего дока, потом получаю док заново и сравниваю, если она не совпадает, то заменяю текущий док тем, что получил для проверки даты, ну т.д...
 

duchan

Green Team
20.09.2006
127
11
BIT
96
Как вариант к предложеному Morpheus: в виде в колонке не ключевые поля а дата\время изменеия (@Modified), при открытии сохраняем в глобалах текущее время изменения, потом сравниваем со значением из вьюшки - другое значит док правился и его надо переоткрыть.

Для тех кому не понятно для чего может пригодится: проблема в том что если я открыл на чтение док-т, он у меня повисел в режиме просмотра, а в это время другой юзер правил его и сохранил. Если я после этого нажму правка, то Лотус не перечитывает его с базы, а использует то что было получено для отображения в режиме просмотра - получаем "граблями в лоб"... :(
 

VladSh

начинающий
Lotus Team
11.12.2009
1 783
157
BIT
53
Для тех кому не понятно для чего может пригодится: проблема в том что если я открыл на чтение док-т, он у меня повисел в режиме просмотра, а в это время другой юзер правил его и сохранил. Если я после этого нажму правка, то Лотус не перечитывает его с базы, а использует то что было получено для отображения в режиме просмотра - получаем "граблями в лоб"... :(
Совершенно верно! Поэтому я когда-то предлагал , но тупизм, видимо, победил...
 
D

Darker

в коде беру последнюю дату модификации из текущего дока, потом получаю док заново и сравниваю, если она не совпадает, то заменяю текущий док тем, что получил для проверки даты, ну т.д...
я так понимаю, что сие проверяется перед сохранением?
 

VladSh

начинающий
Lotus Team
11.12.2009
1 783
157
BIT
53
я так понимаю, что сие проверяется перед сохранением?
Можно перед сохранением, но тогда только запросная система проканает.
Я беру док и проверяю перед началом внесением изменений, тогда же провожу попытку блокировки, так что всё тип-топ.
 
D

Darker

VladSh
как быть если одновременно отрабатывают несколько агентов, затрагивающих одновременно один документ.
Предположим первый агент работает с документом n секунд, второй n*k. Получается одному из них придется обработать документ заново? Либо один из агентов блокирует документ, остальные ожидают?
 
Мы в соцсетях:

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