CommFort

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

Внешняя авторизация.

Собственно серверным плагинам не разрешено получить пароли. Поэтому какая либо нормальная реализация с проверкой на AD или в БД биллинга сразу не возможна.

Приходят на ум всякие извращения начиная от укащания пароля в поле запроса активации до запроса пароля в ЛС или авторизация на боте специальной командой (вроде NickServ в IRC). Но это всё херня, ибо даже авторизовав пользователя таким образом мы не сможем сменить ему пароль уч. записи (или сможем?) да и лишние телодвижения... Многие просто этого не поймут.

Ещё один вариант — в обратном порядке. Биллинг (или другое нечто) при создании пользователя создаёт его и в коммфорте. Это возможно. Но опять же откуда ни возьмись — ограничения. Самое из них не понятноя для меня: невозможно сделать так, чтобы учётки не удалялись по времени неиспользования. Именно из-за этого нет смысла рассматривать схему с созданием учётки от внешнего биллинга потому, что она всё равно удалится (максимум 90 дней). Да и не лучший это вариант, так как во всех нормальных системах пароли так или иначе захешированы, что теоретически считается необратимым.

Исходя из всего этого самой нормальной схемой получается NickServ для коммфорта. Который будет всем вошедшим запрещать публикацию сообщений, но позволит пользователю авторизоваться с его текущим ником с паролем, который он укажет боту по спец команде. По истечении времени или не правильных попытках — бан от сервера на какое-то время. Но тогда всё равно остаётся вопрос с паролем на чат. Он может быть выбран пользователем любым, так как ему нужно будет всё равно пройти процесс регистрации. Так же надо будет запрашивать подтверждение пароля на боте если пользователь не заходил в чат тот промежуток времени, который указан для удаления учётки (нужно отслеживать посещения).

Какие мысли будут по алгоритму? Поправьте, если я в чём-то не прав.

PS а может ли серверный плагин назначать права пользователю? В доках вроде не нашёл...

Собственно серверным плагинам не разрешено получить пароли.

Не только плагинам. Пароль в открытом виде вообще не уходит дальше клиентского ПК. Сервер оперирует только хэш-кодами.

Который будет всем вошедшим запрещать публикацию сообщений, но позволит пользователю авторизоваться с его текущим ником с паролем, который он укажет боту по спец команде.

Это вполне возможно реализовать. При попытке публикации сообщения в канал пользователя не прошедшего авторизацию плагина сообщеие должно блокироваться одним из двух методов:

1) Премодерация.
2) Накладываться ограничение (недолгое, не более чем минут на 5, чтобы не засорять бан-лист).

При этом плагин должен отправить сообщение пользователю с инструкциями по прохождению авторизации плагина.

PS а может ли серверный плагин назначать права пользователю? В доках вроде не нашёл...

Нет, управление правами возможно только в ручном режиме.

Maxim Mirgorodsky писал(а): Не только плагинам. Пароль в открытом виде вообще не уходит дальше клиентского ПК. Сервер оперирует только хэш-кодами.

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

Maxim Mirgorodsky писал(а):Это вполне возможно реализовать. При попытке публикации сообщения в канал пользователя не прошедшего авторизацию плагина сообщеие должно блокироваться одним из двух методов:

1) Премодерация.
2) Накладываться ограничение (недолгое, не более чем минут на 5, чтобы не засорять бан-лист).

При этом плагин должен отправить сообщение пользователю с инструкциями по прохождению авторизации плагина.

Премодерация никуда не годна ввиду того, что работает только в каналах, где находится бот. Только ограничением. Причём опять же надо изворачиваться, так как бот не умеет снимать ограничение. Что делать, если пользователь авторизовался в ту же секунду, как вошёл?

Maxim Mirgorodsky писал(а): Нет, управление правами возможно только в ручном режиме.

И опять ограничения.


Я счиаю, что вам нужно меньше ограничивать людей. Хотя бы API сделайте более свободным, если уж следуя каким-то странным мотивам, не получается сделать настройки самого чата более гибкими. А так получается и разработчики плагинов ограничены. Вот к примеру скажите на милость зачем эта хитрость с тем, чтобы серверный плагин сидел в каналах? Почему он не может получать просто _все_ события так, как он получает подключения пользователей и создания учёток? Почему наложение ограничения есть, а снятия нет? Почему создать и удалить пользователя можно, а изменить нельзя? Почему нельзя сделать бессрочной регистрацию уч. записи?
Думаю, что все эти вопросы вам следует рассмотреть очень пристально.

Получается лучшее, что мы можем сделать будет выглядеть так:

- Пользователь регистрируется и входит с любым паролем.
- Бот накладывает ограничение (к примеру на публикацию во всех публичных каналах) на какой-то срок и высылает инструкции по авторизации.
- Пользователь авторизуется паролем (при этом его пароль, возможно от каких-то важных служб, попадает В ЛОГ, который теперь и поправиль нельзя). И ... по прежнему ничего не может сделать, так как срок ограничения не прошёл.
---- при этом не авторизовавшись он вполне может ходить в скрвтве каналы, общаться в приватах и слать ЛС (спамить ботом)
---- если сделать срок ограничения коротким и продлевать его по таймеру — в канале будет спам сообщениями, что пользователь наказан. Плюс нагрузка лишняя из-за таймера.

Вот такая хромая на обе ноги система. Плюс ещё и нужно контролировать заходил ли пользователь (не удалилась ли его учётка) и переспросить потом авторизацию, если удалилась.

Как по мне — это извращения.

Хотя бы API сделайте более свободным

Планируем существенную модернизацию механизма работы плагинов в новой версии.

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

С целью сохранения приватности.

Почему наложение ограничения есть, а снятия нет?

Для этого плагину будет необходим полный список всех ограничений. Постараемся реализовать взаимодействие с ним в 5.00.

Почему создать и удалить пользователя можно, а изменить нельзя?

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

Почему нельзя сделать бессрочной регистрацию уч. записи?

Абсолютно бессрочная точно не будет, потому что база данных имеет ограниченные объемы (для контроля нагрузки).

Как по мне — это извращения.

Верно, речь шла только о запрете общения в определенных каналах. В следующей версии планируется новый тип ограничения - запрещение приватной переписки. Что в совокупности с запрещением публикации во всех каналах полностью отключит возможность текстовых публикаций. Однако, доставку пароля придется перекладывать на отдельное приложение (клиентский плагин). Что положительно скажется и на безопасности хранения пароля.

Maxim Mirgorodsky писал(а):Верно, речь шла только о запрете общения в определенных каналах. В следующей версии планируется новый тип ограничения - запрещение приватной переписки. Что в совокупности с запрещением публикации во всех каналах полностью отключит возможность текстовых публикаций. Однако, доставку пароля придется перекладывать на отдельное приложение (клиентский плагин). Что положительно скажется и на безопасности хранения пароля.

Т.е. клиентский плагин может получить пароль в чистом виде?

PS в чём же клиентская часть безопаснее сервра? Я этого утверждения не понимаю. Скомпромитировать клиентскую часть или трафик от неё к серверу на много проще, чем сервер-серверное взаимодействие при проверке пароля с сервера чата на сервер AD или биллинга, что вообще может быть в пределах _одного_ сервера.

PS в чём же клиентская часть безопаснее сервра? Я этого утверждения не понимаю. Скомпромитировать клиентскую часть или трафик от неё к серверу на много проще, чем сервер-серверное взаимодействие при проверке пароля с сервера чата на сервер AD или биллинга, что вообще может быть в пределах _одного_ сервера.

Имелся ввиду аргумент:
- Пользователь авторизуется паролем (при этом его пароль, возможно от каких-то важных служб, попадает В ЛОГ, который теперь и поправиль нельзя)

Если доставку пароля переложить на клиентский плагин, в лог ничего не попадет.

Т.е. клиентский плагин может получить пароль в чистом виде?

Нет, имелся ввиду пароль дополнительной авторизации (которым владеет серверный плагин), пароль учетной записи CommFort тут ни при чем.

Maxim Mirgorodsky писал(а): Нет, имелся ввиду пароль дополнительной авторизации (которым владеет серверный плагин), пароль учетной записи CommFort тут ни при чем.

Я не понимаю смысл, можно пример, хотя бы в двух словах?

Серверный плагин осуществляет дополнительную авторизацию (или регистрацию). Доставка пароля для дополнительной авторизации осуществляется с помощью клиентского плагина. То есть клиентский плагин открывает окно в котором просит указать дополнительный пароль и передает его средствами своего протокола серверному плагину, после чего серверный плагин снимает все ограничения с клиента.

Конечно, для клиентов схема из двух паролей будет сложной, но такая схема работать будет.

Maxim Mirgorodsky писал(а):Серверный плагин осуществляет дополнительную авторизацию (или регистрацию). Доставка пароля для дополнительной авторизации осуществляется с помощью клиентского плагина. То есть клиентский плагин открывает окно в котором просит указать дополнительный пароль и передает его средствами своего протокола серверному плагину, после чего серверный плагин снимает все ограничения с клиента.

Конечно, для клиентов схема из двух паролей будет сложной, но такая схема работать будет.

Работать будет. но мне очень интересно вот тут:

после чего серверный плагин снимает все ограничения с клиента

Как же он снимет эти ограничения?

В случае реализации ограничения премодерацей - прекратит премодерацию.

Снятие банов будет возможно в плагинах только пятой версии.

Maxim Mirgorodsky писал(а):В случае реализации ограничения премодерацей - прекратит премодерацию.

Снятие банов будет возможно в плагинах только пятой версии.

А если плагин будет «сидеть» во многих публичных каналах (с целью премодерации), это сильно скажется на производительности сервера?

Т.е. фактически будет проверяться каждое сообщение на принадлежность пользователю.

И ещё вопрос — в каком виде плагин получит картинку?

А если плагин будет «сидеть» во многих публичных каналах (с целью премодерации), это сильно скажется на производительности сервера?

В зависимости от оптимальности реализации самой функции премодерации в плагине.

И ещё вопрос — в каком виде плагин получит картинку?

Верно, в этом проблема. Картинки через премодерацию не проходят вообще.

Maxim Mirgorodsky писал(а): Верно, в этом проблема. Картинки через премодерацию не проходят вообще.

Подводя итог.
Значит всё таки возвращаемся к тому, что самый эффективный (и, по сути, единственный) вариант это:

Запрещать публикацию во всех общих каналах на короткий срок около 5 минут.
Отсылать инструкцию по авторизации.
Ждать авторизации и при успехе сообщить и больше ничего не делать.
При неудаче отключить от чата на тоже короткий срок.

Премодерация не подходит из-за:
- потенциальной высокой нагрузки при большом трафике
- необходимость следить за созданием каналом и засылать в них бота (а так же выходить из канала с последним пользователем, иначе каналы будут жить вечно и плодиться и плодиться)
- и из-за того, что не ограничивает публикацию картинок

И всё равно остаётся проблема с приватами, скрытыми каналами и ЛС, так как их запретить ограничением нельзя.

Что ж. Выглядит всё не очень радужно и я искренне надеюсь, что API в пятой версии будет более нормальным без странных и, как по мне, не логичных, ограничений использования.

Спасибо за дискуссию, жаль больше ни кто не поучаствовал

UPD Плагин сможет удалить уч. запись если она сейчас онлайн?

Yaroslav писал(а): Спасибо за дискуссию, жаль больше ни кто не поучаствовал

я следил, очень познавательно было почитать.

UPD Плагин сможет удалить уч. запись если она сейчас онлайн?

Да.