Гостевой доступ и разделение прав на несколько уровней

[Maxim Mirgorodsky]

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

Для начала доведем нашу текущую позицию и имеющийся практический опыт.

Во второй половине 2007 года мы начали работу над версией 4.0. Стояла задача полностью переработать систему авторизации. Что имелось на тот момент? Как таковой базы данных пользователей не было. Любой пользователь мог зайти в чат под любым именем. То есть 100% гостевой доступ. При подключении к серверу у пользователя спрашивалось имя, после ввода которого можно было использовать программу.

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

Как часто происходит, начали со сложного. Реализовали базу данных пользователей, систему регистрации и активации, а чтобы всеми этими функциями не отпугивать новых пользователей, реализовали гостевой доступ. В верхнем правом углу было не 2, а 3 кнопки. В первой был логин (который мог быть "Гость"), во второй отображаемое имя, а в третьей, как и сейчас, состояние. Сообщения в каналах выводились в таком виде: "Отображаемое имя (логин): текст".

При первом же применении новой системы авторизации на практике начался кошмар.. Пользователи не могли самостоятельно понять, что такое регистрация, зачем она нужна, что такое "Гость", что им выбирать. Путались в трех кнопках, не следили за соответствием имени. Стали жаловаться на сложность и запутанность новой авторизации.

Многие проблемы были ожидаемы, и их нужно было как-то решать. Решать так, чтобы не превращать авторизацию в экзамен для пользователя. Авторизация это тот этап, на котором если пользователь столкнется со сложностями, то ему проще будет удалить программу и он никогда не узнает о ее функциональности. Ведь предыдущая версия всех этих проблем была лишена. Да, администраторы получали гибкий инструмент, но пользователи то этого не видят. Они видят только неудобства для себя. Сначала пытались сохранить основные принципы, сделав подсказки и стимулируя правильно пользоваться инструментами новой авторизации. Но потом пришло понимание, что все это не годится, это не в духе CommFort'а. И задача была сформулирована так: пользователь, переходящий с третьей версии должен вообще не почувствовать разницу для себя. Сначала был вырезан гостевой доступ. Зачем пользователю, еще ни разу не использовавшему программу, задавать вопросы об уровне учетной записи? Он не знает, как ему лучше. Программа должна делать этот выбор. Потом была убрана возможность выбора имени (при использовании одной учетной записи). Пользователь должен видеть один единственный его идентификатор - имя. И только тогда он будет следить за его актуальностью и никогда не запутается. И в завершении, была убрана регистрация. Если точнее, то поле ввода пароля (но при включенной активации учеток модераторами это поле оставили по понятным причинам). Пользователь теперь подключившись к серверу видит только поле ввода имени. Он не знает, что введя его, будет автоматически зарегистрирован. Ему постфактум выводится пароль с рекомендацией записать или изменить его. И вот такая авторизация оказалась приемлемой. С ней вопросов не возникнет даже у самого неопытного в компьютерных программах пользователя.

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

И хотелось бы напоследок напомнить об одном очень важном моменте: CommFort - универсальная программа, предназначенная не только для домовых сетей, но и для корпоративных.

[bigbag]

Выложу свои мысли относительно ранее упоминаемой концепции сабжа, вопрос про сложность конкретно.

Как уже было только что сказано, программа должна делать выбор об уровне прав (не пользователь). И мы решили, что программа должна выбирать в сторону регистрации полноценной учетной записи.

Согласен с тем, что пользователя не надо грузить. Он нажимает иконку, пишет ник и может общаться. Сейчас из-за системы банов на крупных серверах это не сразу получается, нужно ждать разрешения зайти ещё.
--
1. Intro.
Мы оставляем существующую систему учётных записей, она вполне удобна для идентификации и наказаний, но расширяем свойства самих учётных записей. Каждая запись получает дополнительный параметр -- role-- число, за которым на сервере администратор закрепил определённый профиль.

2. Администратор сервера.
Администратор работает со строками в настройках: гость, участник, модератор, вип, вип-2, hurr durr. Администратор создаёт аналогичные профили с произвольным набором разрешённых действий для каждого. Числа -- для программы, о них никто не знает.
Чтобы всё сразу работало из коробки, как раньше, на сервере уже есть предопределённый набор: участник, модератор, модератор main, администратор, бот. Профиль по умолчанию (который программа присваивает всем новым пользователям: участник, с соотвествующим набором разрешений писать куда угодно, как в 5.70). Администратор волен сделать любой профиль дефолтным. Создать для этого Гость, например, с ограниченными возможностями общения. Сервер же регистрирует всех, время жизни записи в базе только может различаться.

3. Модераторы.
Некоторые модераторы и боты теперь имеют возможность управления профилями, получая новую строчку в контекстном меню пользователя и в менеджере базы данных в стиле:

Код: Выделить всё

Профиль -> [ ]read only [x]гость [ ]участник [ ]вип

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

4. Пользователи.
Для пользователей изменения пройдут безболезненно: в окошке информации появится дополнительное поле с указанием профиля.

5. Примеры.

5.1 Окно настройки прав ptokax, самого распространённого dc-хаба под windows с продвинутым чатом.
--
При грамотном проектировании модели, её внедрение не привнесёт дополнительных проблем настройки для ленивых адинистраторов (в чате и вовсе не заметят), но даст чертовски гибкий инструмент остальным.
Но в крупных чатах, где за день проходят тысячи человек, установка жёстких ограничений для профиля по умолчанию создаст сложности для модераторов, на первое время, во всяком случае. Но хуже не станет, тем не менее.

[ForestM]

разделение прав следует ждать в новых версиях?? или это просто обсуждения?

[bigbag]

ForestM
Обсуждение же, пишите свои мысли о преимуществах/недостатках подобного подхода.

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

[Bomber]

На мой взгляд очень своевременно подняли эту тему.Ограничение в правах не очень сильно отразится на комфорте обычных пользователей,особенно если модераторы не ленивые...