Задача: в системе должно быть 2 группы пользователей:
1) "агенты"
2) "администраторы"
Агенты занимаются тем, что добавляют ("от своего имени") некие данные в базу и ждут пока эти данные проверят.
Администраторы делают то же самое, но кроме того ещё проверяют данные полученные от агентов (разрешить || не разрешить), т.е. админ - это тот же агент, только с большими правами.
Так вот… Как лучше организовать таблицы? У меня 2 варианта:
a) Общая таблица для админов и агентов, а в ней поле - "is_admin" (bool)
b) Таблица агентов и таблица админов (куда записывать ID агентов, имеющих права администратора) связанные 1:1.
Кроме того не догоняю как лучше сделать иерархию классов
a) Класс User и дочерние - Admin и Agent
b) Класс Agent и дочерний, Admin (рассширяющий функции родителя)
Короче, как лучше?…
[offtop]издвините, случайно рано нажал на энтер[/offtop]
новые сообщения
ответы на мои сообщения
избранное
скрытые темы
случайный топик
открыть всё в новых вкладках
Форум → Программирование → PHP для идиотов → Как разделить пользователей
Как разделить пользователей
-
Сообщения:
1068
Репутация:
N
Группа:
Джедаи
-
Сообщения:
3131
Репутация:
N
Группа:
в ухо
27 июля 2007 г. 15:08, спустя 13 минут 52 секунды
a) Общая таблица для админов и агентов, а в ней поле - "is_admin" (bool)
b) Таблица агентов и таблица админов (куда записывать ID агентов, имеющих права администратора) связанные 1:1.
Мне a) больше нравится. Зачем лишняя таблица?Кроме того не догоняю как лучше сделать иерархию классов
a) Класс User и дочерние - Admin и Agent
b) Класс Agent и дочерний, Admin (рассширяющий функции родителя)
А какая функциональность будет у обоих? -
Сообщения:
1068
Репутация:
N
Группа:
Джедаи
27 июля 2007 г. 15:29, спустя 21 минуту 30 секунд
и те и другие добавляют-редактируют-удаляют данные. Но агенты работают только со своими данными, а админы - с любыми.
-
Сообщения:
11960
Репутация:
N
Группа:
в ухо
27 июля 2007 г. 15:34, спустя 4 минуты 31 секунду
делай поле is_admin binary
и если он пытается чужое редактировать проверй if (is_admin)все умрут, а я изумруд -
Сообщения:
1068
Репутация:
N
Группа:
Джедаи
27 июля 2007 г. 15:50, спустя 16 минут 30 секунд
пришла в голову аналогия с предмодерацией форума - есть пользователи которые оставляют сообщения, и есть модеры которые которые эти сообщения проверяют и так же могут оставлять свои сообщения…
думаю теперь стоит ли вообще разделать классы, и если стоит то как лучше… -
Сообщения:
3131
Репутация:
N
Группа:
в ухо
27 июля 2007 г. 16:02, спустя 12 минут 17 секунд
Я вообще не люблю в подобных случаях создавать объекты-юзеры. Ведь использоваться будет только один из них. Да и он, это скорее соответствует не реальному объекту (пользователю), а учетной записи, а смысл её — привилегии доступа к чему-либо, имеющие для каждого конкретного сценария всеобъемлющий смысл.
Я бы при авторизации запомнил где-нибудь, админ это или не админ, а в каждом методе, выполняющем действия требующие админских прав, проверял эту переменную. -
Сообщения:
883
Репутация:
N
Группа:
Джедаи
27 июля 2007 г. 16:09, спустя 6 минут 57 секунд
если система не будет развиваться - нормальное решение, но имхо - более универсальное сделать роли
потому как возможно, например, такое развитие событий:
еще одна группа агентов, у которых будут подчиненные агенты, с правами - утверждать свои записи и записи подчиненных, или по-раздельно как на форуме..
все от задачи зависит -
Сообщения:
1068
Репутация:
N
Группа:
Джедаи
27 июля 2007 г. 16:49, спустя 39 минут 55 секунд
Я бы при авторизации запомнил где-нибудь, админ это или не админ, а в каждом методе, выполняющем действия требующие админских прав, проверял эту переменную.
не понял, а где это запомнить - в глобальной переменной?но имхо - более универсальное сделать роли
блин, мне бы где-нибудь почитать про это или пример какой посмотреть… а то упорно не догоняю… хочеться что бы всё красиво было….. -
Сообщения:
3131
Репутация:
N
Группа:
в ухо
27 июля 2007 г. 16:53, спустя 4 минуты 11 секунд
не понял, а где это запомнить - в глобальной переменной?
Да где угодно. В простейшем случае для такой задачи я бы сделал статический класс users, например, который бы отвечал за авторизацию, проверку привилегий и т.п. При авторизации/загрузке сеанса он бы сохранял статус пользователя в скрытом поле, и возвращал бы по запросу:if (!users::admin()) {
// Нафег
return false;
}
// Действия -
Сообщения:
883
Репутация:
N
Группа:
Джедаи
27 июля 2007 г. 18:39, спустя 1 час 46 минут 1 секунду
лин, мне бы где-нибудь почитать про это или пример какой посмотреть… а то упорно не догоняю… хочеться что бы всё красиво было…..
на форуме есть группы пользователей (суть роли)
админ, модератор, привилигированный юзер, обычный юзер, гость.
для каждой роли назначаются свои привилегии. по сути они нужны для удобства - видишь какие роли доступны юзеру - понимаешь какие у него права, не нужно каждый раз парится с нарезкой привилегий. удобно в общем.
на форуме юзеру доступна только одна роль, в более сложных ситуациях юзеру может быть доступно несколько ролей. -
Сообщения:
1048
Репутация:
N
Группа:
Адекваты
27 июля 2007 г. 20:59, спустя 2 часа 19 минут 49 секунд
А права стандартные или тоже будут создаваться? -
Сообщения:
1068
Репутация:
N
Группа:
Джедаи
2 августа 2007 г. 20:21, спустя 5 дней 23 часа 21 минуту
так… значит сделал "по ролям"
1. таблица member ("члены", блин…)
2. таблица role ("роли" "членов")
3. таблица article (ну типа объекты на которые распрастраняются права, а именно таблица портфолио, таблицы справочников и таблица пользователей member)
4. таблица permission, cвязывающая role и article (М:М). С ней и возникли траблы…
проблема в том, что к разным объектам article применяются разные действия:
- информацию в справочниках можно просматривать, добавлять, изменять и удалять;
- портфолио можно добавлять, изменять, удалять, а так же разрешать-блокировать, кроме того члены одной роли (агенты) могут работать только со своими портфолио, а члены другой (одмины) - с любыми;
- пользователей можно добавлять, изменять, удалять, а так же разрешать-блокировать,
- статистика, которую вообще можно только просматривать, ну и очищать, наверное…
вот как всю эту фигню запихнуть в одну таблицу permission? сначала сделал так:role | article | read | readall | append | update | remove | block
но в этом случае, например для справочников поля readall, block получаются "левыми", для статистики вообще не нужно ничего кроме read и remove
Может лучше создавать для каждого типа объектов отдельную таблицу? (ну типа permission_handbook, permission_portfolio, permission_member и т.д.) Или я вообще загнался и не то делаю? -
Сообщения:
883
Репутация:
N
Группа:
Джедаи
3 августа 2007 г. 0:25, спустя 4 часа 4 минуты 34 секунды
а почему не
role - int
article - int
permition - text
Пожалуйста, авторизуйтесь, чтобы написать комментарий!