Хранение доступа пользователей к страницам в MYSQL⁠⁠

Приветствую всех, кто заинтересовался таким вопросом и попал сюда!

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

Идея была в следующем:

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

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

Однако практически первое Но, с которым я столкнулся это какие вообще есть способы хранения доступа пользователей в БД MYSQL? Как это реализовывалось под капотом? Ну так вот первое к чему я пришёл это хранение в таблице пользователей в текстовом поле записей типа "1,3,8,45,", что означало - какие ID модулей доступны конретному пользователю. Таким образом пользователь логинился, сайт на основе записей пользователя выдавал ссылки только на те страницы, которые были юзеру разрешены.

Теперь настал момент переписать приложение по-нормальному, и снова этот вопрос, какие еще варианты есть хранения в базе данных доступа к страницам, если "ну допустим" количество этих страниц "стремится в бесконечность", как и количество пользователей?

Вы смотрите срез комментариев. Показать все

alex.sav

2 года назад

Первое, что нужно сделать, это отделить модули от пользователей.

То есть добавить ГРУППЫ.

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

раскрыть ветку (5)

mrGraveheart

2 года назад

Спасибо! У меня получится кол-во пользователей = кол-ву групп, там полный разнобой по доступу. Тоже думал сгруппировать, т.к. это бы облегчало процесс добавления нового модуля - не множеству пользователей, а одной группе, но блин так не выходит.

раскрыть ветку (4)

alex.sav

2 года назад

Еще мысли:

FIND_IN_SET() это скорее всего самый медленный способ. Сейчас посмотрел EXPLAIN на небольшом примере, который тут другой пользователь писал - он делает full scan, то есть тупо берет строку ID=1, ищет в сете, потом строку ID=2 и так всю таблицу форм.

IN() или JOIN будут работать намного быстрее.

Хотя если форм не очень много, это вряд ли будет играть какую-то роль.

Еще для экономии места можно использовать битовые строки. То есть если у тебя есть 64 модуля - их можно закодировать в одном 64-битном числе.

Заморачиваться с отдельной таблицей модули-пользователи имеет смысл только если модулей будет несколько сотен.

alex.sav

2 года назад

Неужели никаких закономерностей нет? Ты когда добавляешь права пользователям ведь чем-то руководствуешься? Какими-то правилами?

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

раскрыть ветку (2)

mrGraveheart

2 года назад

Закономерности есть за исключением десятка юзеров. Закономерности такие: в зависимости от отделения работы, руководителя и должности пользователя ему назначаются модули, однако некоторые модули уникальные и нужны конкретному пользователю, другие конкретно только двум-трём, третьи исключительно мои, но иногда даются в просмотр другим на некоторое время (например, пока я в отпуске). Там вобщем такая круговерть с ними...

раскрыть ветку (1)

alex.sav

2 года назад

Ну, на лицо организационный бардак :)

Я бы попытался разгрести этот бардак и унифицировать как можно больше вещей, и всё-таки сделать группы. Это потом окупится за счет повышения эффективности работы организации и уменьшения путаницы и бардака (круговерти вот этой :).

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

Если до конца все-таки не получится унифицировать, то добавить таблицу "exceptions" и там хранить пользователя и дополнительные модули, к которым у него есть доступ. Цеплять эту таблицу JOIN-ом по user ID. Можно даже сделать + и - модули, то есть какие добавить, а какие убрать.

Формы получать двумя запросами - сначала берем user + group + exceptions, собираем список ID, дальше получаем сами формы через IN(список).

Можно теоретически, конечно, написать один запутанный мега-JOIN, но два запроса это более понятно и практично :)

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку