есть пользователь №1, который юзает формы сайта (порой очень приличные, с глубокими запросами в бд), вносит инфу, правит её, и, соответственно, просматривает.
а есть пользователи №2, №3, ... №n, которые должны быть лишены прав внесения и изменения инфы, но, могут смотреть результат работы первого пользователя (таблицы, графики, диаграммы, др. данные).
все операции с данными (добавление, изменение, просмотр) завязаны на уникальный идентификатор пользователя. т.е. пользователи №2, №3 и т.д., имея другой идентификатор не смогут смотреть введенные данные пользователем №1 по определению.
сижу и думаю, как это лучше и ПРОЩЕ реализовать. и пришла мне мысль, а что если попробывать запаролить часть страниц, где расположены формы ввода и редактирования данных. в таком случае, пользователь №1 может дать свой аккаунт скольким угодно людям, не имея пасса доступа к запароленой части страницы, другие пользователи смогут только просматривать введенную инфу. это бы решило проблему привязки на id пользователя.
как думаете, такое реально реализовать (часть страниц под пароль)? или есть другие у кого идеи?
PS: кто хоть немного знаком с drupal, все запросы к базе, будь-то просмотр, добавление данных или их изменение - реализованы с помощью
global $user;
$user->uid;
Спустя 37 минут, 36 секунд (6.04.2011 - 00:45) Trianon написал(а):
plotkin
Если есть возможность (а у большинства современных хосингов такая возможность есть, не говоря уже о VDS) использовать дополнительный эккаунт для подключения к БД - то стоит дать ему ограниченные права ( на SELECT, но не на UPDATE DELETE INSERT ) к критичным таблицам.
И действия пользователей 2 3 4 выполнять через коннект от этого эккаунта.
Но.
Если есть возможность (а у большинства современных хосингов такая возможность есть, не говоря уже о VDS) использовать дополнительный эккаунт для подключения к БД - то стоит дать ему ограниченные права ( на SELECT, но не на UPDATE DELETE INSERT ) к критичным таблицам.
И действия пользователей 2 3 4 выполнять через коннект от этого эккаунта.
Но.
| Цитата |
| пользователь №1 может дать свой аккаунт скольким угодно людям |
Если пользователь №1 дает свой эккаун другому пользователю - тот автоматически становится им. По определению.
Спустя 9 часов, 41 минута, 58 секунд (6.04.2011 - 10:27) plotkin написал(а):
создать еще одного пользователя в базе и ограничить права - без проблем. единственное, я пока не понимаю, как реализовать привязку на подключение к базе через 2й, 3й, 4й и т.д. акки в drupal.
а на счет выдачи своего аккаунта пользователем №1:
дело в том, что он не раздает свой логин и пасс кому угодно. на сайте сидят n-ное кол-во групп пользоватлей. у каждой из этих групп есть свой пользователь №1, а есть пользователи, кому просто нужно смотреть. для каждой из этих групп тогда создавать отдельного юзера бд с ограниченными правами?
а на счет выдачи своего аккаунта пользователем №1:
дело в том, что он не раздает свой логин и пасс кому угодно. на сайте сидят n-ное кол-во групп пользоватлей. у каждой из этих групп есть свой пользователь №1, а есть пользователи, кому просто нужно смотреть. для каждой из этих групп тогда создавать отдельного юзера бд с ограниченными правами?
Спустя 1 час, 4 минуты, 49 секунд (6.04.2011 - 11:32) Trianon написал(а):
я не предлагал добавлять эккаунты по числу пользователей.
Только по числу ролей с идентичным набором привелегий.
Только по числу ролей с идентичным набором привелегий.
| Цитата |
| а на счет выдачи своего аккаунта пользователем №1: дело в том, что он не раздает свой логин и пасс кому угодно. |
Фразу "может дать свой аккаунт" по другому воспринять трудно.
Имеет смысл четче формулировать свои мысли.
Спустя 29 минут, 56 секунд (6.04.2011 - 12:02) plotkin написал(а):
если я правильно понял, предлагаете разграничить права с помощью ролей. тем более, что мой drupal должен это позволять не создавая доп. аккаунты в бд.
в блоке content расположены 3 формы: ввод, редактирование, просмотр.
если пользователь является главным юзером в своей группе, то его роль позволяет ему видеть все 3 формы и пользоваться, разумеется. а если это "второстепенный" пользователь, то его права позволят ему пользоваться только формой просмотра (тут не понятно, будет он видеть формы ввода и редактирования или нет).
теоретически, реализовать доступ к части блока по наличию прав роли возможно?
ЗЫ и все равно остро стоит вопрос по доступу к просмотру с идентификатором пользователя, отличным от того, что вводил информацию.
UPD: вариант вложенной авторизации реально реализовать?
тогда главный пользователь каждой группы сможет раздать свой акк всем участникам своей группы. без пасса для форм ввода информации никто не сможет менять данные в базе. алгоритм что-то вроде такого: представление делим на 2 части. одну часть подключаем по умолчанию (ту, что для всех), а вторую часть подключаем только по наличию уникальной сессии и кук (если пользователь прошел вложенную авторизацию).
в блоке content расположены 3 формы: ввод, редактирование, просмотр.
если пользователь является главным юзером в своей группе, то его роль позволяет ему видеть все 3 формы и пользоваться, разумеется. а если это "второстепенный" пользователь, то его права позволят ему пользоваться только формой просмотра (тут не понятно, будет он видеть формы ввода и редактирования или нет).
теоретически, реализовать доступ к части блока по наличию прав роли возможно?
ЗЫ и все равно остро стоит вопрос по доступу к просмотру с идентификатором пользователя, отличным от того, что вводил информацию.
UPD: вариант вложенной авторизации реально реализовать?
тогда главный пользователь каждой группы сможет раздать свой акк всем участникам своей группы. без пасса для форм ввода информации никто не сможет менять данные в базе. алгоритм что-то вроде такого: представление делим на 2 части. одну часть подключаем по умолчанию (ту, что для всех), а вторую часть подключаем только по наличию уникальной сессии и кук (если пользователь прошел вложенную авторизацию).