Меню
Что нового?

Контроль доступа: сложности при распределение анкетных даных и прав для пользователей

Гриша К.

Новичок
Контроль доступа: сложности при распределение анкетных даных и прав для пользователей

Здравствуйте.

При организации контроля доступа пользователей на сайте (http://phpclub.ru/talk/showthread.php?s=&threadid=88278&rand=10), у меня возникли дополнительные сложности:

на сайте предполагается несколько групп пользователей,
имеющих общие данные: имя пользователя, e-mail, пароль
имеющих разные данные и права:
Администраторы - имеют только описанные выше данные, [могут иметь права просмотра скрытых разделов, добавления, редактирования и удаления информации].
Партнеры - дополнительно должны содержать ИД партнера (не ИД пользователя, а ИД данных о фирме парнера), в соответсвии с таблицей информации о партнерах (инфа.о фирме, условия доставки), [имеют права просмотра сделанных заказов данного партнера, изменения их статуса, комментирования заказов и инфы о товарах данного партнера]
Пользователи - дополнительно должны иметь Ф.И.О., адрес, телефон, [color=#66666][права только просмотр информации о сделанных ими заказах][/color].

Вопрос состоит в том, как правильно организовать структуру БД, для последующего правильного определения прав пользователей.
Например я создам общую таблицу для всех пользователей, которая будет содержать имя пользователя, e-mail, пароль, дату регистрации, дату последнего посещения,
но мне также необходимо чтобы пользователи группы партнеры могли иметь ИД фирмы партнера, а обычные пользователяи имели анкетные данные Ф.И.О., адрес телефон.
Структура моей БД представлена здесь http://phpclub.ru/talk/showthread.php?s=&threadid=88278&rand=10

Немогли вы подсказать, нормален ли такой вариант:
Делаю разные таблицы для 3-х групп пользователей, и соответсвенно разные формы авторизации.
Ранг так скажем пользователя будет определяться имененем переменной сессии:
- Администраторы - $_SESSION['user_admin'] (при инициализации этой переменной определяем права администратора на объекты: просмотр, добавление, редактирование, удаление).
- Партнеры - $_SESSION['user_partner'] (при инициализации этой переменной партнер может просматривать страницу заказов данной фирмы-партнера).
- Пользователи - $_SESSION['user_client'] (при инициализации этой переменной пользователь может просматривать страницу своих заказов).
 

Quessir

Новичок
Re: Контроль доступа: сложности при распределение анкетных даных и прав для пользователей

Автор оригинала: Гриша К.

Немогли вы подсказать, нормален ли такой вариант:
Делаю разные таблицы для 3-х групп пользователей, и соответсвенно разные формы авторизации.
Ранг так скажем пользователя будет определяться имененем переменной сессии:
- Администраторы - $_SESSION['user_admin'] (при инициализации этой переменной определяем права администратора на объекты: просмотр, добавление, редактирование, удаление).
- Партнеры - $_SESSION['user_partner'] (при инициализации этой переменной партнер может просматривать страницу заказов данной фирмы-партнера).
- Пользователи - $_SESSION['user_client'] (при инициализации этой переменной пользователь может просматривать страницу своих заказов).
Нажмите для раскрытия...
В принципе так оно и делается

-~{}~ 21.07.06 21:56:

Только лучше 1 таблица с доп. полем. Т.е. чем выше права, тем больше ты ставишь права. Для админа , скажим 10, для партнера 5, для пользователя там 3 и т.д.
 

4m@t!c

Александр
Исходя из каких соображений вы завели три разных переменных, а не одну переменную с тремя вариантами значений, соответствующих каждому типу пользователя?
 

Гриша К.

Новичок
Quessir, спасибо за ответ.

Почему я решил разделять на 3 таблицы, потому что у меня для пользователей группы "Пользователи", должны содержаться дополнительные анкетные данные Ф.И.О., адрес, телефон. А для партнеров должен содержать ИД фирмы партнера.
Но возможно стоит все объединить в одну таблицу, и в ненужных полях для пользователей ставить нули - незнаю насколько нормален такой вариант.


4m@t!c, спасибо за ответ.
Соображения у меня сейчас такие, что например $_SESSION['user_admin'] = имя пользователя, а имя переменной 'user_admin' определяется исходя из формы авторизации в которой он авторизовался (например форма для админов), либо например исходя из ИД группы (0-пользователь, 1 - админ, 2-партнер).
 

Quessir

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

-~{}~ 21.07.06 22:14:

А форму иметь все-таки желательно одну и затем (как я уже писал выше про права) определять его права.
 

Гриша К.

Новичок
Quessir, спасибо за ответ,
с доп таблицей есть некоторая сложность, при проверке прва доступа и т.д. Хотя:
1) Вообще наверное при авторизации пользователя стоит использовать левостороннее объединение основной таблицы с дополнительными,
2) Либо вообще в зависимости от формы авторизации делать разные запросы к БД.
Форма авторизации пользователя, тогда делаем объединение основной таблицы с доп таблицей, вот точно наверное так и буду делать.

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

-~{}~ 21.07.06 19:41:

Отвечать наверное больше не будете уже, ну спасибо большое за разъяснения мне теперь ясно что делать, а то с утра встал и совсем непонилмал как все организовать.
 
bgm

bgm

 
Если нет острой необходимости производить поиск по регистрационной информации, то можно её хранить в одном поле в виде XML. И для каждого типа пользователей завести XSD схему, которая будет определять структуру XML данных.
 

Гриша К.

Новичок
bgm, спасибо за ответ.
С XML я незнаком, и неготов пока изучать. А поиск будет по имени пользователя, и группе пользователя.
 

Гриша К.

Новичок
bgm, спасибо за ссылку, прочитал, но в голове все не укладыается (XSD схема и т.д.), чтобы понять как вообще с эти работать, я думаю надо купить книжку и читать, немало времени наверное уйдет у меня на это, так что пока отложу это изучение.
 
Войдите или зарегистрируйтесь для ответа.
Сверху