2016-10-23 3 views
-2

В это время у меня есть простой раздел входа в систему на мой веб-сайт, из которого администратор может добавлять/редактировать содержимое страницы, добавлять/редактировать страницы или темы. Теперь я думаю о линии в этом проекте, чтобы этот сайт работал так, как нужно. Мне нужно добавить многоуровневую систему пользователей, Я бы подумал, что добавление пользовательского уровня как INT к моим наборам таблиц позволит это, , то на моих страницах, где у меня есть мой вызов "is_logged_in", я мог бы также вызвать уровень пользователя INT и храните его в сеансе. Таким образом, если пользователь настроен на уровень 1 показать ссылки a, если пользователь установили уровень 2 показать ссылки b. или я смотрю на это неправильно?Как я могу изменить систему входа в систему для входа в систему с несколькими уровнями?

+0

Нет, отлично выглядит. Действуй. – arkascha

+0

Идите еще глубже и используйте массивы для хранения разрешений, чтобы вы могли выполнять более гранулированную систему разрешений. – Solrac

+0

Ваше решение в порядке, если оно соответствует вашим потребностям. В какой-то момент вы можете перейти от «уровней» к чему-то более гибкому, например, к «ролям» или «разрешениям» и т. Д. Но нет смысла создавать что-то, что вы еще не используете (см. [YAGNI] (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)). –

ответ

0

Не нужно изобретать велосипед. То, что вы ищете, называется функциональностью списка контроля доступа (ACL). Есть много доступных решений, которые вы можете включить в свой проект. Лично я использую библиотеки Acl от Zend, но есть еще много ароматов.

Как это работает (базовая версия): вы назначаете некоторые роли ACL - например, «admin», «staff», «user», «guest», где «гость» будет вашим анонимным посетителем по умолчанию. Когда пользователь входит в систему, вы сохраняете роль ACL в сеансе пользователя.

Затем вы создаете класс ACL, который назначает эти роли вашим ресурсам. Например. «admin» может читать и редактировать чьи-либо данные, «персонал» может читать данные «admin», «staff» и «user», но редактировать свои собственные и «пользовательские» данные «пользователь» может читать другие «пользовательские» данные, но редактировать его собственные данные.

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

Смежные вопросы