[Закрыть]
 
popoff.donetsk.ua
Не всем людям выгодно, чтобы другие были справедливыми, и тогда этих других обвиняют в жадности и эгоизме.
Начало | Новости | Статьи | Форум | Опросы | Карта сайта | Обо мне
popoff.donetsk.ua - Форум - Программирование на PHP - Кеширование привилегий в переменных сессии vs моментальное применение изменений в списке привилегий

Кеширование привилегий в переменных сессии vs моментальное применение изменений в списке привилегий

форумы popoff.donetsk.ua
Страницы: [1]
<< Новый  |  Старый >>  |  Ответ не возможен

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

Автор Сообщение
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1549
Кеширование привилегий в переменных сессии vs моментальное применение изменений в списке привилегий

Есть одно замечание по поводу кэширования и раздачи привилегий. Реализованный способ предполагает сбор привилегий во время авторизации, сохранения их в сессии и дальше все привилегии авторизированного пользователя берутся из сессии. Чем это плохо? Допустим, моя система критична к правам пользователя и смена прав должна происходить мгновенно, с момента изменения их администратором. Можно считывать их при каждом обращении к странице, но это большая нагрузка...
Я предлагаю реализовать следующий метод. В момент сохранения новых прав пользователя (или администратора, как это у тебя называются все пользователи с правами) привилегии загоняются в массив, сериализуются и сохраняются в базе. При обращении к странице, считывается только эта строка для определения привилегий пользователя и, как следствие, изменения привилегий пользователя будут мгновенно отражаться на его работе.

popoff
Yuri
Июл, 2004
Сообщений: 923
popoff url://forum.message:1550

В сессии кешируется только запрет привилегий. Разрешение привилегий каждый раз считывается из базы. То есть, если Вы выдаёте привилегию, то пользователь должен выйти и зайти, чтобы изменения вступили в силу. Если Вы отбираете привилегию, то изменению вступают в силу сразу.

Для кеширования данных (в том числе и предложенного Вами массива) у меня существует специальный модуль:
http://popoff.donetsk.ua/text/work/libs/cms/cache/
Этот модуль можно использовать *при необходимости*. Использовать его всегда я не рекомендовал бы, так как могут возникнуть проблемы с отслеживанием моментов очистки и обновления кеша (так как изменения происходят не в одной точке программы, а в нескольких, хотя и не многих), что не допустимо в такой критичной к точности работы системы, как системы управления привилегиями. Плюс к тому же, хотя система и кажется сложной, её реализация - довольно простая, а усложнять её - значит увеличивать количество ошибок, что, снова же, может оказаться очень критичным для этой важнейшей системы.

По поводу большой нагрузки - экспериментальных данных нет, поэтому ничего говорить нельзя. Врядли нагрузка будет сильно большая, так как списки привилегий, как списки привилегий администраторов, так и списки привилегий ролей, как правило, не слишком большие. Причём объём списков уменьшается как при значительном увеличении возможностей администратора (это происходит засчёт использования одной родительской привилегии вместо многих дочерних), так и при значительном уменьшении возможностей.

~~~~~ 7 Сен 2006, 15:29 ~~~~~

Другое дело, если для Вас критична и выдача привилегий, то в базе можно хранить флажок типа «сбросить кеш привилегий сессии». Неправильная работа этого флажка не приведёт к ошибкам в работе системы в целом, так как в случае неустановки флажка система будет работать как и раньше, то есть запрет останется до перевхода пользователя, а в случае установки, когда изменений не было - система просто пересчитает данные из базы.

Но я, если честно, пока не вижу случаев, в которых немоментальная выдача привилегий была бы критична. Если они есть, я был бы рад, ели бы Вы мне на них указали.

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1551

Не разбирался пристально как реализовано кэширование у тебя в системе. Как разберу - прокомментирую.

По поводу системы где выдача привилегий критична, хотя подозреваю что это провокация

Корпоративный ресурс, например, где осуществляется доступ к конфиденциальным данным компании, с которым также работают партнёры компании (сторонние организации, получающие доступ к ресурсу, например, по ВПН), где оперативность доступа к информации имеет ОЧЕНЬ большое значение (то есть, предположим, счёт идёт на минуты). Партнёры осуществляют доступ к данным на коммерческой основе, то есть ежемесячной абонплатой за аккаунт. И вот, предположим, администратор допустил ошибку в раздаче прав и пользователю стали доступны вместо его данных чужие и в этот момент он залогинился. Задача становится так: надо запретить доступ к не его данным и разрешить к его. По описанной тобой выше схеме (которая применяется сейчас) ему просто ничего не будет доступно пока пользователь не перелогинится (и поверь, не все догадаются это сделать увидев надпись «Данных нет» или «Данные не доступны»), или, в зависимости от реализации, вообще выкинет из системы.
Таким образом оперативность доступа к данным, надёжность работы и юзабилити выходят на первое место. Как следствие, раздача привилегий, в любом направлении, должна быть мгновенной.
И это не притянутая к жизни ситуация а фактически взята из жизни.

popoff
Yuri
Июл, 2004
Сообщений: 923
popoff url://forum.message:1552

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

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

Поэтому, для предложенного Вами случая использование системы распределения привилегий может рассматривться только как временный вариант решения («затычка»). Для решения Вашей задчи следует создавать специализированную систему по продаже Ваших товаров.


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

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1553

Подход немного не с той стороны. Предложенный для примера ресурс не продаёт товар, а предлагает доступ к информации, которая и так принадлежит партнёру, плата берётся за интерфейс доступа к ней. Также, можно добавить и другой, не относящийся к категории товара функционал.
Допустим, корпоратив помимо доступа к данным (визуальное отображение статистических данных), предоставляет сервисы типа: приём заказов, заявлений, получение данных (файлов), отправка данных (файлов), управление (обработка) заказов/заявок, отслеживание обработки (на какой стадии) и т.д. У каждого партнёра есть свой администратор, который управляет привилегиями своих пользователей и может разрешать, либо запрещать доступ к тем или иным сервисам или данным. Внутри компании которая предоставляет услуги доступа и сервисы есть свои пользователи, которым нужен строго индивидуальный набор прав по работе с партнёрами. Кому-то доступны одни сервисы и функциональные возможности, другим другие сервисы и возможности, или в одних и тех же сервисах разные функциональные возможности. Грубо говоря, в системе каждый пользователь имеет свой индивидуальный набор привилегий. На группы пользователи разбиваются по принадлежности к партнёру. Они имеют доступ только к данным своей компании. Пользователи же компании которая предоставляет услуги тоже принадлежат к группе «Своя компания» но доступ к данным у них может быть абсолютный внутри определённого сервиса, или по избранным партнёрам и т.д.. Также возможна дополнительная разбивка на группы (например по отделам внутри компании, или по функциональным возможностям)
Предположим что в системе около 200 пользователей и каждый со своим «характером».
И не забывай, что при всём при этом, как мы предположили, данные имеют высокую степень конфиденциальности и желательно иметь какую-то дополнительную систему контроля привилегий (например, на уровне базы данных триггерами).

popoff
Yuri
Июл, 2004
Сообщений: 923
popoff url://forum.message:1554

Если Вы продаёте интерфейс доступа, значит товаром является интерфейс доступа. От того, рассматривать ли в качестве товара информацию или интерфейс доступа, суть моего ответа не меняется: в данном случае требуется принципиально другая система для проверки оплаченности ресурса.

Перед тем, как давать доступ, проверяются не только привилегии (кто куда может получить доступ), но и оплаченность ресурса (может ли вообще).

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

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1558

Ты меня убиваешь!...
С кэшированием я понял... Это и не основное что меня интересует. Мне интересно как применять твою систему в более крупном проекте чем, допустим, форум.

Пример был приведён как система где моментальная выдача привилегий была бы критична. Оплата доступа лишь дополнительный аргумент и взимается она не за каждый сервис в отдельности, а за доступ к системе в целом. Можем предположить что система бесплатна, но каждый пользователь имеет свой индивидуальный набор привилегий, но в рамках привилегий своей группы. Также, можем допустить что сервисы тоже группируются, то есть система имеет несколько модулей, доступ к которым тоже должен ограничиваться.

popoff
Yuri
Июл, 2004
Сообщений: 923
popoff url://forum.message:1559

Разработанная мной система управления привилегиями предназначена для больших систем.

Что именно Вам не понятно?

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.
Select
Фёдор Мечников
Сен, 2006
Сообщений: 16
Select url://forum.message:1562

Вот я ещё раз перепрочитаю статью, на всякий случай, потом сформулирую... То есть сделаю ещё одну самостоятельную попытку осилить.
А вкратции, не очень понятно как работать с группами в приведённом примере, как сделать так чтобы пользователь одного партнёра никак не унаследовал права другого, то есть не причислился к двум этим группам...

popoff
Yuri
Июл, 2004
Сообщений: 923
popoff url://forum.message:1564

У меня пользователи не могут наследовать права друг друга.
Списки привилегий администраторов могут наследовать списки привилегий ролей.
Списки привилегий ролей могут наследовать списки привилегий других ролей.
Для управления тем, кто чем может управлять, существуют специальные привилегии:
http://popoff.donetsk.ua/text/work/libs/passport/privilege/privileges.html

________________________________
Если не будет деревьев — нам нечем будет дышать, если вода загрязнится — нам нечего будет пить.

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

Страницы: [1]
<< Новый  |  Старый >>  |  Ответ не возможен
Вход
Поиск[?]:
porter.mir.dn.ua