mysql — Реализация контроля доступа на основе ролей в приложении php

Question

mysql — Реализация контроля доступа на основе ролей в приложении php

Я работал над приложением PHP для моего колледжа, которое требует контроля доступа на основе ролей. Подход, который я использовал, заключался в создании отдельного пользователя MySQL для каждой роли. Таким образом, у каждой роли был отдельный пользователь БД. Каждый из этих пользователей БД имел права на минимальный набор таблиц, который требовался для роли.

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

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

Это был мой первый живой проект, поэтому у меня не было большого опыта в плане реализации настоящего проекта.

2

mysql php project roles web-application-project

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Если вы не являетесь хостером, вы, вероятно, не хотите создавать пользователей базы данных динамически с помощью сценариев. Думаю об этом:

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

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

users( id:pk, name )
roles( id:pk, name )
permissions( id:pk, key, description )
permission_role( permission_id:fk, role_id:fk )
role_user( role_id:fk, user_id:fk )

У вас есть три вещи:

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

Это базовая настройка. Другие таблицы — это просто вспомогательные таблицы для объединения частей.

Ваш код обрабатывает все остальное. Настройте (или лучше больше) класс, который делает тяжелую работу. Затем передайте экземпляр вашего ACL вашему классу User (конечно, возможны и другие реализации. См. Внизу поста).

<?php

class Acl implements AclInterface {

public function hasPermissionTo( $action )
{
// Query DB and check if a record exists
// in the role_user table where the
// user_id matches with the current user
// and join the role_id with `roles` and then
// with `permission_role` to see if the user
// is permitted to perform a certain action
}

}

class User {

protected $acl;

public function __construct( AclInterface $acl )
{
$this->acl = $acl;
}

public function hasPermissionTo( $action )
{
return $this->acl->hasPermissionTo( $action );
}

}

Вы должны получить основную концепцию. Фактическая реализация зависит от вас. Вещи, которые вы можете рассмотреть:

Вы хотите, чтобы ваш ACL был частью вашего User точнее автономный компонент?
Как вы хотите передать текущего пользователя в ACL? Вы хотите передать экземпляр текущего пользователя в ACL или, вернее, только идентификатор пользователя?

Эти вопросы зависят от того, что вам нравится и от вашей архитектуры.
Удачного кодирования!

3