Списки контроля доступа и игнор-листы

maaboo

Новичок
Списки контроля доступа и игнор-листы

Доброго...

Имеется некое приложение (точнее пишется), где будет организованы ACL. Я ранее задавал вопрос, но почему-то никто из уважаемых участников форума не дал на него ответа. Вопрос про пример организации контроля доступа. Но как оказалось при анализе такой контроль больно уж смахивает на юниксовый и не позволяет гибко рулить (например, пользователь не может входить одновременно в несколько групп, или скажем наследовать права). Я посмотрел движок WackoWiki, и как там организовано подобное, так вот там имеется табличка wakka_acls, со следующими столбцами:

page_tag | varchar(250) | PRI
supertag | varchar(250) | MUL
privilege varchar(20) | PRI
list | text

У меня возникло два вопроса:

1. Почему привилегии написаны как varchar(20)? И как это может работать?
2. Насколько я понял группы хранятся в text. Насколько это оправдано, и можно ли сделать по-другому?

Кроме того, как осуществить хранение в базе настроек вроде
user value
against
user value?
(например user1 игнорит user2, user 35 зафрендил user998 и так далее).


Это какая-то самоперекрещивающаяся таблица получается. Как это организовать?

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

Кто-нибудь реализовывал контроли доступа и списки, подобные игнорным?
 

NemesiS

Новичок
Можно так:
1 - владелец игнор листа
2 - список игнорируемых, через разделитель.
 

maaboo

Новичок
Автор оригинала: NemesiS
Можно так:
1 - владелец игнор листа
2 - список игнорируемых, через разделитель.
Это получается что сколько пользователей столько и таблиц что ли? А если пользователей скажем 50 тысяч?
 

NemesiS

Новичок
1 пользователь - одна запись в таблице.
в первой колонке его id.
а во второй id тех, кого он игнорирует, напр в таком виде:
[1],[2]
скобки, для того, чтоб в запросе можно было указать
WHERE ignor LIKE '%id%'
и при списке 1,11,12,14,21 не получить всех на 1го пользователя.
 

maaboo

Новичок
Автор оригинала: NemesiS
1 пользователь - одна запись в таблице.
в первой колонке его id.
а во второй id тех, кого он игнорирует, напр в таком виде:
[1],[2]
скобки, для того, чтоб в запросе можно было указать
WHERE ignor LIKE '%id%'
и при списке 1,11,12,14,21 не получить всех на 1го пользователя.
А хранить каким полем? Text? Blob? Сколько там максимум может быть этом?
 

NemesiS

Новичок
Сходи в ман, немного подумай...

ну наверное id - int (tiny, или big решай сам)
а список игнорируемых - text (short или long тоже тебе на выбор)
 

Фанат

oncle terrible
Команда форума
maaboo
как бы это помягче сказать... твой собеседник не очень силён в теории. и в практике тоже.
 

maaboo

Новичок
Автор оригинала: Фанат
maaboo
как бы это помягче сказать... твой собеседник не очень силён в теории. и в практике тоже.
Ну дык.. может направишь на путь истинный? Я бы и гуглить мог, но не всегда умею ему сформулировать такие абстрактные для меня вещи, да и ключе-словарный запас у меня не позволяет...
 

Фанат

oncle terrible
Команда форума
Ну, я тоже не силён.
То есть на вопрос , как организовать структуру игнора и френдов, я бы ответил стандартно - таблица френдс: ид юзера|ид френда. и с игнорами так ж.
но вот как с их учетом запрос строить - хз.

А то посмотри устройство базы livekournal-a. там ведь это тоже ж есть. приватность записей по группам.
 

NemesiS

Новичок
Фанат, не будем оскорблять друг-друга.
1) На твой уровень профессионализма я не претендую
2) Ты не знаешь силен ли я в практике и теории.
3)Ты сам предложи что-нибудь, а не критикуй других., или ты теоретик??? >(
 

maaboo

Новичок
Автор оригинала: Фанат
Ну, я тоже не силён.
То есть на вопрос , как организовать структуру игнора и френдов, я бы ответил стандартно - таблица френдс: ид юзера|ид френда. и с игнорами так ж.
но вот как с их учетом запрос строить - хз.

А то посмотри устройство базы livekournal-a. там ведь это тоже ж есть. приватность записей по группам.
Эээ.. а как можно было бы это посмотреть? Где-то есть исходники?
 

Фанат

oncle terrible
Команда форума
ну, разумеется. посмотри на их сайте - должна быть ссылка
 

Alexandre

PHPПенсионер
Вопрос про пример организации контроля доступа. Но как оказалось при анализе такой контроль больно уж смахивает на юниксовый и не позволяет гибко рулить (например, пользователь не может входить одновременно в несколько групп, или скажем наследовать права).
- Таблица Пользователи
- Таблица группы
- связывающая Таблица Пользователи >-< группы
- Таблица фронт скрипты(классы , экшены, урлы - в зависимости от того что собираешься защищать )
- Таблица приложения или пакеты (набор скриптов)
- связывающая Таблица пакеты >-< группы

Недостаток, не могу дать пользователю дополнительную привелегию на Приложение (пакет)

все вышеперечисленное реализовывалось и не один раз.

Расширение:
- Таблица Привелегии
- связывающая Таблица X Пользователи >-< Привелегии
- Таблица Denied (Revocation List )

Расширение на Доп привелегии приходилось делать, но Revocation List - это аналог Доп привелегий
 
Сверху