Лучший способ хранить разрешения пользователей? - PullRequest
9 голосов
/ 09 сентября 2010

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

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

Кроме того, сессии, по-видимому, могут редактироваться пользователем ... есть ли более безопасный способ?

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

Я открыт для любых идей. Спасибо.

Ответы [ 3 ]

21 голосов
/ 09 сентября 2010

Прежде всего, пользователь не может редактировать переменные сеанса. Единственное, что сохраняется на компьютере пользователя - это идентификатор сеанса. Этот идентификатор затем используется сервером для получения пар ключ / значение, которые хранятся ТОЛЬКО на сервере. С точки зрения клиента невозможно изменить значения по прихоти.

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

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

Чтобы использовать этот метод, представьте, что мы определяем следующие значения:

CAN_EDIT_SOMETHING        = 1     // Powers of 2
CAN_SEE_SOMETHING_ELSE    = 2
CAN_DO_ADMIN_STUFF        = 4
...                       = 8

Чтобы дать людям несколько разрешений, используйте двоичный ИЛИ

PERMISSIONS = CAN_EDIT_SOMETHING | CAN_DO_ADMIN_STUFF

Чтобы проиллюстрировать, как это работает, мы можем взглянуть на биты:

   0b0001
OR 0b0100
---------
   0b0101

Чтобы проверить, есть ли у кого-то разрешение, используйте двоичное И

if( PERMISSIONS & CAN_EDIT_SOMETHING != 0 ) {
}

Чтобы увидеть, как это работает, мы снова посмотрим на биты

    0b0101
AND 0b0001
----------
    0b0001  // Not equal to 0. They must have that permission!

Последнее преимущество этого метода состоит в том, что он позволяет легко объединять несколько разрешений в «мета-разрешения»

// If both EDIT_SOMETHING and ADMIN_STUFF are tasks that an admin
// can perform, we can combine them easily
//
IS_FULL_ADMIN     = CAN_EDIT_SOMETHING | CAN_DO_ADMIN_STUFF


// We can then use this value exactly as we do any other permission
//
PERMISSIONS       = IS_FULL_ADMIN | CAN_SEE_SOMETHING ELSE

Используйте его, если хотите, но это хороший прием в вашем арсенале.

1 голос
/ 09 сентября 2010

мне кажется ОК!Вы могли бы взглянуть на какое-нибудь программное обеспечение, чтобы улучшить производительность сеанса chache.

Запрос к БД каждый раз не так плох, как кажется!Во-первых, вам, вероятно, все равно нужно подключиться к БД, во-вторых, если вы запрашивали разрешения пользователей при входе в систему, то есть вероятность, что все соответствующие строки находятся в буфере, и ввода-вывода не требуется, в-третьих, запрос для одного разрешения дляодин пользователь будет намного легче, чем запрос всех разрешений для пользователя.

0 голосов
/ 09 сентября 2010

Ваше объяснение модели кажется немного запутанным.Разрешение является продуктом субъекта авторизации и объекта авторизации.Вы действительно храните эти продукты для каждой комбинации предмета и объекта?Это очень неэффективное решение, которым очень трудно управлять.

Кроме того, пользователь может редактировать сеансы, по-видимому,

WTF ????? !!!!

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

Конечно, поиск очень большого массива (не уверенного в фактической точке останова - но в области n = 1000 - но на это влияет множество переменных) может быть значительно медленнее, чем выборка результатов из базы данных.

Трудно сказать, что вы делаете неправильно, не понимая, как работает ваша текущая система.Это один из этих ?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...