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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

Наилучший подход - отображать и удалять.

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

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

Ответ 5

Сосредоточьтесь на пользователе! Все ваши усилия в области развития хотят обеспечить лучший UX.

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

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

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

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

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

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

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

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

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

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

Ответ 6

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

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

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

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

Ответ 7

Вместо хранения в сеансе вы можете передать код ошибки в 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
    );
}