Гостевой доступ и разделение прав на несколько уровней
Добавлено: 06:34, 09.04.2013
В одной из тем снова поднялся вопрос об уровнях прав. Создаем данную тему, чтобы объединить все обсуждения, касающиеся гостевого доступа и уровней прав.
Для начала доведем нашу текущую позицию и имеющийся практический опыт.
Во второй половине 2007 года мы начали работу над версией 4.0. Стояла задача полностью переработать систему авторизации. Что имелось на тот момент? Как таковой базы данных пользователей не было. Любой пользователь мог зайти в чат под любым именем. То есть 100% гостевой доступ. При подключении к серверу у пользователя спрашивалось имя, после ввода которого можно было использовать программу.
Требовалось защитить модераторские права, сделать возможным надежный бан (при включенной активации), при всем при этом не усложняя программу для обычных пользователей.
Как часто происходит, начали со сложного. Реализовали базу данных пользователей, систему регистрации и активации, а чтобы всеми этими функциями не отпугивать новых пользователей, реализовали гостевой доступ. В верхнем правом углу было не 2, а 3 кнопки. В первой был логин (который мог быть "Гость"), во второй отображаемое имя, а в третьей, как и сейчас, состояние. Сообщения в каналах выводились в таком виде: "Отображаемое имя (логин): текст".
При первом же применении новой системы авторизации на практике начался кошмар.. Пользователи не могли самостоятельно понять, что такое регистрация, зачем она нужна, что такое "Гость", что им выбирать. Путались в трех кнопках, не следили за соответствием имени. Стали жаловаться на сложность и запутанность новой авторизации.
Многие проблемы были ожидаемы, и их нужно было как-то решать. Решать так, чтобы не превращать авторизацию в экзамен для пользователя. Авторизация это тот этап, на котором если пользователь столкнется со сложностями, то ему проще будет удалить программу и он никогда не узнает о ее функциональности. Ведь предыдущая версия всех этих проблем была лишена. Да, администраторы получали гибкий инструмент, но пользователи то этого не видят. Они видят только неудобства для себя. Сначала пытались сохранить основные принципы, сделав подсказки и стимулируя правильно пользоваться инструментами новой авторизации. Но потом пришло понимание, что все это не годится, это не в духе CommFort'а. И задача была сформулирована так: пользователь, переходящий с третьей версии должен вообще не почувствовать разницу для себя. Сначала был вырезан гостевой доступ. Зачем пользователю, еще ни разу не использовавшему программу, задавать вопросы об уровне учетной записи? Он не знает, как ему лучше. Программа должна делать этот выбор. Потом была убрана возможность выбора имени (при использовании одной учетной записи). Пользователь должен видеть один единственный его идентификатор - имя. И только тогда он будет следить за его актуальностью и никогда не запутается. И в завершении, была убрана регистрация. Если точнее, то поле ввода пароля (но при включенной активации учеток модераторами это поле оставили по понятным причинам). Пользователь теперь подключившись к серверу видит только поле ввода имени. Он не знает, что введя его, будет автоматически зарегистрирован. Ему постфактум выводится пароль с рекомендацией записать или изменить его. И вот такая авторизация оказалась приемлемой. С ней вопросов не возникнет даже у самого неопытного в компьютерных программах пользователя.
Вообще, уровни прав и гостевой доступ - это более обширная тема. Как уже было только что сказано, программа должна делать выбор об уровне прав (не пользователь). И мы решили, что программа должна выбирать в сторону регистрации полноценной учетной записи. А можно повернуть и иначе - программа может выбирать для всех гостевой доступ с ограниченными правами. Тут мы имеем плюсы и минусы совершенно другого характера. Их можно долго обсуждать. Там неизбежно поднимутся и смежные вопросы вроде идентификации, системы ограничений (надежных банов), защиты от атак и прочего. Есть что обсудить.
И хотелось бы напоследок напомнить об одном очень важном моменте: CommFort - универсальная программа, предназначенная не только для домовых сетей, но и для корпоративных.
Для начала доведем нашу текущую позицию и имеющийся практический опыт.
Во второй половине 2007 года мы начали работу над версией 4.0. Стояла задача полностью переработать систему авторизации. Что имелось на тот момент? Как таковой базы данных пользователей не было. Любой пользователь мог зайти в чат под любым именем. То есть 100% гостевой доступ. При подключении к серверу у пользователя спрашивалось имя, после ввода которого можно было использовать программу.
Требовалось защитить модераторские права, сделать возможным надежный бан (при включенной активации), при всем при этом не усложняя программу для обычных пользователей.
Как часто происходит, начали со сложного. Реализовали базу данных пользователей, систему регистрации и активации, а чтобы всеми этими функциями не отпугивать новых пользователей, реализовали гостевой доступ. В верхнем правом углу было не 2, а 3 кнопки. В первой был логин (который мог быть "Гость"), во второй отображаемое имя, а в третьей, как и сейчас, состояние. Сообщения в каналах выводились в таком виде: "Отображаемое имя (логин): текст".
При первом же применении новой системы авторизации на практике начался кошмар.. Пользователи не могли самостоятельно понять, что такое регистрация, зачем она нужна, что такое "Гость", что им выбирать. Путались в трех кнопках, не следили за соответствием имени. Стали жаловаться на сложность и запутанность новой авторизации.
Многие проблемы были ожидаемы, и их нужно было как-то решать. Решать так, чтобы не превращать авторизацию в экзамен для пользователя. Авторизация это тот этап, на котором если пользователь столкнется со сложностями, то ему проще будет удалить программу и он никогда не узнает о ее функциональности. Ведь предыдущая версия всех этих проблем была лишена. Да, администраторы получали гибкий инструмент, но пользователи то этого не видят. Они видят только неудобства для себя. Сначала пытались сохранить основные принципы, сделав подсказки и стимулируя правильно пользоваться инструментами новой авторизации. Но потом пришло понимание, что все это не годится, это не в духе CommFort'а. И задача была сформулирована так: пользователь, переходящий с третьей версии должен вообще не почувствовать разницу для себя. Сначала был вырезан гостевой доступ. Зачем пользователю, еще ни разу не использовавшему программу, задавать вопросы об уровне учетной записи? Он не знает, как ему лучше. Программа должна делать этот выбор. Потом была убрана возможность выбора имени (при использовании одной учетной записи). Пользователь должен видеть один единственный его идентификатор - имя. И только тогда он будет следить за его актуальностью и никогда не запутается. И в завершении, была убрана регистрация. Если точнее, то поле ввода пароля (но при включенной активации учеток модераторами это поле оставили по понятным причинам). Пользователь теперь подключившись к серверу видит только поле ввода имени. Он не знает, что введя его, будет автоматически зарегистрирован. Ему постфактум выводится пароль с рекомендацией записать или изменить его. И вот такая авторизация оказалась приемлемой. С ней вопросов не возникнет даже у самого неопытного в компьютерных программах пользователя.
Вообще, уровни прав и гостевой доступ - это более обширная тема. Как уже было только что сказано, программа должна делать выбор об уровне прав (не пользователь). И мы решили, что программа должна выбирать в сторону регистрации полноценной учетной записи. А можно повернуть и иначе - программа может выбирать для всех гостевой доступ с ограниченными правами. Тут мы имеем плюсы и минусы совершенно другого характера. Их можно долго обсуждать. Там неизбежно поднимутся и смежные вопросы вроде идентификации, системы ограничений (надежных банов), защиты от атак и прочего. Есть что обсудить.
И хотелось бы напоследок напомнить об одном очень важном моменте: CommFort - универсальная программа, предназначенная не только для домовых сетей, но и для корпоративных.