Imake, спасибо за ссылки, буду разбираться. Что касается предложенного админского решения, я его предлагал админу еще до размещения поста. Ответ прост - дизайн names.nsf трогать низзя (предыдущей программер умудрился случайно убить адресную книгу, еле восстановили, теперь трогать ее - табу). К тому же одни пользователи привыкли авторизоваться по лотусовому имени, другие по емэйл, а против топ-менеджеров переть трудно...
-
15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby
За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.
На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.
Запись на курс до 25 апреля. Получить промодоступ ...
стесняюсь спросить, а что думают сертифицированные (ваши) админы про, например:
The number of ways that a user can authenticate against the Web server has a direct impact on security. The more name variations that are allowed, the more open the Web site is to a dictionary attack. For example, if last name is a valid user name, in a large company it would be fairly easy to find a "Smith" or an "Adams." A hacker could easily try to gain access to the site with any number of common last names.
Налицо попытка спихнуть на девелоперов базовые принципы безопасности, которыми лотус прикрывается в целом
это вообще жесть, убить на работающем сервере её достаточно затруднительно
трогать, конечно, АК нежелательно, но... надо трезво оценивать ситуацию - наваяете примочку в аутентификацию - как бы больше отгребать потом не пришлось, если что-то пойдет не так...
этих юзеров можно поместить в отдельную NAB и её дизай менять, подключить через DA
здесь, один из участников описывал свои экзерцизы (с дублированием и "расщеплением" аутентификации), используя DA + AD (на месте АД м.б. любой ЛДАП, в данном случае)
решение было не изящным, но он его заимплементил и остался удовлетворен
здесь, один из участников описывал свои экзерцизы (с дублированием и "расщеплением" аутентификации), используя DA + AD (на месте АД м.б. любой ЛДАП, в данном случае)
решение было не изящным, но он его заимплементил и остался удовлетворен
кстати, норм вариант...
а вообще задача от боссов "Ужесточить/запретить кому-то доступ с такими-то параметрами" требует ответа "Нет проблем, но (!) теперь ВСЕ должны логин вводить ТОЛЬКО мыло(или фулнейм, или как решите)", в случае недовольства - ссылка на задачу...
это вообще жесть, убить на работающем сервере её достаточно затруднительно
Ну убил это так, образно, юзеры все потерлись.
Попробую предложить этот вариант
а мне ещё интересен мой бредовый вариант с фолдером и ограничением доступа на него группе - сработает ли? жаль сейчас некак проверить, но под клиентом точно работает отлично, а вот под вэб - хз...
в этом варианте я бы на каждую форму, которую нужно видеть через веб вставил бы на WebQueryOpen агентика,
который бы и делал проверку на принадлежность юзера к какой-то группе, ну и если не принадлежит то отваливался бы по ошибке или рисовал тег "нет доступа"
добавлю контекстную ремарку. как у меня сделано в магазе.
сначала регится юзвер в отдельной базе. там проверяем всякие поля, одинаковые емайлы, имена и прочее. можно проверять и ваши условия.
на мыло приходит текст с сылкой. по ссылке запускаем агент с id который переносит данные а DA, рефрешит names для автологина и пр.
и в плане спама удобно и условия можно понаставить.
сначала регится юзвер в отдельной базе. там проверяем всякие поля, одинаковые емайлы, имена и прочее. можно проверять и ваши условия.
на мыло приходит текст с сылкой. по ссылке запускаем агент с id который переносит данные а DA, рефрешит names для автологина и пр.
и в плане спама удобно и условия можно понаставить.
Обучение наступательной кибербезопасности в игровой форме. Начать игру!