ФорумПрограммированиеPHP для идиотов → Как разделить пользователей

Как разделить пользователей

  • Timur

    Сообщения: 1068 Репутация: N Группа: Джедаи

    Spritz 27 июля 2007 г. 3:54

    Задача: в системе должно быть 2 группы пользователей:
    1) "агенты"
    2) "администраторы"

    Агенты занимаются тем, что добавляют ("от своего имени") некие данные в базу и ждут пока эти данные проверят.
    Администраторы делают то же самое, но кроме того ещё проверяют данные полученные от агентов (разрешить || не разрешить), т.е. админ - это тот же агент, только с большими правами.

    Так вот… Как лучше организовать таблицы? У меня 2 варианта:
    a) Общая таблица для админов и агентов, а в ней поле - "is_admin" (bool)
    b) Таблица агентов и таблица админов (куда записывать ID агентов, имеющих права администратора) связанные 1:1.

    Кроме того не догоняю как лучше сделать иерархию классов
    a) Класс User и дочерние - Admin и Agent
    b) Класс Agent и дочерний, Admin (рассширяющий функции родителя)

    Короче, как лучше?…

    [offtop]издвините, случайно рано нажал на энтер[/offtop]
  • vasa_c

    Сообщения: 3127 Репутация: N Группа: в ухо

    Spritz 27 июля 2007 г. 4:08, спустя 13 минут 52 секунды

    a) Общая таблица для админов и агентов, а в ней поле - "is_admin" (bool)
    b) Таблица агентов и таблица админов (куда записывать ID агентов, имеющих права администратора) связанные 1:1.

    Мне a) больше нравится. Зачем лишняя таблица?

    Кроме того не догоняю как лучше сделать иерархию классов
    a) Класс User и дочерние - Admin и Agent
    b) Класс Agent и дочерний, Admin (рассширяющий функции родителя)

    А какая функциональность будет у обоих?
  • Timur

    Сообщения: 1068 Репутация: N Группа: Джедаи

    Spritz 27 июля 2007 г. 4:29, спустя 21 минуту 30 секунд

    и те и другие добавляют-редактируют-удаляют данные. Но агенты работают только со своими данными, а админы - с любыми.
  • md5

    Сообщения: 11949 Репутация: N Группа: в ухо

    Spritz 27 июля 2007 г. 4:34, спустя 4 минуты 31 секунду

    делай поле is_admin binary
    и если он пытается чужое редактировать проверй if (is_admin)
    все умрут, а я изумруд
  • Timur

    Сообщения: 1068 Репутация: N Группа: Джедаи

    Spritz 27 июля 2007 г. 4:50, спустя 16 минут 30 секунд

    пришла в голову аналогия с предмодерацией форума - есть пользователи которые оставляют сообщения, и есть модеры которые которые эти сообщения проверяют и так же могут оставлять свои сообщения…

    думаю теперь стоит ли вообще разделать классы, и если стоит то как лучше…
  • vasa_c

    Сообщения: 3127 Репутация: N Группа: в ухо

    Spritz 27 июля 2007 г. 5:02, спустя 12 минут 17 секунд

    Я вообще не люблю в подобных случаях создавать объекты-юзеры. Ведь использоваться будет только один из них. Да и он, это скорее соответствует не реальному объекту (пользователю), а учетной записи, а смысл её — привилегии доступа к чему-либо, имеющие для каждого конкретного сценария всеобъемлющий смысл.
    Я бы при авторизации запомнил где-нибудь, админ это или не админ, а в каждом методе, выполняющем действия требующие админских прав, проверял эту переменную.
  • ghost

    Сообщения: 883 Репутация: N Группа: Джедаи

    Spritz 27 июля 2007 г. 5:09, спустя 6 минут 57 секунд

    если система не будет развиваться - нормальное решение, но имхо - более универсальное сделать роли

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

    все от задачи зависит
  • Timur

    Сообщения: 1068 Репутация: N Группа: Джедаи

    Spritz 27 июля 2007 г. 5:49, спустя 39 минут 55 секунд

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

    не понял, а где это запомнить - в глобальной переменной?

    но имхо - более универсальное сделать роли

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

  • vasa_c

    Сообщения: 3127 Репутация: N Группа: в ухо

    Spritz 27 июля 2007 г. 5:53, спустя 4 минуты 11 секунд

    не понял, а где это запомнить - в глобальной переменной?

    Да где угодно. В простейшем случае для такой задачи я бы сделал статический класс users, например, который бы отвечал за авторизацию, проверку привилегий и т.п. При авторизации/загрузке сеанса он бы сохранял статус пользователя в скрытом поле, и возвращал бы по запросу:
    if (!users::admin()) {
    // Нафег
    return false;
    }
    // Действия
  • ghost

    Сообщения: 883 Репутация: N Группа: Джедаи

    Spritz 27 июля 2007 г. 7:39, спустя 1 час 46 минут 1 секунду

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

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

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

    Сообщения: 1048 Репутация: N Группа: Адекваты

    Spritz 27 июля 2007 г. 9:59, спустя 2 часа 19 минут 49 секунд

    А права стандартные или тоже будут создаваться?
  • Timur

    Сообщения: 1068 Репутация: N Группа: Джедаи

    Spritz 2 августа 2007 г. 9: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 и т.д.) Или я вообще загнался и не то делаю?
  • ghost

    Сообщения: 883 Репутация: N Группа: Джедаи

    Spritz 2 августа 2007 г. 13:25, спустя 4 часа 4 минуты 34 секунды

    а почему не
    role - int
    article - int
    permition - text

Пожалуйста, авторизуйтесь, чтобы написать комментарий!