Стоит ли хранить зашифрованные данные пользователя в Local/Session Storage на клиенте?

Доброго времени суток!
Задумка:
При входе в систему 1-н раз сделать запрос на права пользователя (его действия с объектами, например, имеет ли пользователь обращаться к определенной таблице или делать вставку, кто он и т.д.). На выходе получаю (пример) следующее результирующее множество в виде многомерного массива:
$arr = [ 
    [
        'r' => 'Администратор',
        'og' => 'Таблицы', 
        'obj' => 't1', 
        'ac' => 'SELECT'
    ],
    [    
        'r' => 'Администратор',
        'og' => 'Таблицы',
        'obj' => 't1', 
        'ac' => 'INSERT' 
    ],
    [    
        'r' => 'Администратор',
        'og' => 'Таблицы', 
        'obj' => 't1', 
        'ac' => 'UPDATE'
    ],
    [    
        'r' => 'Администратор',
        'og' => 'Таблицы', 
        'obj' => 't1', 
        'ac' => 'DELETE'
    ],
    [    
        'r' => 'Администратор',
        'og' => 'Таблицы', 
        'obj' => 't2', 
        'ac' => 'SELECT'
    ],
    [    
        'r' => 'Администратор',
        'og' => 'Формы', 
        'obj' => 'log', 
        'ac' => 'INSERT'
    )
  ];


Что хочу:
Сгенерировать пригодное для хранения представление массива (сериализовать) и закодировать полученные данные. Далее отправить код хранится в Session Storage.

Для чего:
Тут, скорее, уже ближе подхожу к своему вопросу, который напишу ниже.
Чисто субъективное мнение, чтобы каждый раз не обращаться к БД и не тратить на это время, можно получить зашифрованные данные из хранилища браузера и передать обработчику, который, в свою очередь, рассериализует и раскодирует зашифрованные данные в обратном порядке. А с помощью пользовательской ф-ции, например такой:
function handler(array $arr, ...$par) {
    $flag = false;
    if (is_array($arr)) {
        foreach ($arr as $key => $val) {
          if(is_array($val)) {
            $compare = array_diff($par, array_values($val));
                if (count($compare) < 1) {
                    $flag = true;
                    return $flag;
                }
            }
        }
    }
}

$q = handler($arr, 't1','INSERT', 'Таблицы');
if ($q) {
    echo "Совпадения найдены!";
}
else {
    echo "Совпадения НЕ найдены!";
}

смогу понять, к примеру, может ли пользователь делать записи в таблицу "t1" или нет, какая у него роль и т.п.
Т.е. все эти манипуляции для того, чтобы каждый раз не обращаться к БД.

Теперь САМ ВОПРОС:
1. Стоит ли так делать и почему;
2. Какой будет прирост производительности (разница обращение к файлу обработчика vs стучаться в БД);
3. Как Вы решаете подобные вопросы.

Если я ошибаюсь, подскажите пути решения!

Всем удачи и хорошего настроя на весь день!
  • Вопрос задан
  • 405 просмотров
Решения вопроса 1
@FanatPHP
Чебуратор тега PHP
Это просто идеальная иллюстрация к известному высказыванию Дональда Кнута "Преждевременная оптимизация - корень всех зол".

Сначала высасываем из пальца проблему: "тратится время на обращение к бд". Сколько там его тратится, тратится ли вообще, замедляет ли это систему, является ли вообще это проблемой - все эти вопросы нам неинтересны. Мы хотим грудью на амбразуру, стать героем и получить медальку.

После этого начинаем проблему решать.
Значит, чтобы сэкономить время на запросе к базе, которая обычно лежит локально и обычное обращение занимает микросекуны, мы решаем закэшировать данные на клиенте. Который может быть в тысяче километров, а пинг в сотни миллисекунд - не редкость. И вот мы решаем что клиент будет с каждым запросом отправлять массив данных. Причем таких данных, которые на сервере и так. есть. Гениально!

Стоит ли так делать и почему;
не стоит потому что не надо высасывать проблемы из пальца.
Какой будет прирост производительности
Отрицательный
Как Вы решаете подобные вопросы.
МЫ ИХ НЕ РЕШАЕМ.
Мы решаем реальные проблемы, объективно существующие.
А воображаемые проблемы высосанные из пальца решать не следует.
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
ThunderCat
@ThunderCat Куратор тега PHP
{PHP, MySql, HTML, JS, CSS} developer
Ахренеть, то есть если я, допустим, пользователя понизил в правах, то по вашей логике я должен лично к нему домой причапать и почистить куки/сторэйдж. Это гениальное решение, решающее несуществующую проблему! Браво!
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Ни в коем случае.
Храните в серверном кеше для данной сессии или в самой сессии.

Почему? Небезопасно доступы хранить у клиента!
Ответ написан
irishmann
@irishmann
Научись пользоваться дебаггером
1. Не стоит так делать. Потому что все что приходит от клиента, должно проверяться.
2. Как следствие, производительность упадет.
3. Храню сессиях.
Ответ написан
index0h
@index0h
PHP, Golang. https://github.com/index0h
1. Стоит ли так делать и почему;

Нет. Проверка прав должна выполняться на сервере и не зависеть от внешних систем, к которым нет доверия (это я про фронт). Фактически вы контроль доступа хотите передать другой стороне.

2. Какой будет прирост производительности

Прирост то будет, но меньше, чем вы надеетесь. Но не делайте так, еще раз.

3. Как Вы решаете подобные вопросы.

Один раз разобрался с https://symfony.com/doc/current/security.html и пользуюсь.
Ответ написан
Robur
@Robur
Знаю больше чем это необходимо
Если вы раскодируете и что-то проверяете на клиенте - то и кодировать не надо. Это можно использовать только для улучшение UX - например показать пользователю сразу доступные ему пункты в меню.

Если вы раскодируете и проверяете права на сервере, чтобы не лезть в БД, так делать можно, хороший пример - JWT, так же можно много чего попроще придумать.
Можно не значит нужно - выше вам правильно сказали, чтобы оптимизировать запросы к БД надо сначала начать страдать от медленных запросов к БД.
Ответ написан
firedragon
@firedragon
Senior .NET developer
Вот основные причины.
https://habr.com/ru/post/349164/
https://habr.com/ru/post/143259/

В общем храните в сторадже некритичную информацию, даже можете хранить роль в системе, если ваш фронтэнд предполагает разное поведение для разных ролей, но единственное чему можно доверять это идентификатор сессии в паре с ip. Все остальное доставайте на сервере. Если будет проседать, то поставьте redis для кэширования
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы