Разрешение доступа к скрипту в .htaccess
Ситуация такая.Поставлен запрет на отображение содержимого каталога при отсутствии индексного файла.Но нужно дать доступ к одному скрипту,крон будет запускать.
order allow,deny allow from all php_value include_path . / Options -Indexes DirectoryIndex index.php AddDefaultCharset utf-8 #php_flag display_errors 1 #php_value error_reporting 6135 php_value session.cookie_domain myskbonus.ru RewriteEngine On #чпу RewriteCond % !-d RewriteCond % !-f RewriteRule ^([a-z]+)$ index.php?dir=$1&page=index&action=index&% [QSA,L] RewriteRule ^([a-z]+)(/|)$ index.php?dir=$1&page=index&action=index&% [QSA,L] RewriteRule ^([a-z]+)/([a-z]+)(/|)$ index.php?dir=$1&page=$2&action=index&% [QSA,L] RewriteRule ^([a-z]+)/([a-z]+)/([a-zA-Z\_\-]+)(/|)$ index.php?dir=$1&page=$2&action=$3&% [QSA,L] #RewriteRule ^(.*)$ index.php?dir=welcome&page=index&action=page404 [L] #Доступ к сайту только по HTTPS #RewriteCond % !on #RewriteRule (.*) https://%% # Включение PHP short_tag php_value short_open_tag 1 Order Allow,Deny Deny from all #Разрешить доступ к index.php всем order allow,deny allow from all order allow,deny allow from all Order Allow,Deny Allow from all Как разрешить доступ всем ролям ко всем действиям всех контроллеров
Как разрешить доступ всем ролям ко всем действиям всех контроллеров, но если контроллер User, разрешить доступ только роли admin ?
2 ответа 2
Необходимо переопределить behaviors конкретно для UserController .
class BaseController extends Controller < public function behaviors() < return [ 'verbs' =>[ 'class' => VerbFilter::className(), 'actions' => [ 'logout' => ['post'], ], ], ]; > > class UserController extends BaseController < public function behaviors() < $behaviors = parent::behaviors(); $behaviors['access'] = [ 'class' =>AccessControl::className(), // We will override the default rule config with the new AccessRule class 'ruleConfig' => [ 'class' => AccessRule::className(), ], 'rules' => [ [ 'roles' => ['admin'], 'allow' => true, ], ], ]; return $behaviors; > > Т.е BaseController должен содержать общие фильтры/ограничения для все контроллеров, которые от него наследуются.
Если обраться к исходникам yii2, то можно заметить, что матчинг контроллера происходит по свойству Controller::$uniqueId . Далее, смотрим в исходники Controller.php, где присутсвует метод Controller::getUniqueId() . id контроллера определяется в зависимости от используемого модуля (к примеру, если ваше приложение разделено на frontend (то что видет пользователь), backend (админка) и т.д.). Я не знаю какой у вас модуль, наверно дефолтный ( Application ), потому «решение в лоб» — переопределяем getUniqueId() :
class UserController extends BaseController < public function getUniqueId() < return 'user'; >> Если всё же дефолтный, то достаточно указать свойство Controller::$id :
class UserController extends BaseController
Далее в BaseController ваше ‘controllers’ => [‘user’] должно сработать.
class BaseController extends Controller < public function behaviors() < return [ 'access' =>[ 'class' => AccessControl::className(), 'ruleConfig' => [ 'class' => AccessRule::className(), ], 'rules' => [ [ 'controllers' => ['user'], 'roles' => ['admin'], 'allow' => true, ], [ 'controllers' => ['user'], 'allow' => false, ], ], ], 'verbs' => [ 'class' => VerbFilter::className(), 'actions' => [ 'logout' => ['post'], ], ], ]; > > PHP :: Определение прав доступа к файлам и папкам
При размещении файлов сайта на веб-сервере Unix разработчик сталкивается с необходимостью определения прав доступа для каждого отдельного файла или каталога. Права доступа определяют кто и что может делать с данным файлом или каталогом. Существуют три основных вида прав доступа:
- чтение содержимого файла или просмотр перечня имен файлов в каталоге;
- запись файла или создание и удаление файлов из каталога;
- запуск файлов (например, скриптов) или доступ к файлам в каталоге.
Все перечисленные виды прав назначаются одной из трех групп пользователей (отношение пользователей к той или иной группе определяется сервером в момент их подключения к нему):
- user (владелец файла) – это пользователь, который создает данный файл или папку, и затем подключается к серверу, например, по протоколу FTP под своим именем и паролем;
- group (группа, к которой принадлежит владелец файла) – это другие пользователи, которые также подключаются к серверу по протоколу FTP и пытаются получить доступ к файлам или каталогам непосредственного владельца;
- other (все остальные пользователи) – это все посетители сайта, которые заходят на него через свой браузер.
Сами права доступа обозначаются либо при помощи букв r (чтение), w (запись), x (исполнение) в формате ixxxyyyzzz , либо при помощи трехзначного числа в восьмеричной системе счисления (цифры от 0 до 7 ) в формате 0nnn . Первая группа букв или цифра устанавливают права для владельца файла, вторая – для группы, а третья – для всех остальных. Что касается первой буквы в символьном формате, то она указывает на то, что права доступа назначаются либо директории, тогда ставится буква d , либо обычному файлу, тогда ставится дефис — . Если вместо буквы указан дефис, то данный вид прав для соответствующей группы отсутствует. Например, файл с правами доступа -rwxrwxrwx или 0777 могут читать, записывать и запускать все группы пользователей, а вот директорию с правами доступа drwxr—r— или 0744 может просматривать, удалять и создавать в ней файлы, а также получать доступ к файлам только владелец. Остальным группам разрешается лишь просмотр каталога. Реальный пример отображения прав доступа к файлам на хостинге показан на рис. №1 .
Рис. №1. Пример отображения прав доступа на сервере
Нас будет интересовать числовой формат определения прав доступа к файлам и каталогам, расшифровка цифр которого представлена в таблице №2 .
| Числовой формат | Символьный формат | Права доступа |
|---|---|---|
| 0 | — | Права отсутствуют |
| 1 | —x | Только выполнение |
| 2 | -w- | Только запись |
| 3 | -wx | Запись и выполнение |
| 4 | r— | Только чтение |
| 5 | r-x | Чтение и выполнение |
| 6 | rw- | Чтение и запись |
| 7 | rwx | Чтение, запись, выполнение |
Таблица №2. Таблица прав доступа в цифровом формате
Теперь, когда мы получили некоторое представление о правах доступа к файлам и каталогам, продемонстрируем определение прав доступа к файлу на примере №3 .
'; //fileperms()- возвращает информацию о правах доступа в виде 10-го //числа (или false). После перевода в восьмеричное число, последние //4 цифры будут содержать сведения о правах доступа, а также //(на большинстве платформ) инф-цию о типе файла. Например, для файла //test_2.php на рис. 9.1 получим 33188 или в 8-й 100644 echo substr(decoct(fileperms('test_2.php')), -4); //Выведет 0644 echo '
'; echo '-------- chmod() --------
'; //chmod() - изменяет режим доступа к файлу и возвращает true|false chmod('test_2.php', 0777); //Разрешили всем все права chmod('test_2.php', 0744); //Владельцу все, остальным только чтение chmod('test_2.php', 0755); //Владельцу все, остальным чтение и запись ?>
Также обратите внимание на функции chown() , chgrp() , umask() . Все они находятся в «Функции для работы с файловой системой» -> «Файловая система» .
Быстрый переход к другим страницам
html.okpython.net Copyright © 2016-2023.
Реализовываем роли доступа на PHP сайте
Добрый вечер, господа. Сейчас разрабатываю интернет-магазин на самописной CMS. И возникла необходимость реализовать роли доступа для администратора, пользователя, гостя и модератора. Но как их реализовать понятия не имею, а поисковые системы пока не дали ответ на этот вопрос. Поделитесь, пожалуйста, ссылками, что нужно почитать или поделитесь опытом. Заранее спасибо!
простой способ — добавьте поле role в таблицу пользователей, и распределите ранги, допустим role = 1 — обычный пользователь, role = 2 — зарегистрированный пользователь, role = 3 — администратор. А где вам нужно просто дёргайте значение role и проверяйте условиями
2 ответа 2
Самый тривиальный способ: нужно каждому юзеру назначить уровень доступа, а при совершении какого-то действия – проверять, достаточно ли у него прав. Например, вот таблица пользователей:
id | login | pwd | rank 1 | admin | *** | 99 2 | user | *** | 1 3 | user2 | *** | 1 4 | manager | *** | 50 5 | superadmin | *** | 100 Допустим, при аутентификации данные о пользователе записываются в сессию так:
$_SESSION['user'] = array( 'id' => 4, 'login' => 'manager', 'rank' => 50, ); Тогда при совершении какого-то действия нужно просто проверять, достаточно ли у текущего пользователя прав:
. if ($_GET['action'] == 'save-user-profile') < if ($_SESSION['user']['rank'] >= 50) < $db->users->replacerow($_POST['profile']); echo 'Профиль успешно сохранен'; > else < header($_SERVER['SERVER_PROTOCOL'].' 403 Forbidden'); die('Недостаточно прав для совершения операции'); >> . Еще можно по-сложному. Например, завести список всех возможных действий (редактирование своего профиля, редактирование чужого профиля, удаление учетной записи, комментирование, . N), хранить эти все разрешения и привязывать к учетной записи. А при попытке совершить какое-то действие — проверять, разрешено ли это конкретному пользователю:
$action = $_GET['action']; if ($action == 'save-user-profile') < if ($_SESSION['user']['access'][$action]) < $db->users->replacerow($_POST['profile']); echo 'Профиль успешно сохранен'; > else < header($_SERVER['SERVER_PROTOCOL'].' 403 Forbidden'); die('Недостаточно прав для совершения операции'); >> Этот подход сложнее: нужно продумать стратегию хранения этих разрешений, придумать, как исключить коллизии в их наименованиях. Зато вы всегда сможете какому-то конкретному пользователю дать возможность, скажем, удалять профили, при этом не давая возможность редактировать их.
В простейшем случае в базе данных создается таблица возможных ролей, а в таблицу пользователя добавляется ссылка на нее. При авторизации в сессию пользователя записывается его роль. После чего при отображении любого раздела или даже элемента на странице можно проверить роль пользователя и разрешить либо запретить ему доступ. Если же пользователь не авторизован, ему можно присвоить роль по-умолчанию, вроде гостя. Чуть подробней с более сложным примером данной модели можно почитать здесь: Управление привилегиями пользователя на основе ролей. С некоторыми различиями и усложнениями, это самая распространенная схема разграничения прав пользователей на сайтах, насколько я могу судить.
Дополнительно можно почитать про ACL, которая часто используется совместно с ролями. При этом каждому пользователю назначается список операций, которые он может совершать в отношении того или иного субъекта (например, статьи или записи в блоге). При этом список может назначаться как для каждого отдельного пользователя, так и для группы пользователей (роли).
Это, конечно, не все. Различных систем контроля доступа много. Думаю, полезным будет ознакомиться с тем как это реализовано в других CMS.
Похожие
Подписаться на ленту
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.7.21.43541
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.