Многопользовательская система

DV

Guest
Многопользовательская система

Подскажите, пожалуйста, как сделать, чтобы в администраторской панели у разных админов был доступ только к определенному разделу(-ам)? Создать дополнительное поле в таблице пользователей, где через какой-нибудь разделитель, например тире, перечислить номера допустимых разделов, а при входе это поле обработать с помощью explode(), например, и потом проверять этим массивом, есть ли раздел в списке, если нет, пункт этот не выводить?
Замудрил…или есть проще способ? :D
 

untied

Сдвинутый новичок
Нет. Нужно создать отдельную таблицу для определения соответствий админа и раздела. Т.е. если соответствие есть (имеется пара id раздела - id администратора), то доступ разрешен.
Правда, если разделов будет много (и админов много), то будет достаточно геморройно назначать каждому доступ. Можно придумать группы администраторов. И тогда доступ к разделу назначается для группы, а админы потом распределяются по группам доступа.
 

DV

Guest
Разделов будет достаточно и админов со временем тоже. :)
 

untied

Сдвинутый новичок
Тогда три таблицы:

- таблица групп (id, название)
- соответствие админ - группа (id админа, id группы)
- соответствие группа - раздел (id группы, id раздела)

Последняя таблица как раз и определяет доступ.
 

DV

Guest
а не сильно это сложно? А если админ - один раздел. Будет 20 разделов и 20 админов, что создавть 20 групп???
 

untied

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

И потом, никто не запрещает сделать объединенным методом. Доступ групп и доступ персонально админам. То есть четыре таблицы:

- 3 описанных выше
- соответствие админ - раздел (id админа, id раздела)
 

DV

Guest
а как защитить от смены админа. Был я админ id=20, что мне стоит сменить его на id=5 c более высоким уровнем...создать тогда в таблице id админа - id разделов поле с каким-нибудь идентификатором, например сессии и проверять он или не он?
 

untied

Сдвинутый новичок
Ну тут все просто.
Есть раздел, скажем "Управление операторами". К этому разделу изначально имеет доступ некий супервизор, который создается с заданным логином и паролем при инсталляции системы.
Далее заходишь как супервизор, создаешь нужных операторов (администраторов). И задаешь им требуемый доступ к разделам. Скажем, оператору А доступ в раздел "Управление операторами" запрещаешь. И оператор А никак свой уровень доступа поменять не сможет. И переназначить себе id (то, что ты упоминаешь, хотя это и странно -- переназначать id) тоже не сможет.
 

DV

Guest
И переназначить себе id (то, что ты упоминаешь, хотя это и странно -- переназначать id) тоже не сможет.
А как мне передавать id админа между скриптами? В сессии?

-~{}~ 21.02.05 16:11:

И как лучше, создать доп. поле в таблице пользователей с признаком админовских возможностей. Или просто в отдельной таблице вести админов?
 

untied

Сдвинутый новичок
id оператора, видимо, следует передавать в сессии.

По поводу организации пользователей и админов.
Можно поступать и так и эдак. Вот 3 варианта, к примеру:

1. Обычные пользователи и операторы хранятся в разных таблицах.
2. Пользователи и операторы хранятся в одной таблице, но есть отдельное поле, которое показывает, что данный пользователь -- оператор.
3. Можно никак не различать пользователей и операторов. Просто у одних будет доступ к тем или иным разделам, а у других никакого доступа не будет.
 

untied

Сдвинутый новичок
Автор оригинала: DV
А что в сессии нельзя никак id другой подсунуть?
Каким образом? Через браузер передается только идентификатор сессии. А переменные сессии (в том числе и идентификатор администратора) хранятся на сервере (и там же они и создаются, сразу после чтения данных из таблиц БД).
Как ты их подменишь, минуя скрипты и, соответственно, аутентификацию?

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