Стоит задача сделать так, чтобы пользователи не могли редактировать свой ростер.
Редактирование ростера происходит централизованно на LDAP-сервере.
Настроил модуль mod_shared_roster_ldap.
Создал пользователя, добавил его в группу. Логинюсь из под mirand-ы. Все проходит нормально, пользователь переходит в online, загружается ростер.
Потом в mirand-е вручную перемещаю пользователей (оказывается почему-то возможно это делать), удаляю группы...
В общем, могу полностью исковеркать ростер....
Состояние ростера восстанавливается только если удалять какой-либо контакт в ростере. При этом он автоматически подгрузится заново и заново подгрузится группа этого контакта и все (для этого контакта) восстановится в исходный вид.
Подскажите это нормально поведение??
Можно как-то это исправить??
Мои настройки:
{mod_shared_roster_ldap,
[
{ldap_base, "dc=...,dc=ru"},
%% Roster Filter
{ldap_rfilter, "(objectClass=jabberGroup)"},
%% Group Filter
{ldap_gfilter, "(&(objectClass=jabberGroup)(cn=%g))"},
{ldap_groupattr, "cn"},
{ldap_groupdesc, "description"},
{ldap_memberattr, "jabberUid"},
{ldap_memberattr_format, "%u"},
%% User Filter
{ldap_ufilter, "(&(objectClass=jabberPerson)(uid=%u)(jabberAccountEnabled=TRUE))"},
{ldap_useruid, "uid"},
{ldap_userdesc, "cn"},
%% Additional Filter
{ldap_filter, ""},
{ldap_auth_check, on},
{ldap_group_cache_validity, 30},
{ldap_user_cache_validity, 30}
]
}
Это нормальное поведение. 1.
Это нормальное поведение.
1. Невозможно запретить клиенту вообще что бы то ни было на его стороне. Например, конкретно Миранда может не удалить пользователя из ростера (это операция на стороне сервера), а просто спрятать его (т.е. выставить ему в БД флаг "скрыт" и не отображать его) - тогда сервер будет отправлять полный ростер, а клиент будет отображать только его часть. Пользователь может переименовать контакт. Может создать метаконтакт (миранда - многопротокольный клиент). Сервер никак в это не вмешивается.
2. Кроме того, сервер не запрещает пользователю менять контакт в ростере (т.е. назначать отображаемое имя и в какие группы он входит). Вообще создание общего ростера происходит так: сначала для этого пользователя строится его индивидуальный ростер, потом каждый контакт общего ростера ищется в этом индивидуальном, и если он уже там, его не трогают, добавляют только отсутствующие. Сервер лишь гарантирует, что в ростере будут все, а порядок там он не наводит. Ну, и ещё управляет видимостью (подпиской).
Если это Вам не подходит, у Вас лишь одна возможность: менять клиент (или писать свой, чтобы мог только то, что Вы хотите). Изменение серверной стороны не может полностью решить Вашу проблему, даже если захотеть.
Большое спасибо! Подскажите
Большое спасибо!
Подскажите пожалуйста еще один момент: индивидуальный ростер пользователя хранится в базе данных миранды или в базе данных EJabberd??
Если в базе данных EJabberd, то есть ли какая-либо возможность управлять этим ростером?? Может как-то запрещать команды на его изменение или может как-то скриптом «обнулять» его (например, что-нибудь типа router-filter.xml в Jabberd2 – там можно с помощью XPath-выражений фильтровать определенные команды (хотя на тот момент, когда я пробовал Jabberd2, эта функция корректно не работала)).
И еще вопрос возник: если я использую авторизацию через LDAP, модули mod_vcard_ldap, mod_shared_roster_ldap, то какие данные пользователя продолжают храниться в базе данных EJabberd??
Индивидуальный ростер - в БД
Индивидуальный ростер - в БД ejabberd. В БД Миранды хранятся настройки нонтактов, которые применяются поверх получаемого с сервера ростера (который представляет собой сумму индивидуального и общего ростеров).
Честно говоря, я никогда не задавался целью блокировать какие-нибудь команды серверу. Поэтому, боюсь, я тут не советчик. Но даже при условии неправильной работы фильтра можно попробовать это с другой стороны - ведь можно попробовать сделать БД с индивидуальными ростерами read-only (сразу говорю - не имею представления как, и может быть, это не сработает, просто направление).
При аутентификации LDAP и mod_vcard_ldap в БД сервера хранится индивидуальный ростер. Данные о именах и паролях, а также о никах и телефонах в БД не сохраняются.