Уровни пользователей и архитектура ООП

Я разрабатываю систему входа для бэкэнд.

Для выполнения определенной задачи будет создано несколько пользовательских уровней/разрешений.

Элемент может иметь 1 или более уровней.

Какая лучшая архитектура для этого?

Я пришел с этим решением:

Таблицы:

Group
 - group_id (P)
 - group_name

Group_User
- group_id (F)
- user_id

А как связь с ООП?

OOP Design Я придумал:

class User {

private $privateSalt = "Don't Tell Anyone! Q£$£$^$";

public function newAccount($email, $password, $firstName, $lastName) { }

public function login($email = 0, $password = 0) { }

private function _setSession($data) {
    $_SESSION['logged_in'] = true;
    $_SESSION['member_id'] = $data['member_id'];
    $_SESSION['email'] = $data['email'];
    $_SESSION['first_name'] = $data['first_name'];
}

public function logout() { }

public function isLoggedIn() { }

}

Нет необходимости объявлять данные пользователя в свойствах ООП, потому что я сохранил их в сеансе? Также, если пользователь обновляет страницу, рекомендуется снова проверить пользователя $_SESSION ['member_id'] на базу данных?

ОТВЕТЫ

Ответ 1

Система входа в систему на самом деле довольно легко сделать, но очень сложно сделать все хорошо. Внедрение mecanisms восстановления пароля, администрирование учетной записи пользователя для пользователей и администраторов, mutliple ролей, которые могут быть добавлены и отредактированы, все это, конечно же, должно быть сделано безопасным способом. Добавьте к этому OAuth и OpenID, системы входа в систему - одна из самых сложных частей многих современных приложений.

Я хотел бы рассмотреть как другие решили проблему, есть библиотеки и компоненты, такие как Zend_Acl, которые могут облегчить задачу и избежать некоторых основных проблем, с которыми вы столкнетесь. Это, как говорится, исследуйте идеи, которые у вас есть, я имею в виду, что это здорово, что вы делаете, и я вовсе не говорю об этом, чтобы отговорить вас. Я начал с того же самого точного пути, что и вы, много лет назад.

Сказав это, у меня есть несколько вопросов, чтобы спросить о вашем новом дизайне. Функция newAccount - это единственные параметры, необходимые для этой функции? Вы можете рассмотреть возможность передачи объектов в функции, для которых требуется множество параметров, таким образом вы можете воспользоваться типом намека. Функция login(), почему параметры установлены на значение по умолчанию 0? Действительно ли это значения по умолчанию для этой функции? На первый взгляд, может быть, лучше будет $email = null и $password = null, но может ли один логин без email/password? Если ваша прикладная логика полагается на то, что эти значения установлены, нормально иметь сигнатуру функции, которая обеспечивает соблюдение логики. Я считаю, что это здорово, хотя и поддерживайте инициативу и любопытны.

Счастливое кодирование, друг

Ответ 2

Чтобы ответить на второй вопрос: я не знаю, почему вы хотите проверить $_SESSION['member_id']

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

Ответ 3

Я предполагаю, что вы хотите, это не столько логин script, сколько архитектура для управления правами пользователя.

Вход script (и самонастраивание разрешений) должен быть довольно простым. Ссылка Stef должна быть полезна для этого.

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

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