1 В БД записать пути к защищаемым разделам
2 В защищаемых скриптах (админка, к примеру) при их старте:
- получить текущий путь из массива $_SERVER
$PATH = $_SERVER['REQUEST_URI'].$_SERVER['SCRIPT_NAME'];
- получить доступные для текущего пользователя пути из БД
- если путь к данному скрипту есть среди доступных пользователю - выполнять его, если нет - редиректить с сообщением об ошибке.
Вот набросок, если подробней (к коду не сильно придирайтесь, важен сам принцип)
1. Есть 3 таблицы в БД: users, links, users2links
users - содержит данные о пользователе
id | login | pswd | date
1 | admin |dgksdsdv | 2011-05-24 14:44:39
2 | user1 |sdfdfsdf | 2010-12-24 15:00:39
links - путь к разделам и скриптам (в них проверяется право доступа)
id | path | text
110 | adminpath | <font color=red>Администрирование</font>
201 | personal | <font green>Личное</font>
users2links - связка пользователей и разделов
uid - внешний ключ колонки id таблицы users
lid - внешний ключ колонки id таблицы links
uid | lid
1 | 110
1 | 201
2 | 201
2. В скриптах, в частности, в админке - при старте проверяется право доступа
#скрипт /adminpath/index.php (uri: httр ://domain.local/adminpath)
<?php
// описываем ф-ции
function CheckAllowPage()
{
/** Получаем расположение скрипта*/
$PATH = $_SERVER['REQUEST_URI'].$_SERVER['SCRIPT_NAME'];
/** Убираем index из пути*/
$p1 = "/(\/)*index(.)*([A-Za-z0-9]*)/i";
$PATH = preg_replace($p1,"",$PATH);
/** собираем путь скрипта заново*/
$Path_array = explode("/",$PATH);
$PATH =strtolower(implode("/",$Path_array));
/** Проверяем права*/
return _checkAllowPageFromBd($PATH);
}
function _checkAllowPageFromBd($PATH)
{
global $OPSGlobal;
// $OPSGlobal - это массив, где содержатся указатели на класс БД и пользователя;
// заполняется при старте каждого скрипта
// $OPSGlobal["SES"]->uid содержит id текущего пользователя из таблицы users или 0, если не авторизован
// $OPSGlobal["SES"]->db->QueryObjects($SQL) выполняет запрос в БД и возвращает ассициативный массив с результатом (или пустой, если нет записей)
// Проверяем, есть ли среди доступных пользователю защищённых скриптов проверяемый
$SQL = 'SELECT links.path,links.text FROM links,users2links
WHERE users2links.uid = "'.$OPSGlobal["SES"]->uid.'" AND links.path="'.$PATH.'";';
$lnk = $OPSGlobal["SES"]->db->QueryObjects($SQL);
$cnt = count($lnk);
if ($cnt) return 1; // доступ разрешён
else return 0; // доступ закрыт
}
...
// исполняем скрипт
if ($OPSGlobal["SES"]->uid==0 || !CheckAllowPage()) redirect('/'); // редирект в случае если прав доступа нет
?>
<html>
<!-- страница-->
</html>
Спустя 1 час, 18 минут, 53 секунды (18.08.2011 - 14:54) m4a1fox написал(а):
ИМХО хз! А не проще ли проверять так. При заходе 
в админку, форма, в форму вбиваем логин и пасс, проверяем в БД, если ето админ, делаем сессию одну, если обычный юзер - то другую. А потом просто проверять сессию на то, кто ето есть такой. Сессию то не подделать, она на стороне сервера.... опять же - ИМХО!
в админку, форма, в форму вбиваем логин и пасс, проверяем в БД, если ето админ, делаем сессию одну, если обычный юзер - то другую. А потом просто проверять сессию на то, кто ето есть такой. Сессию то не подделать, она на стороне сервера.... опять же - ИМХО! Спустя 14 минут, 7 секунд (18.08.2011 - 15:09) slimper написал(а):
m4a1fox
Этот метод вроде как обычный. У него нет тех плюсов, что при моём.
Авторизация одна на всех, у админов и просто привелегированных появляются красивые ссылочки на закрытые разделы. Закрытых разделов можно насоздавать и потом так ими управлять проще.
Я же так могу отослать случайного пользователя на 404, вроде как знать не знаю, что за адрес, тут такова нет. Сессий у меня нет, я по кукам работаю. Ну и вообще так удобней и админить будет. В общем, я считаю, что в таком подходе много всяческих плюсов. Мне интересно, какие там минусы?
Этот метод вроде как обычный. У него нет тех плюсов, что при моём.
Авторизация одна на всех, у админов и просто привелегированных появляются красивые ссылочки на закрытые разделы. Закрытых разделов можно насоздавать и потом так ими управлять проще.
Я же так могу отослать случайного пользователя на 404, вроде как знать не знаю, что за адрес, тут такова нет. Сессий у меня нет, я по кукам работаю. Ну и вообще так удобней и админить будет. В общем, я считаю, что в таком подходе много всяческих плюсов. Мне интересно, какие там минусы?
Спустя 12 минут, 19 секунд (18.08.2011 - 15:21) m4a1fox написал(а):
slimper
ИМХО! Не я сказал! Но
ИМХО! Не я сказал! Но
| Цитата |
| я по кукам работаю |
Не есть ГУД! Не советуют так делать! Session куда надежнее....
Спустя 10 минут, 50 секунд (18.08.2011 - 15:32) slimper написал(а):
m4a1fox
хотя вопрос не по теме :-) Но!
Надёжней чем? Нет, пользу от сессий я понимаю. Но они не всегда нужны. Смысл в них привязать некий идентификатор к данным на сервере. Я же через куку привязываю данные пользователя к данным в базе. На гостей у меня постоянные дефолтные значения. В общем, пока сессии не потребовались.
хотя вопрос не по теме :-) Но!
Надёжней чем? Нет, пользу от сессий я понимаю. Но они не всегда нужны. Смысл в них привязать некий идентификатор к данным на сервере. Я же через куку привязываю данные пользователя к данным в базе. На гостей у меня постоянные дефолтные значения. В общем, пока сессии не потребовались.
Спустя 16 минут, 2 секунды (18.08.2011 - 15:48) m4a1fox написал(а):
slimperНу сам смотри! Удачи!
Спустя 10 минут, 14 секунд (18.08.2011 - 15:58) neadekvat написал(а):
А я так и не понял, что там автор мутит.
Вот я ввожу логин и пароль, допустим, я админ. Мне в куку записывается какое-то значение, которое впоследствии дает доступ к разделами админа? Или что мне в кукисы запишется?
Вот я ввожу логин и пароль, допустим, я админ. Мне в куку записывается какое-то значение, которое впоследствии дает доступ к разделами админа? Или что мне в кукисы запишется?
Спустя 1 минута, 37 секунд (18.08.2011 - 16:00) m4a1fox написал(а):
neadekvat
| Цитата |
| Или что мне в кукисы запишется? |
Хз
| Цитата |
| Мне в куку записывается какое-то значение, которое впоследствии дает доступ к разделами админа? |
Вроде так. Я ж говорю - сессии надежнее
Спустя 3 минуты, 46 секунд (18.08.2011 - 16:03) Игорь_Vasinsky написал(а):
Как я понял в 3 таблице связаны id разделов с id юзеров. Тока я не понял что за принцип привязки.......
На мой взгляд проще - при авторизации сравнил логин и пароль - если админ - то одна сессионая переменная - по которой везде зелёный свет - если не админ - то ходишь там и видишь то что разрешено обычному смертному.
UPD: нееет... куки бы я не использовал, а вот сессии - то самое.
На мой взгляд проще - при авторизации сравнил логин и пароль - если админ - то одна сессионая переменная - по которой везде зелёный свет - если не админ - то ходишь там и видишь то что разрешено обычному смертному.
UPD: нееет... куки бы я не использовал, а вот сессии - то самое.
Спустя 8 минут, 10 секунд (18.08.2011 - 16:12) slimper написал(а):
neadekvat
про куки и сессии - это офтоп. Не в этом суть.
В куку пишется стучайная комбинация, как и в сессии. При входе, если есть кука, смотрится, кому из регистрированных пользователей она принадлежит. если никому - удаляется, если есть - из БД в структуру пользователя считываются данные. А админ ты или нет - как раз смотрится по записям в таблице users2links. См таблицы выше.
Если в таблице users2links твой id привязан к id в таблице links, и запись эта ведёт к админке, то у тебя 1)появится ссылка на администрирование 2) ты туда сможешь зайти и собссно админить.
Если запись ведёт в другие разделы, то 1) у тебя появятся на них ссылки 2)ты сможешь туда зайти введя адрес руками.
Если ты гость но ввёл руками адрес админки, то тебя редиректит, может даже на 404, и ты может даже не узнаешь, что страница на самом деле есть, просто тебе туда нельзя.
Какие минусы? Вот в чем вопрос, который меня волнует прежде всего
про куки и сессии - это офтоп. Не в этом суть.
В куку пишется стучайная комбинация, как и в сессии. При входе, если есть кука, смотрится, кому из регистрированных пользователей она принадлежит. если никому - удаляется, если есть - из БД в структуру пользователя считываются данные. А админ ты или нет - как раз смотрится по записям в таблице users2links. См таблицы выше.
Если в таблице users2links твой id привязан к id в таблице links, и запись эта ведёт к админке, то у тебя 1)появится ссылка на администрирование 2) ты туда сможешь зайти и собссно админить.
Если запись ведёт в другие разделы, то 1) у тебя появятся на них ссылки 2)ты сможешь туда зайти введя адрес руками.
Если ты гость но ввёл руками адрес админки, то тебя редиректит, может даже на 404, и ты может даже не узнаешь, что страница на самом деле есть, просто тебе туда нельзя.
Какие минусы? Вот в чем вопрос, который меня волнует прежде всего
Спустя 9 минут, 14 секунд (18.08.2011 - 16:21) neadekvat написал(а):
1. В какой-то степени ты по сути реализовал механизм сессий.
2. Тебе каждый раз приходится тянуть из базы права пользователя в то время, как их можно хранить именно в сессионных переменных. Сформировал массив доступов и прочей лабуды, сериализовал - засунул в сессию, пришел пользователь - десериализовал массив.
Кроме того, с помощью сессий можно хоть немного, но увеличить безопасность - например, записать туда user-agent, ip-адрес и любую другую персонализированную информацию, которая защитит при банальной краже кукиса с идентификатором сессии.
2. Тебе каждый раз приходится тянуть из базы права пользователя в то время, как их можно хранить именно в сессионных переменных. Сформировал массив доступов и прочей лабуды, сериализовал - засунул в сессию, пришел пользователь - десериализовал массив.
Кроме того, с помощью сессий можно хоть немного, но увеличить безопасность - например, записать туда user-agent, ip-адрес и любую другую персонализированную информацию, которая защитит при банальной краже кукиса с идентификатором сессии.
Спустя 9 минут, 9 секунд (18.08.2011 - 16:30) m4a1fox написал(а):
Игорь_Vasinsky
| Цитата |
| Как я понял в 3 таблице связаны id разделов с id юзеров. Тока я не понял что за принцип привязки....... На мой взгляд проще - при авторизации сравнил логин и пароль - если админ - то одна сессионая переменная - по которой везде зелёный свет - если не админ - то ходишь там и видишь то что разрешено обычному смертному. UPD: нееет... куки бы я не использовал, а вот сессии - то самое. |
Почти слово в слово!
Спустя 2 минуты, 10 секунд (18.08.2011 - 16:32) m4a1fox написал(а):
slimper
Вот видишь! neadekvat, Игорь_Vasinsky и я тебе про это уже страницу расписали! Юзай сессию и не парся! ИМХО!
Вот видишь! neadekvat, Игорь_Vasinsky и я тебе про это уже страницу расписали! Юзай сессию и не парся! ИМХО!
Спустя 1 минута, 36 секунд (18.08.2011 - 16:34) slimper написал(а):
neadekvat
В общем, давайте забудем про куки и сессии. ЭТО НЕ ВАЖНО!
Важно, что при входе пользователя ему выдается id (НЕ ВАЖНО- ИЗ БД ИЛИ МАССИВА $_SESSION). Затем смотрится, какие разделы доступны канкретно вошедшему. На эти разделы появляются ссылки (в том куске, где обычно пишут "Привет, вы вошли как Вася." появится
<a..>"Администрирование"</a>, <a..>"Личное"</a>, итд). При переходе по ссылке на раздел там проверяется, а можешь ты сюда ходить или нет. Если да - видишь страницу, иначе-иначе.
В общем, давайте забудем про куки и сессии. ЭТО НЕ ВАЖНО!
Важно, что при входе пользователя ему выдается id (НЕ ВАЖНО- ИЗ БД ИЛИ МАССИВА $_SESSION). Затем смотрится, какие разделы доступны канкретно вошедшему. На эти разделы появляются ссылки (в том куске, где обычно пишут "Привет, вы вошли как Вася." появится
<a..>"Администрирование"</a>, <a..>"Личное"</a>, итд). При переходе по ссылке на раздел там проверяется, а можешь ты сюда ходить или нет. Если да - видишь страницу, иначе-иначе.
Спустя 2 минуты, 38 секунд (18.08.2011 - 16:36) m4a1fox написал(а):
slimper
| Цитата |
| при входе пользователя ему выдается id |
- auto_increment, primary key?
Спустя 2 минуты, 51 секунда (18.08.2011 - 16:39) neadekvat написал(а):
slimper, это все создает избыточность, как в коде, так и в базе данных. Кроме этих, я уже описал и другие плюсы использования стандартных сессий.
Твой вопрос выглядит как-то так:
- Ну и что, что я жарю в кастрюле? Какие плюсы от жарки на сковородке то?
Твой вопрос выглядит как-то так:
- Ну и что, что я жарю в кастрюле? Какие плюсы от жарки на сковородке то?
Спустя 2 минуты, 32 секунды (18.08.2011 - 16:42) slimper написал(а):
m4a1fox
Не придирайся. Уникальная комбинация, основаная на генераторе чисел,времени
столбец unique, при добавлении проверяется на повтор. так что там всё чисто
вообще все id во всех таблицах - строки с длиной 24 символа из генератора.
define('OPS_SYSTEM_KEY_START',2);
define('OPS_SYSTEM_KEY_STOP' ,16);
function OPSGetRandomKey($l=0) {
# из чего генерируем
$alphabet = "abcdefghijklmnopqrstuvwxyz1234567890";
$alphalen = strlen($alphabet);
$key="";
# запускаем генератор
mt_srand((double)microtime()*1000000);
if($l == 0)
$keylength=mt_rand(OPS_SYSTEM_KEY_START,OPS_SYSTEM_KEY_STOP);
else
$keylength=min(OPS_SYSTEM_KEY_STOP,max(OPS_SYSTEM_KEY_START,$l));
for ($i=0; $i<$keylength ; $i++) {
$key .= substr($alphabet, mt_rand() % $alphalen, 1);
}
return $key;
}
Не придирайся. Уникальная комбинация, основаная на генераторе чисел,времени
столбец unique, при добавлении проверяется на повтор. так что там всё чисто
вообще все id во всех таблицах - строки с длиной 24 символа из генератора.
define('OPS_SYSTEM_KEY_START',2);
define('OPS_SYSTEM_KEY_STOP' ,16);
function OPSGetRandomKey($l=0) {
# из чего генерируем
$alphabet = "abcdefghijklmnopqrstuvwxyz1234567890";
$alphalen = strlen($alphabet);
$key="";
# запускаем генератор
mt_srand((double)microtime()*1000000);
if($l == 0)
$keylength=mt_rand(OPS_SYSTEM_KEY_START,OPS_SYSTEM_KEY_STOP);
else
$keylength=min(OPS_SYSTEM_KEY_STOP,max(OPS_SYSTEM_KEY_START,$l));
for ($i=0; $i<$keylength ; $i++) {
$key .= substr($alphabet, mt_rand() % $alphalen, 1);
}
return $key;
}
Спустя 8 минут, 10 секунд (18.08.2011 - 16:50) m4a1fox написал(а):
slimper
ИМХО! Как то сложно все!
ИМХО! Как то сложно все!
Спустя 20 минут, 59 секунд (18.08.2011 - 17:11) Guest написал(а):
slimper
тебе дело говорят - не упирайся... Сессии для того и были придуманы. Так как ты рассуждают те, кто еще не полностью врубился что к чему. А раз тебе советуют - прислушайся =)
тебе дело говорят - не упирайся... Сессии для того и были придуманы. Так как ты рассуждают те, кто еще не полностью врубился что к чему. А раз тебе советуют - прислушайся =)
Спустя 19 часов, 11 минут, 58 секунд (19.08.2011 - 12:23) slimper написал(а):
Получилось - кто про Фому, кто про Ерёму. Вопрос, стало быть, задал неправильно. За что извиняюсь. Попробую заново.
В общем, нужно поделить пользователей по категориям и раздать им права на разделы сайта. Допустим есть 3 раздела, где нужно ограничить доступ: /adminpath, /management, /worker.
Адреса их соответственно: (_http://domain.local/adminpath, _http://domain.local/management, _http://domain.local/worker)
Как это обычно решается? Вариант, двумя таблицами: users (пользователи) и role (роли)
Таблица users будет иметь поля: id | login | password | date | role
-Где поле role содержит идентификатор из таблицы role по внешнему ключу
Таблица role будет иметь поля: id | text
Пример заполнения
users:
id | login | password | date | role
100 | slimper | sgsdgdfdg | 2001-05-24 14:44:39 | 1
210 | Vasia | dfgrjhert | 2009-06-25 12:44:39 | 2
87 | Petia | ssetwe | 2007-03-25 10:44:39 | 3
32 | Joe | sdfsdfg | 2007-03-25 10:44:39 | 0
role:
id | text
1 | admin
2 | manager
3 | worker
0 |
Как проверяется право доступа в каждом из разделов? Определяется постоянная переменная в начале скрипта, с которой сравнивается имеющаяся у пользователя?
В /adminpath: define('AUTH','admin');
В /management define('AUTH','manager');
В /worker define('AUTH','worker');
Получить роль пользователя:
SELECT role.text FROM role,users WHERE users.role=role.id AND users.id = ??(тут ид пользователя)
записать результат в переменную, допустим $db_userrole и сравнить её с $AUTH в соответствующем скрипте. if($db_userrole==AUTH)Если совпадает - работаем, если нет - то нет.
Этот способ можно переделать на разные лады, но самый главный вопрос: Как скрипт проверяет право доступа пользователя к себе?
Он Должен!! содержать правлильный признак, чтобы с ним сравнивать предьявляемый пользователем. В этом примере скрипты содержат павильный признак в виде наглухо зашитой в скрипте переменной $AUTH, где записан правильный ответ на вопрос доступа.
В моём предложении (см. первое сообщение темы) я предлагаю сделать таким признаком путь к самому скрипту. Т.е. вычислить путь скрипта и сравнить его с путями, доступными пользователю.
Таки сам вопрос! Верно ли моё предложение и какие у него минусы?
В общем, нужно поделить пользователей по категориям и раздать им права на разделы сайта. Допустим есть 3 раздела, где нужно ограничить доступ: /adminpath, /management, /worker.
Адреса их соответственно: (_http://domain.local/adminpath, _http://domain.local/management, _http://domain.local/worker)
Как это обычно решается? Вариант, двумя таблицами: users (пользователи) и role (роли)
Таблица users будет иметь поля: id | login | password | date | role
-Где поле role содержит идентификатор из таблицы role по внешнему ключу
Таблица role будет иметь поля: id | text
Пример заполнения
users:
id | login | password | date | role
100 | slimper | sgsdgdfdg | 2001-05-24 14:44:39 | 1
210 | Vasia | dfgrjhert | 2009-06-25 12:44:39 | 2
87 | Petia | ssetwe | 2007-03-25 10:44:39 | 3
32 | Joe | sdfsdfg | 2007-03-25 10:44:39 | 0
role:
id | text
1 | admin
2 | manager
3 | worker
0 |
Как проверяется право доступа в каждом из разделов? Определяется постоянная переменная в начале скрипта, с которой сравнивается имеющаяся у пользователя?
В /adminpath: define('AUTH','admin');
В /management define('AUTH','manager');
В /worker define('AUTH','worker');
Получить роль пользователя:
SELECT role.text FROM role,users WHERE users.role=role.id AND users.id = ??(тут ид пользователя)
записать результат в переменную, допустим $db_userrole и сравнить её с $AUTH в соответствующем скрипте. if($db_userrole==AUTH)Если совпадает - работаем, если нет - то нет.
Этот способ можно переделать на разные лады, но самый главный вопрос: Как скрипт проверяет право доступа пользователя к себе?
Он Должен!! содержать правлильный признак, чтобы с ним сравнивать предьявляемый пользователем. В этом примере скрипты содержат павильный признак в виде наглухо зашитой в скрипте переменной $AUTH, где записан правильный ответ на вопрос доступа.
В моём предложении (см. первое сообщение темы) я предлагаю сделать таким признаком путь к самому скрипту. Т.е. вычислить путь скрипта и сравнить его с путями, доступными пользователю.
Таки сам вопрос! Верно ли моё предложение и какие у него минусы?