Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > Скриптовые языки программирования > PHP
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 06.04.2011, 11:32   #1
silvestr
Пользователь
 
Регистрация: 04.04.2011
Сообщений: 38
По умолчанию делегирование части прав пользователя

есть пользователь №1, который юзает формы сайта (порой очень приличные, с глубокими запросами в бд), вносит инфу, правит её, и, соответственно, просматривает.

а есть пользователи №2, №3, ... №n, которые должны быть лишены прав внесения и изменения инфы, но, могут смотреть результат работы первого пользователя (таблицы, графики, диаграммы, др. данные).

все операции с данными (добавление, изменение, просмотр) завязаны на уникальный идентификатор пользователя. т.е. пользователи №2, №3 и т.д., имея другой идентификатор не смогут смотреть введенные данные пользователем №1 по определению.

сижу и думаю, как это лучше и ПРОЩЕ реализовать. и пришла мне мысль, а что если попробывать запаролить часть страниц, где расположены формы ввода и редактирования данных. в таком случае, пользователь №1 может дать свой аккаунт скольким угодно людям, не имея пасса доступа к запароленой части страницы, другие пользователи смогут только просматривать введенную инфу. это бы решило проблему привязки на id пользователя.

PS: кто хоть немного знаком с drupal, все запросы к базе, будь-то просмотр, добавление данных или их изменение - реализованы с помощью

PHP код:
global $user;
$user->uid
и еще момент, дело в том, что пользователь №1 не раздает свой логин и пасс кому угодно. на сайте сидят n-ное кол-во групп пользователей. у каждой из этих групп есть свой пользователь №1, а есть пользователи, кому просто нужно смотреть. в рамках каждой группы (если запаролить формы ввода и редактирования информации), главный пользователь и раздавал бы свой акк остальным, при условии, что часть страницы будет закрыта от других.

как думаете, такое реально реализовать (часть страниц под пароль)? или есть другие у кого идеи?
silvestr вне форума Ответить с цитированием
Старый 06.04.2011, 11:46   #2
ssdm
Форумчанин
 
Регистрация: 20.05.2009
Сообщений: 506
По умолчанию

Имхо вам надо использовать роли.
ssdm вне форума Ответить с цитированием
Старый 06.04.2011, 11:47   #3
ssdm
Форумчанин
 
Регистрация: 20.05.2009
Сообщений: 506
По умолчанию

http://www.yiiframework.com/doc/guid...ru/topics.auth
http://kotishka.homeip.net/mvc-php/authorization
Вот например , почитайте.

Да и просто гуглите
Цитата:
авторизация роли php
, статей много.
ssdm вне форума Ответить с цитированием
Старый 06.04.2011, 12:25   #4
silvestr
Пользователь
 
Регистрация: 04.04.2011
Сообщений: 38
По умолчанию

светлая голова!

тем более, что в моем drupal это все реализовано уже. осталось разобраться, как этим воспользоваться.

спасибо за мысль.
silvestr вне форума Ответить с цитированием
Старый 06.04.2011, 16:18   #5
silvestr
Пользователь
 
Регистрация: 04.04.2011
Сообщений: 38
По умолчанию

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

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

поэтому единственная идея, что у меня возникает пока - авторизация внутри авторизации.

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

внутренняя дополнительная авторизация даст право на просмотр форм ввода и редактирования информации.

вот только не могу понять, как реализовать эту самую вложенную авторизацию.
silvestr вне форума Ответить с цитированием
Старый 06.04.2011, 16:54   #6
ssdm
Форумчанин
 
Регистрация: 20.05.2009
Сообщений: 506
По умолчанию

Вы бы лучше расписали что сделать надо, было бы проще помочь.
Как я понимаю у вас есть группы пользователей и в каждой группе есть админ.
Тогда админу можно выставить роль "АдминГруппы" , а пользователям группы роль "ЮзерГруппы". Ну и соответственно юзеров и админа надо привязать к группе( группы могут динамически изменятся(названия) , добавляться, удалятся ).

Add : Соответственно контент привязываешь к определенной группе(группам).

Последний раз редактировалось ssdm; 06.04.2011 в 16:56. Причина: Add
ssdm вне форума Ответить с цитированием
Старый 06.04.2011, 17:27   #7
silvestr
Пользователь
 
Регистрация: 04.04.2011
Сообщений: 38
По умолчанию

да, я уже думал над этим. но видите ли в чем беда:

1. либо вводить идентификатор группы пользователей, что заставит переписать все на свете, от запросов в базу, до самой базы. а это титанический труд, т.к. писалось несколько недель.

2. либо реализовать "вложенную авторизацию" и наделить каждую группу пользователей всего одним аккаунтом на всех.

UPD: в первом варианте придется перелопатить несколько тысяч строк кода модели, порядка 15 контроллеров и перевязать все от идентификатора пользователя к идентификатору группы. в этом случае уже внутри группы можно варьировать подключение представления. если ты админ группы, то подключаем тебе одно представление, если ты не админ, - другое.

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

Последний раз редактировалось silvestr; 06.04.2011 в 17:49. Причина: upd 2
silvestr вне форума Ответить с цитированием
Старый 06.04.2011, 17:47   #8
ssdm
Форумчанин
 
Регистрация: 20.05.2009
Сообщений: 506
По умолчанию

Цитата:
1. либо вводить идентификатор группы пользователей, что заставит переписать все на свете, от запросов в базу, до самой базы. а это титанический труд, т.к. писалось несколько недель.
На самом деле переделывать все равно придется ,так не лучше ли сразу делать правильно ?!
Вы сейчас столкнулись с ошибкой при проектирование ,чем дольше тянуть будете с её устранением - тем больнее будет когда придется все переделывать )

Скиньте схему вашей базы данных .возможно не все так страшно как вам кажется.
ssdm вне форума Ответить с цитированием
Старый 06.04.2011, 18:04   #9
silvestr
Пользователь
 
Регистрация: 04.04.2011
Сообщений: 38
По умолчанию

Цитата:
Сообщение от ssdm Посмотреть сообщение
На самом деле переделывать все равно придется ,так не лучше ли сразу делать правильно ?!
Вы сейчас столкнулись с ошибкой при проектирование ,чем дольше тянуть будете с её устранением - тем больнее будет когда придется все переделывать )
ну почему же, вроде бы я даже уже нашел решение постом выше.

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

а так админ группы региться, устанавливает пасс, который потом по требованию будет ставить печеньку и раздает свой акк всей своей группе.
silvestr вне форума Ответить с цитированием
Старый 06.04.2011, 18:31   #10
ssdm
Форумчанин
 
Регистрация: 20.05.2009
Сообщений: 506
По умолчанию

Цитата:
Сообщение от silvestr Посмотреть сообщение
ну почему же, вроде бы я даже уже нашел решение постом выше.

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

а так админ группы региться, устанавливает пасс, который потом по требованию будет ставить печеньку и раздает свой акк всей своей группе.
Ну можно и так.
Сначала входишь как юзер группы, видишь контент, при попытке добавления/изменения/удаления - запрашиваешь пароль админа.
ssdm вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Делегирование событий в IE6 Виталий Желтяков JavaScript, Ajax 3 01.11.2010 21:58
Отображение информации в зависимости от прав пользователя bush007 PHP 7 11.12.2009 11:05
Повышение прав пользователя ikot Win Api 9 27.08.2009 09:23
Получение прав другого пользователя Квэнди Win Api 14 28.07.2008 14:49
Назначение прав пользователя Seqular Безопасность, Шифрование 1 04.08.2007 16:48