Сообщения об ошибках хранятся в СЕССИИ

Question

Полезно ли хранить сообщения об ошибках в SESSION? Например после перенаправления. Передача через URL не является решением для меня ... Мне интересно, если это хорошее решение ... потому что ..

Может ли конкретная отправка пользователя вызвать проблему? (Долгое время занимает пост, в то время как содержание ajax получается из другой вкладки), что может испортить сеанс! Или это невозможно?

Если пользователь отправляет запрос и по какой-то причине не отображает страницу, сообщение может отображаться на нерелевантной странице!

Так? Любые альтернативы ??
Например, при использовании POST / redirected / get pattern

Answer 1

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

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

Answer 2

Полезно ли хранить сообщения об ошибках в SESSION?Например после перенаправления.

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

Хранение данных такого рода в сеансе - это просто приглашение кусловия гонки.

Answer 3

почему вы не назначаете им конкретный идентификатор, например error_id = 2, и отправляете их через URL? или это также невозможно в вашем случае? Вы также можете отправить идентификатор ошибки через сеанс ...

Answer 4

Сосредоточьтесь на пользователе! Все ваши усилия по разработке направлены на обеспечение максимально возможного UX.

Первый вопрос: зачем вам вообще нужны сообщения?

• В случае успешного запроса вы хотите, чтобы пользователь знал, что его запрос был успешно выполнен.
• В случае ошибочного запроса выможно различить: если запрос может быть изменен пользователем, чтобы превратить его в успешный запрос, то отобразить полезное сообщение об ошибке (например, отправка простой формы).Если запрос не может быть изменен пользователем, будьте максимально информативны , почему запрос не выполнен (например, «Не удалось выполнить, поскольку служба XY недоступна. Обратитесь в службу поддержки и т. Д.»).

Легко: ошибочный запрос, который может быть изменен:

В случае ошибочного запроса, когда пользователь может изменить запрос, не сохраняйте его в сеансеи непосредственно отображать страницу, на которой пользователь может исправить свой запрос.

Сложный: успешный запрос или ошибочный запрос, который нельзя изменить:

Здесь вы, как правило, можете захотетьПользователь не сможет выполнить тот же самый запрос снова после нажатия клавиши F5 или выполнения аналогичных действий, следовательно, вы перенаправляете пользователя.В этом случае я лично предпочитаю решение с компонентом флеш-сообщений (см. Например Symfony Docs или Zend Docs ).В целом, этот метод не приводит к условиям гонки, если ваши приложения удовлетворяют следующим предположениям:

• Ваши HTTP-запросы, запущенные из браузера, выполняются быстро.У пользователя пока нет реальной возможности запустить второй запрос.
• Ваши вызовы AJAX либо не влияют на флэш-сообщения, либо, если вы возвращаете структурированные данные (XML, JSON), вы можете включитьспециальный раздел для флеш-сообщений, которые затем обрабатываются Javascript.

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

• Сохранить временную метку при добавлениифлеш сообщение.Не отображать старые сообщения (например,> 1 минута).Мобильный пользователь может потерять соединение, а затем повторить попытку.В каком состоянии он ожидает, что приложение будет в состоянии?
• Никогда не позволяйте HTTP-запросам между вашим пользователем и вашим сервером занимать много времени.Если вам нужно выполнить длинные вычисления, попробуйте разгрузить вещи в фоновый рабочий и покажите пользователю статус обработки.

Подведение итогов: Если у вас есть общие рекомендации относительноЕсли ваш HTTP-обмен данными установлен, то пользователь вряд ли сможет испортить флеш-сообщения.Взвесьте все «за» и «против» и сфокусируйтесь на пользователе, а не на сложности вашей реализации, так как есть способы, чтобы справиться с этим.

Answer 5

Нередко хранить сообщения об ошибках в сеансе, особенно в тех случаях, когда может быть несколько перенаправлений.В Zend Framework есть что-то вроде флэш-мессенджера, который это делает.

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

Лучший подход - отобразить и удалить.

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

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

Answer 6

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

class MyException extends Exception
{
    const USER_NOT_FOUND = 'The requested user was not found';
    // ...
}

Тогда ваш перенаправленный URL-адрес будет выглядеть как /controller/action/error/USER_NOT_FOUND, и вы будете использовать его для поиска сообщения:

echo constant('MyException::' . $error);

Вам не нужно использовать класс Exception для этого, но он позволяет вам поддерживать порядок

if ($errorState) {
    throw new MyException(
        MyException::USER_NOT_FOUND
    );
}

Answer 7

Вообще говоря:

Постарайтесь разместить как можно больше на стороне клиента (javascript и cookies) и постарайтесь хранить как можно меньше на стороне сервера.

Сюда входит переменная SESSION, которая в лучшем случае должна содержать только идентификатор пользователя.

Если сообщение после перенаправления, вы можете добавить переменную запроса, которая могла бы проиндексировать сообщение и показать его таким образом.