2013-11-27 3 views
2

Я работаю над системой инвентаризации веб-приложений, которая включает в себя различные уровни пользовательских разрешений и микроуправление отдельными разрешениями на этих уровнях. Поэтому большинство администраторов имеют все разрешения, но вы можете создать администратора и убрать их с определенного разрешения. В конечном счете эти разрешения хранятся в виде битовой строки в базе данных MySQL, где 1 означает, что у них есть разрешение, а 0 означает, что они не имеют. Я работаю над тем, чтобы сделать систему более эффективной, не жертвуя безопасностью. Вместо того чтобы запускать поиск по базе данных и проверять разрешения каждый раз, когда пользователь хочет выполнить какое-либо действие, я хотел бы кэшировать разрешения в переменной сеанса PHP вместе с меткой времени, когда эти разрешения были удалены с сервера.PHP Глобальная отметка времени для кэширования разрешений

$query_getUser = $this->User->prepare("SELECT * FROM users WHERE Email = ?"); 
$query_getUser->bindParam(1, $Email); 
$query_getUser->execute(); 
$result = $query_getUser->fetchAll(PDO::FETCH_ASSOC); 
$date = new DateTime(); 

session_start();       
$_SESSION['Email'] = $Email;       
$_SESSION['Password'] = $Password;      
$_SESSION['Timestamp']= $date->getTimestamp();  
$_SESSION['Permissions']= $result['Permissions']; 

Основная проблема, с которой я столкнулся, заключается в том, где хранить глобальную переменную для этого. Что было бы самым безопасным местом? По сути, я хочу, чтобы глобальная текущая дата кеша хранилась где-нибудь, где я могу получить к ней доступ для сравнения в O (1) раз.

Кроме того, существуют ли какие-либо серьезные проблемы с разрешениями реализации таким образом? Если разрешения пользователя изменены редко, а новый пользователь еще не имеет разрешений, пока он не будет добавлен в систему (поэтому create_user не вызывает обновление кеша, а modify_user), является ли это разумным подходом?

+0

+1 для структурированного вопроса и подготовленных заявлений. – Jonast92

ответ

0

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

Что-то вроде этого:

class Auth { 
    public static function has_privilege($privilege) { 
     $privileges = static::_get_privileges(); 
     if(in_array($privilege, $privileges)) { 
      return true; 
     } 
     return false; 
    } 
    protected static function _get_privileges() { 
     $from_session = $_SESSION['Privileges']; 
     $last_update = $_SESSION['Timestamp']; 
     if(time() - $last_update > 60*60*24) { // One day 
      // Fetch them from the DB 
     } 
     else { 
      return $from_session; 
     } 
    } 
} 

А затем проверить привилегию, как это:

if(\Auth::has_privilege('do_something')) { 
    echo 'You can do something.'; 
} else { 
    echo 'You cannot do something.'; 
} 

Было бы лучше, чтобы все это как часть User класса, но это должно дать вам идея.

Теперь, с точки зрения безопасности, это зависит от вашей системы. Функциональность сеанса PHP по умолчанию хранит информацию о сеансе в файлах в каталоге /tmp, поэтому пока этот каталог защищен, ваш сеанс будет безопасным. Вещь, о которой вы должны беспокоиться, - это захват сеанса, но это не зависит от вашей проблемы с хранилищем привилегий.

+0

Если я это правильно понимаю, это в основном установит тайм-аут на разрешения пользователя. То, что я пытаюсь сделать, - это автоматический тайм-аут прав пользователя при изменении разрешения. Так что, если, например, пользователь лишится своих прав администратора и они только вошли в систему до этого, это изменение вступит в силу в следующий раз, когда они попытаются выполнить действие, требующее разрешения. – Don

+0

Тогда нет возможности сохранить их в сеансе без необходимости запрашивать DB каждый раз, если вы не хотите другого механизма хранения. Что случилось с запросом базы данных каждый раз для получения привилегий? – jraede

+0

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

Смежные вопросы