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

Question

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

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

Участник может иметь 1 или более уровней.

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

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

Таблицы:

Group
 - group_id (P)
 - group_name

Group_User
- group_id (F)
- user_id

И как связь с ООП подход?

ООП Дизайн Я придумал:

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'] в базе данных?

Answer 1

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

Я бы рассмотрел , как другие решают проблему , есть библиотеки и компоненты, такие как Zend_Acl , которые могут помочь значительно облегчить задачу и избежать некоторых базовых проблем. вы встретите При этом ДЕЙСТВИТЕЛЬНО исследуйте идеи, которые у вас есть, я имею в виду, что это здорово, что вы делаете, и я вовсе не говорю это, чтобы вас обескуражить. Я начал по тому же пути, по которому вы идете, много лет назад.

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

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

Answer 2

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

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

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

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

Answer 3

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

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