Методы управления переменными сеанса

Question

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

---

Прецедент для этого связан с системой управления пользователями: Возьмет, например, admin пользователя обновление regular пользователя к manager, этому пользователю type изменения затем enable|disable функции программного обеспечения на интерфейсе.

Проблема: Вы не будете знать об этом пользователе type изменения, если вы не запрос к базе данных и сброс скажем, например, переменную $_SESSION['user']['type'], и или пользователь входит в | из системы.

---

Вопрос: Есть ли какие-нибудь хорошие методологии для решения этой головной боли?

Answer 1

Я не думаю, что mysql triggers would be ideal for this. Зачем? Потому что вы, скорее всего, столкнетесь с частью логики в php и part в mysql. Это хорошая вещь, чтобы остаться с одной технологией, потому что будет легче поддерживать/отлаживать код для вас и ваших коллег позже.

Итак, если вы хотите, чтобы изменение роли пользователя принимало немедленное действие, вам придется либо загружать роль пользователя в каждом запуске сценария, либо выходить из системы, используя некоторый флаг в базе данных, который сигнализирует, что его сеанс недействителен (или вы можете реализовать свой собственный session_set_save_handler, который сохранит сеанс где-нибудь в файле, где вы можете удалить его, чтобы выйти из системы).

Это зависит от ваших потребностей, решение которых лучше всего подходит вашему делу.

• Если ваши роли логики сложна и он состоит из нескольких ролей, назначенных одному пользователя, а также дополнительных разрешения заданий/исключает для каждого пользователя может быть лучше, чтобы сделать эту проверку один раз на входе пользователя в системе и то просто запомните результат, используя сеанс.
• Если проверка разрешений на каждом запуске сценария не является проблемой, вы можете сделать это . Но имейте в виду, что по соображениям безопасности может быть хорошей практикой заставить пользователя войти в систему снова.
• Если пользователь журнал из может вызвать потерять работы, вы должны позволить пользователю выйти себя и применить новые разрешения после первого входа в систему (можно показать пользователю сообщение, что новые разрешения ожидающее Авторизироваться вступают в силу).

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

Answer 2

Если ваши скрипты используют $_SESSION['user']['type'], чтобы узнать о привилегиях пользователя, я бы просто изменил его значение. Или, может быть, я не понял эту проблему?

Answer 3

Я думаю, что самый безопасный способ сделать это, и тот, который я бы выбрал, является способом «головной боли».

1. «Обычный» пользователь Входит в систему и открывает сеанс A1.
2. Пользователь «admin» обновляет A до «менеджера».
3. На данный момент сеанс A1 является действительным сеансом, но он не предоставляет привилегии пользователя «менеджер».
4. Когда пользователь A выйдет из системы и войдет в сеанс A2, этот сеанс предоставит пользователю все привилегии «менеджера», просмотрев текущий «тип» из базы данных.

---

Альтернатива, которая может быть немного дороже в зависимости от вашего приложения:

Каждый раз, когда пользователь представляет маркер сеанса, использовать базу данных для проверки против действительности сессии. Если этот сеанс имеет неверную информацию (т. Е. «Тип» больше не совпадает), заставьте пользователя снова войти в систему.

---

Добавление другой альтернативы:

Не использовать триггер MYSQL, когда приложение вызывающего абонента (админ) обновляет «тип», пользователь А, это также делает вызов, где вы кэшировать сессий и либо (а) обновляет сеанс (не рекомендуется), либо (б) делает сеанс недействительным и заставляет пользователя снова входить в систему.

---

* Обратите внимание, что все эти решения требуют, чтобы пользователь повторно ввести свои учетные данные после того, как они вновь обретенной «менеджер» власть, прежде чем они имеют доступ к "менеджеру материала. Я считаю, что это более безопасная практика, чем обновление сеанса без какой-либо проверки подлинности.

Answer 4

Один из альтернатив - делать запросы ajax с некоторым интервалом времени, который будет обновлять пользователя $ _SESSION. Если у вас есть какие-либо изменения в вашем 'type', вы можете делать все, что хотите, например, заставить пользователя повторно войти в ваше приложение или ничего не делать, кроме обновления информации $ _SESSION. Конечно, вам нужно знать, действительно ли вам нужно получить эту информацию до выхода пользователя из системы и входа в следующий раз с обновленным профилем.

Answer 5

Моя Рекомендуемая методология будет хранить type в каждый пользователь в базе данных. Проблемы, которые возникли бы, если вы решили сохранить type как переменная сессии будет (среди прочих):

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

2. Вам не удастся использовать мощные и продвинутые запросы, предлагаемые базами данных (например, MySQL, который использует SQL). Если вы храните свою информацию в сеансах, вы можете найти способ поиска информации о пользователях 1 на 1, но зачем изобретать колесо? Нелегко создать структуру базы данных с нуля, поэтому я бы не рекомендовал ее делать.

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

1)

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

2)

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

Для простого простого использования SELECT * FROM myTable WHERE id = 4 может потребоваться всего 1 миллисекунда, который будет выполнен в базе данных. Базы данных были специально разработаны для их скорости, поэтому они предпочли

HOWEVER, возможно, у вас нет доступа к базе данных, и именно поэтому вы ищете альтернативу? Ну, тебе повезло! MySQLi - это база данных, в которой используется только файл для хранения информации. Он был специально разработан для пользователей, которые не имеют большого количества ресурсов, и обладает многими возможностями, как MySQL.

Answer 6

Поскольку каждый пользователь имеет role или type, это означает, что возможность просмотра или редактирования контента в приложении надежно подключена к этому коэффициенту. Это означает, что 2 основных вещи, которые ваши переменные сессии должны иметь в userID и userType, которые вы также должны хранить в базе данных

Этих частей информации могут быть переданы в $_SESSION['user'], например, в качестве небольшого массива, в котором ключ массива может быть userID и значение userType.

$_SESSION['user']=array($userID => $userType); 

После того, как пользователь для входа в начальные значения сохраняются в session. Для того чтобы ваша заявка знала, что userA может просматривать или редактировать в вашем приложении, вы в основном выполняете сравнение в своем скрипте с userType, которое имеет userA. Но для достижения того, что вы хотите, вам в основном нужно повторно получить часть информации в начале каждого VIEW/PAGE вашего приложения.Если новое userType было отправлено на номер userA, просто сообщите, что он автоматически выйдет из системы через 15 секунд (предоставит время для чтения самого сообщения), чтобы изменения вступили в силу. Пока ваш пользователь видит это сообщение, вы берете текущие данные сеанса, которые он/она может иметь, и сохраняют его в базе данных, так как некоторые переменные сеанса могут быть (или нет) доступны при обновлении или понижении userType. Помещая сравнение userType в начале каждого VIEW/PAGE вашего приложения, вы сохраняете головную боль, которую пользователь может потерять.

Answer 7

Вопрос: Есть ли хорошие методологии для решения этой головной боли?

Находят веские причины, чтобы этого не делалось!

Хотя это может звучать как шутка, я абсолютно серьезно. Вы должны учитывать:

• Какова ценность этой функции?
• Стоит ли головная боль стоит?
• Каковы риски этой функции (неполная согласованность работы/системы)?
• Вам нужно изменить системное ядро?
• Вам нужно будет проверить систему?
• Есть ли еще действительно замечательные функции (усовершенствования системы), ожидающие исполнения?

Кому-то, кому неудобно отвечать на эти вопросы, на самом деле не нужна эта функция.

Найти простые альтернативы:

• Вызвать пользователя и попросить, чтобы выйти.
• Сообщите пользователю о вашем письме.
• Предоставьте кнопку для уведомления по электронной почте.
• Отправить уведомление по электронной почте автоматически после изменения разрешений.

Это не лень. Просто сосредоточьтесь на реальной ценности.