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

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

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

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

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

Поделитесь опытом работы с распределёнкой

  • Автор темы Gor
  • Дата начала
G

Gor

Всем доброго времени суток.

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

Чтобы было понятней о чём я говорю, предлагаю подобный пример:

Территориально распределённая Лотусовая сеть, много серверов. Используется система Документооборота на базе ЛН, корпоративная почта ЛН.
Есть электронная заявка с этапами подписания, на каждом этапе должен подписать определённый сотрудник. Право на подписание документа должно передаватся
только тогда, когда заявка находится у текущего подписанта, т.е. в момент утверждения прошлым подписантом, соответственно в момент утверждения формируется почтовое уведомление следующему подписанту.

Подписанты:

1этап - Вася (Москва)
2этап - Коля (Ташкент)

Репликация между Москвой и Ташкентом предположим каждые два часа, а почта уходит сразу же.

Итак, как только Вася одобрил заявку, Коля получил почтовое уведомление о том что ему пришёл новый документ на одобрение, НО
как только он пытается его открыть система ругается что прав на редактирование у него нет, т.к. Лотусовые базы ещё не среплицировались.

Задача немного абстрактная, ноя думаю общий смысл ясен)

Как вы решаете/либы подобную проблему???

Ну а если тема не интересна или желания нет можно закрыть мой топик после ответа на вопрос =)
 
K

Klido

Итак, как только Вася одобрил заявку, Коля получил почтовое уведомление о том что ему пришёл новый документ на одобрение, НО
как только он пытается его открыть система ругается что прав на редактирование у него нет, т.к. Лотусовые базы ещё не среплицировались.
агентом уведомление слать, а не с клиента в момент предыдущего действия... агент выполняется на каждом сервере при новом/измененном документе - как раз при репликации...

Добавлено: Gor
Возможно, такая тема многим будет интересна, ну а если она уже поднималась ткните меня туда носом))
https://codeby.net/threads/33879.html

:)
 
N

nvyush

Итак, как только Вася одобрил заявку, Коля получил почтовое уведомление о том что ему пришёл новый документ на одобрение, НО
как только он пытается его открыть система ругается что прав на редактирование у него нет, т.к. Лотусовые базы ещё не среплицировались.
В конце уведомления дописываю что-то вроде "Примечание: если документ не доступен, значит он ещё не реплицировался на Ваш сервер. Репликация производится раз в два часа".
Пытались меня было наклонить, чтоб уведомления рассылались только после репликации, но удалось убедить руководство, что овчинка выделки не стоит.
 
K

Klido

nvy
я ж написал - тупо агент по новым/измененным на каждом серваке - прошла репликация - послали уведомление тем, кто на этом серваке живет...
 
N

nvyush

nvy
я ж написал - тупо агент по новым/измененным на каждом серваке - прошла репликация - послали уведомление тем, кто на этом серваке живет...
Вводная: база нормативной документации, при утверждении документа должна идти рассылка заинтересованным лицам, например, группе "Руководители филиалов". В поле адреса — группа, члены группы раскиданы по разным серверам. Как быть?
 
30.06.2006
141
5
BIT
0
Gor,

По-моему вариант когда сотрудник получает уведомление что ему надо что-то сделать, но фактически он этого не может сделать в корне неверный.

Для пользователя все должно быть прозрачно - получил уведомление по почте, ознакомился, если от него что-то требуется - перешел по ссылке, сделал что надо. Т.е. он не должен знать о какой-то там репликации, что доступ у него будет только через какое-то время и т.д, это не его проблемы. ;-)

Поэтому по-хорошему вам необходимо уведомлять сотрудника уже после того, как ему предоставлен доступ (как реализовать уже сказали выше).

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


nvy,

Вводная: база нормативной документации, при утверждении документа должна идти рассылка заинтересованным лицам, например, группе "Руководители филиалов". В поле адреса — группа, члены группы раскиданы по разным серверам. Как быть?
Можно развернуть группу до конкретных сотрудников и уведомлять каждого после того как данные будут на его сервере.
 
K

Klido

Цитата
Вводная: база нормативной документации, при утверждении документа должна идти рассылка заинтересованным лицам, например, группе "Руководители филиалов". В поле адреса — группа, члены группы раскиданы по разным серверам. Как быть?

Можно развернуть группу до конкретных сотрудников и уведомлять каждого после того как данные будут на его сервере.
именно так
в базе - документы настроек соответствя почтовый сервак-сервак приложений ну или что-то такое...
агент раскручивает группу и проверяет кому посылать в зависимости от сервака
 
30.05.2006
1 345
12
BIT
0
Сложность: надо держать отдельный справочник с именами "домашних" серверов для каждого пользователя. АК не годится, т.к. в филиале м.б. БОЛЕЕ ОДНОГО сервера, СЭД - на одном, почта - на другом
 
A

Akupaka

Сложность: надо держать отдельный справочник с именами "домашних" серверов для каждого пользователя
любая хорошая система должна иметь справочник пользователей, как-то справочник организации, в котором хранится информация о должности пользователя, структуре подразделений и т.п., посему добавить туда нужные поля не составит особого труда.
но проблема и этим может не быть решена, т.к. пользователь может работать не напрямую с сервером, а посредством репликации.
а еще веселая задача - пользователи, которые работают не с одним сервером.
поэтому, эта задача решается только комплексно, для каждого сотрудника/группы отдельно. поэтому и уведомление предложенное nvy весьма небесполезно, но и не решать ее совсем, конечно, минус для системы.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Итак, как только Вася одобрил заявку, Коля получил почтовое уведомление о том что ему пришёл новый документ на одобрение, НО
как только он пытается его открыть система ругается что прав на редактирование у него нет, т.к. Лотусовые базы ещё не среплицировались.
я такую ситуацию достаточно просто разрулил:
Все уведомления у меня не рассылаются сразу, для этого создал отдельную базу куда складываются все эти уведомления, потом агент по изменениям хватает оттуда док, и отсылает его уже как нужно(или от лица сервера или от лица того кто нажал кнопку или....) - прямая работа с mail.box:
этой фичей я убил сразу кодло зайцев:
1) Когда неправильно настроена почта, или отдельный почтовый сервер упал пользователь спокойно продолжает работать на том где стоит СЭД не беспокоясь об уведомлениях впринцыпе
2) Пока зта база не среплицируется на филиал, те не получат уведомления, так как агент там не имеет доков по которым нужно делать уведомления
3) Уникальность сообщения, агент зная кому и от кого слать может игнорить сообщения, когда к примеру тот кто нажал единственный кто и принять должен(нету у него доверенные или ио) - тем самым не слав себе
4) Если есть другое сообщение отменяющее предыдущее по факту выполнения/ошибочного дества/просроченности то умный агент и "отозвать может" и сам из почты удалить
5) Индивидуально настраиваемые форматы сообщения для каждого - агент знает от кого, кому, какой ключ сообщения и т.д. тем самым на лету создавая сообщение хоть для мобильника
......
всё остальное секрета :rolleyes:
 
T

TIA

2) Пока зта база не среплицируется на филиал, те не получат уведомления, так как агент там не имеет доков по которым нужно делать уведомления

Но первоначальная проблема

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

не решается. Т.к. среплицированность БД с уведомлениями вовсе не означает, что отреплицирована БД с документом.
 
K

Kee_Keekkenen

Но первоначальная проблема



не решается. Т.к. среплицированность БД с уведомлениями вовсе не означает, что отреплицирована БД с документом.

по документу уведомления можно проверить факт прихода документа..
на крайняк можно запустить репликацию базы документов..
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
TIA
Но первоначальная проблема

не решается. Т.к. среплицированность БД с уведомлениями вовсе не означает, что отреплицирована БД с документом
еще как решается
эта база в списке конекшена идет последней и есть еще фора, пока агент запустится по модифайтингу
 
T

TIA

еще как решается
Согласен, но не так.

эта база в списке конекшена идет последней и есть еще фора, пока агент запустится по модифайтингу

Вот, проявляются важные детали :KillMe:
А форы у агента нет, он запросто запустится параллельно с репликацией.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
А форы у агента нет, он запросто запустится параллельно с репликацией
агент запускается по факту нового документа, минимальный таймаут это 1 минута, расскажи как это сделать быстрее :)
 
T

TIA

агент запускается по факту нового документа, минимальный таймаут это 1 минута, расскажи как это сделать быстрее
:) Допустим, при репликации первым пришёл новый документ и начался таймаут. Репликация пусть длится 15 мин. Агент, допустим, работает 1 мин и интервал его запуска даже 5 мин. Внимание вопрос, сколько раз за 15 мин. запустится агент? ;) Видите ли, репликация не является атомарной операцией и пока передаются документы, агенты вполне их могут обрабатывать.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Допустим, при репликации первым пришёл новый документ и начался таймаут. Репликация пусть длится 15 мин. Агент, допустим, работает 1 мин и интервал его запуска даже 5 мин. Внимание вопрос, сколько раз за 15 мин. запустится агент? Видите ли, репликация не является атомарной операцией и пока передаются документы, агенты вполне их могут обрабатывать.
всё правильно, но вы забыли, что это последняя база и что агент обрабатывает запрос на документ, который УЖЕ отреплицировался а значит ссылка будет правильная на СУЩЕСТВУЮЩИЙ док
 
T

TIA

то это последняя база и что агент обрабатывает запрос на документ, который УЖЕ отреплицировался а значит ссылка

Бррр. Исходя из цитаты
уведомления у меня не рассылаются сразу, для этого создал отдельную базу куда складываются все эти уведомления, потом агент по изменениям
и контекста проблемы, я так понял, что Вы создаёте отдельный документ в БД с уведомлениями, а сам рабочий документ (у которого по задаче меняется доступ) реплицируется в своей БД. Агент обрабатывает документы в БД с уведомлениями и формирует уже почтовые уведомления в mail.box. Почтовые уведомления имеют ссылки на рабочие документы, через которые пользователь и открывает рабочий документ. Так?
 
Мы в соцсетях:

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