Реализация прав доступа

@AlxBtrd · Регистрация: 14.08.2014

Студворк — интернет-сервис помощи студентам

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

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

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

Варианта у меня 2
1й и временно реализованный - Группы.
Создаётся группа с уникальным ID, в таблице группы присутствуют ячейки отвечающие за права.
В настройках группы можно эти права регулировать. Например add_post - 1 и пользователь может добавлять материалы. 0 и не может. Сейчас таких прав ~8, планируется примерно до 20ти.

В настройках профиля пользователя, ему присваивается идентификатор группы.
При обращении к странице, движок пытается достать ID группы, если она существует - узнаёт права и определяет переменные доступа.
На всякий случай если группы не существует - будут установлены гостевые переменные.

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

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

Дефолтно движок обязан иметь как минимум 2 группы - пользователи и администраторы.
Если удалить случайно (дада, но ведь всякое может случиться!) в MyAdmin ячейки таблицы, появятся ошибки в тех местах сайта, где есть условия "если группа == id, то", потому что таблицы не будет существовать.

Хотя такой подход конечно идеологически не правильный и стоит использовать переменные определённые в начале движка, но может понадобиться например создать группу VIP/Модератор и показывать принадлежность пользователя этой группе если он в ней состоит, а создавать настройку определяющую показывать ли группу в профиле ради 2х групп может быть не допустимо.

Ещё пугает реализация групп как в DLE например. Где такие статусы как Гость и Заблокированный пользователь являются группами.
Выскажитесь на этот счёт, как по вашему, должна ли присутствовать возможность динамически (прямо из админки) настраивать права гостей (всех НЕ пользователей) или достаточно установки переменных в начале движка?

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

2й - Настройки непосредственно в таблице пользователя.
То есть тот же выпадающий список галочек, но только на странице управления пользовательской страницей.

Ячейки хранятся при таком подходе в таблице пользователя. (например id,login,pass,add_post...)

Что смущает:
Немного странный способ группировать пользователей по их правам.
Например можно сделать поиск где нужно отметить права которые должны быть и/или не должны быть у искомых пользователей и по этим параметрам пользователи будут сгруппированы.

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

Для VIP/Модератор и т.п. в профиле, придется заводить отдельное поле!!!
Если у меня 10к пользователей и 10 из них модераторы/вип/макаки у которых должно быть написано это в профиле, у остальных 9990 аккаунтов в профиле будет висеть пустое поле...

Мусор! Сейчас я храню в таблице users исключительно основные данные о аккаунте, необходимые для доступа к нему и самые основные настройки профиля. При таком же подходе придётся завести дополнительные ~20 полей которые будут выглядеть как мусор и скорее всего замедлят работу с этой таблицей.

Хотя конкретно с этим пунктом я придумал кое-что. Хранить эти ячейки с правами в другой таблице (access например) без уникальных идентификаторов и просто связывать эту таблицу с пользователем указывая например в поле from его id и искать права пользователя в этой таблице.

Что скажите? Может быть у вас есть свои варианты реализации? Если да, то предлагайте.

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

@tarasalk · 20.03.2016, 19:01

Есть такой вариант.

Сообщение от AlexBitard

Если удалить случайно (дада, но ведь всякое может случиться!) в MyAdmin ячейки таблицы, появятся ошибки в тех местах сайта, где есть условия "если группа == id, то", потому что таблицы не будет существовать.

Это не аргумент. Такое при любом подходе может случиться, а для страховки надо делать бекап бд.

Сообщение от AlexBitard

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

Можно подумать над наследованием групп(хотя почему групп, слово "роль" более уместно)

Сообщение от AlexBitard

Выскажитесь на этот счёт, как по вашему, должна ли присутствовать возможность динамически (прямо из админки) настраивать права гостей (всех НЕ пользователей) или достаточно установки переменных в начале движка?

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

Сообщение от AlexBitard

Где такие статусы как Гость и Заблокированный пользователь являются группами.

Я бы не стал так делать. Но конечно плясать надо от задачи...

@AlxBtrd · 20.03.2016, 19:24 **[ТС]**

Сообщение от tarasalk

Что значит установка переменных в начале движка?

Сначало выставляются дефолтные переменные, где пользователю ничего не разрешено, а потом, в зависимости от группы (если она есть и найдена) что-то разрешается.

Гости не принадлежат ни к какой группе, а значит и разрешено им ничего не будет.

Я решил так и сделать.

Но вопрос остаётся. Основная проблема групп

Сообщение от AlexBitard

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

Наследование не рассматривается, так как это всё равно клонирование групп (хотя и более удобное), но не из-за этого, а скорее потому что я себе не представляю реализацию

@tarasalk · 20.03.2016, 20:13

Сообщение от AlexBitard

Сначало выставляются дефолтные переменные, где пользователю ничего не разрешено, а потом, в зависимости от группы (если она есть и найдена) что-то разрешается.

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

Сообщение от AlexBitard

Гости не принадлежат ни к какой группе, а значит и разрешено им ничего не будет.

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

Хз что еще добавить. ACL, RBAC, ABAC... уже все придумано.

@AlxBtrd · 20.03.2016, 21:05 **[ТС]**

tarasalk, Приходит в голову решение такое
Создать таблицу вида uid,набор прав
При создании пользователя - создавать для него таблицу с стандартными правами
При необходимости, в привязанной к нему таблице прав, о которой я написал выше, назначать права или запреты.
И при проверке прав, узнавать при помощи этой таблицы, доступно ли определённое действие пользователю.

Если таблица вдруг не найдена - создать дефолтную таблицу для пользователя.

Искать пользователей можно в этом случае по правам.
Мне нужно найти пользователей которые могут модерировать новости и имеют доступ в админ панель - отмечаю 2 этих пункта и ищу такие записи в таблице прав. Если нахожу, беру из каждой записи id пользователя и формирую ответ.

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

Как вам этот вариант? Имеет право на жизнь? Какая-нибудь критика? Какие минусы?
И вот ещё, в такой таблице не будет уникального идентификатора ячейки. Потому что он там не нужен.
На сколько вообще нормальна таблица без уникального столбца? Есть ли у этого минус? Возможно ли индексировать такую таблицу?

@RR_CF · 20.03.2016, 21:34

Я уже спать хочу , мало что поняла , но , если тебе просто права нужно сделать почему бы просто не сделать так?

в таблице Users сделать поле role , которое будет допустим Integer , если оно будет 3 , это допустим админ , если 2 модератор , если 1 редактор , если 0 обычный юзер, и просто подставлять нужные значение под них , через switch Например.

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$role = $row['role']
switch ($role)
 {
        case '0':
                $role = 'user';
                break;
        case '1':
                $role = 'редактор';
                // тут стартуем сессию , если нужно.
                break;
        case '2':
                $role = 'модератор';
// тут стартуем сессию , если нужно.
                break;
        case '3':
                $role = 'администратор';
// тут стартуем сессию , если нужно.
                break;
 
}

Сорьки если не то , просто очень много букв , а я спать хочу , все дела.

@AlxBtrd · 20.03.2016, 22:56 **[ТС]**

RR_CF, Нет, это вообще оффтоп и похоже на спам

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

@AlxBtrd -13 / 2 / 0 Регистрация: 14.08.2014 Сообщений: 240

	Реализация прав доступа 20.03.2016, 17:51. Показов 4129. Ответов 6 Метки нет (Все метки) Долго не мог определиться с реализацией прав доступа для пользователей, надеюсь благодаря Вашим доводам определюсь. Итак, есть перечень прав вроде Модерирования материалов, публичных сообщений, пользователей, статических страниц, доступ к админ панели, задачам, логам, жалобам... Я не могу решить как стоит реализовать распределение прав исходя из того, что идеология моего проекта такова - модульность, независимость компонентов и отсутствие ограничений для расширения в любом направлении. Варианта у меня 2 1й и временно реализованный - Группы. Создаётся группа с уникальным ID, в таблице группы присутствуют ячейки отвечающие за права. В настройках группы можно эти права регулировать. Например add_post - 1 и пользователь может добавлять материалы. 0 и не может. Сейчас таких прав ~8, планируется примерно до 20ти. В настройках профиля пользователя, ему присваивается идентификатор группы. При обращении к странице, движок пытается достать ID группы, если она существует - узнаёт права и определяет переменные доступа. На всякий случай если группы не существует - будут установлены гостевые переменные. Но при удалении группы из админ панели, всех пользователей перекидывает в другую группу, выбранную инициатором удаления. Что смущает: Недостаточная модульность. Например есть группа в которой пользователи могут добавлять материалы, но не могут их удалять, а определённому пользователю нужно разрешить и добавлять и удалять свои материалы при абсолютно тех же других настройках. Придется создать целую кучу групп пользователей на все случаи жизни. Дефолтно движок обязан иметь как минимум 2 группы - пользователи и администраторы. Если удалить случайно (дада, но ведь всякое может случиться!) в MyAdmin ячейки таблицы, появятся ошибки в тех местах сайта, где есть условия "если группа == id, то", потому что таблицы не будет существовать. Хотя такой подход конечно идеологически не правильный и стоит использовать переменные определённые в начале движка, но может понадобиться например создать группу VIP/Модератор и показывать принадлежность пользователя этой группе если он в ней состоит, а создавать настройку определяющую показывать ли группу в профиле ради 2х групп может быть не допустимо. Ещё пугает реализация групп как в DLE например. Где такие статусы как Гость и Заблокированный пользователь являются группами. Выскажитесь на этот счёт, как по вашему, должна ли присутствовать возможность динамически (прямо из админки) настраивать права гостей (всех НЕ пользователей) или достаточно установки переменных в начале движка? Нравится в этом подходе то, что данные о разрешениях/запретах хранятся всего лишь в одной таблице. Никакого мусора и всё очень лаконично. 2й - Настройки непосредственно в таблице пользователя. То есть тот же выпадающий список галочек, но только на странице управления пользовательской страницей. Ячейки хранятся при таком подходе в таблице пользователя. (например id,login,pass,add_post...) Что смущает: Немного странный способ группировать пользователей по их правам. Например можно сделать поиск где нужно отметить права которые должны быть и/или не должны быть у искомых пользователей и по этим параметрам пользователи будут сгруппированы. Например нужно мне найти пользователей только с доступом в админ панель, я ставлю галку на этом пункте, ищу и в результатах только пользователи с таким правом. Для VIP/Модератор и т.п. в профиле, придется заводить отдельное поле!!! Если у меня 10к пользователей и 10 из них модераторы/вип/макаки у которых должно быть написано это в профиле, у остальных 9990 аккаунтов в профиле будет висеть пустое поле... Мусор! Сейчас я храню в таблице users исключительно основные данные о аккаунте, необходимые для доступа к нему и самые основные настройки профиля. При таком же подходе придётся завести дополнительные ~20 полей которые будут выглядеть как мусор и скорее всего замедлят работу с этой таблицей. Хотя конкретно с этим пунктом я придумал кое-что. Хранить эти ячейки с правами в другой таблице (access например) без уникальных идентификаторов и просто связывать эту таблицу с пользователем указывая например в поле from его id и искать права пользователя в этой таблице. Что скажите? Может быть у вас есть свои варианты реализации? Если да, то предлагайте. Думаю это очень важный вопрос, каким бы глупым он не показался, ведь организация прав на сайте, одна из важнейших деталей. 0

@AlxBtrd -13 / 2 / 0 Регистрация: 14.08.2014 Сообщений: 240
	20.03.2016, 21:05 [ТС]
	tarasalk, Приходит в голову решение такое Создать таблицу вида uid,набор прав При создании пользователя - создавать для него таблицу с стандартными правами При необходимости, в привязанной к нему таблице прав, о которой я написал выше, назначать права или запреты. И при проверке прав, узнавать при помощи этой таблицы, доступно ли определённое действие пользователю. Если таблица вдруг не найдена - создать дефолтную таблицу для пользователя. Искать пользователей можно в этом случае по правам. Мне нужно найти пользователей которые могут модерировать новости и имеют доступ в админ панель - отмечаю 2 этих пункта и ищу такие записи в таблице прав. Если нахожу, беру из каждой записи id пользователя и формирую ответ. Этот способ выглядит достаточно независимым. Ведь если например появятся новые правила, я просто добавлю ячейку в таблице прав с значением по умолчанию. Если удалить правило, оно опять же никак не помешает работоспособности. Как вам этот вариант? Имеет право на жизнь? Какая-нибудь критика? Какие минусы? И вот ещё, в такой таблице не будет уникального идентификатора ячейки. Потому что он там не нужен. На сколько вообще нормальна таблица без уникального столбца? Есть ли у этого минус? Возможно ли индексировать такую таблицу? 0

@AlxBtrd -13 / 2 / 0 Регистрация: 14.08.2014 Сообщений: 240
	20.03.2016, 22:56 [ТС]
	RR_CF, Нет, это вообще оффтоп и похоже на спам 0