Error messages stored in SESSION

Is it a good pract开发者_开发问答ice to store error messages in SESSION? For example after a redirect. Passing in through url isnt a solution for me... I am wondering if it is a good solution... because..

Would a concurent submit of user cause problem? (A long time-taking post, while ajax content is obtained from another tab) that may mess up the session! Or that is impossible to happen?

If user makes a request and it fails for some reason to display the page then the message may be shown at an irrelevant page!

So? Any alternatives??

For example when using POST/redirected/get pattern

When storing error messages in the session, you must take care, that two request dont overwrite the other ones message, before it is displayed. And you must take care, that a page, that should display a message, only displays its own message.

You should show errors, when they occur and not redirect before. Also there is no reason to redirect in such a situation.

Is it a good practice to store error messages in SESSION? For example after a redirect.

Not in general. Session data should be data that matters for a significant period, errors are generally a result of a single request and the details don't need to persist.

Storing that sort of data in a session is just an invitation to race conditions.

why dont you assign them an specific id like error_id=2 and send them through url? or is this also not possible in you case? you could also send an error id through session...

It is not uncommon to store error messages in session, especially in cases where there can be multiple redirects. Zend framework has something like flash messenger which kind of does that.

Anything that is in session would stay in session until you destroy it or session times out. The best practice is store the error messages in session, then when the page is loaded where the error message needs to be displayed, your code would get the messages from the session and display them if they exist. After the error messages are displayed you would need to delete them from the session, otherwise each time the user goes to this page they would see the same error messages popping up again and again.

The best approach is to display and delete.

I believe you should not run into any problem ever if you use this approach. The reason is that if an incorrect form is submitted it would always have errors in it and it will always try to store those error messages in session and display them accordingly does not matter how many times they have added/deleted in session. I hope this all makes sense.

Also when you store session error messages you need to store them smartly so that the backend knows that these error messages are stored for which form.

Focus on the user! All your development efforts want to provide the best UX possible.

The first question is, why do you need messages at all?

• In case of a successful request, you want the user to know that his request was successfully executed.
• In case of an erroneous request, you can distinguish: if the request may be altered by the user to turn into a successful request, then show a helpful error message (e.g. a simple form submission). If the request may not be altered by the user, be as informative as possible why the request failed (e.g. "Couldn't execute as service XY is not available. Please contact support etc.").

Easy: Erroneous request that may be altered:

In case of an erroneous request where the user may alter the request, don't save it in the session and directly render the page where the user may correct his request.

Difficult: Successful request or erroneous request that may not be altered:

Here you may generally want the user to not be able to execute the exact same request again after hitting F5 or taking similar actions, hence you redirect the user. In this case I personally favor the solution with a flash messages component (see Symfony Docs or Zend Docs for an example). In general, this technique does not lead to race conditions if your applications meets these assumptions:

• Your HTTP requests fired from the browser are executed fast. A user does not have a real chance of firing a second request in the meantime.
• Your AJAX calls either do not influence the flash messages - or, if you return structured data (XML, JSON) you may include a special section for flash messages, that are then being rendered by Javascript.

Now, to minimize error rates you can do the following:

• Store the timestamp when you added the flash message. Don't display old messages (e.g. > 1 minute). A mobile user may loose connection and then retry. What state does he expect the application to be in?
• Don't ever let the HTTP requests between your user and your server take long. If you need to perform long computations, try offloading things to a background worker and show the status of processing to the user.

Summing up: If you have general good practices concerning your HTTP communication in place, then the user is unlikely able to mess up flash messages. Weigh the pros and cons and focus on the user, not the complexity of your implementation, as there are methods to cope with that.

Generally speaking:

Try to put as much on the client-side (javascript and cookies) and try to store as less as possible on the server-side.

This includes the SESSION variable, which in the best scenario should contain only user id.

If the message is after redirect, you could add a request variable that could index the message and to show it that way.

Instead of storing in a session, you could pass an error code in the URL that you would then use to look up the error. I've user bare-bones exception classes for this kinda thing:

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

Then your redirected url would be something like /controller/action/error/USER_NOT_FOUND and you'd use that to look up the message:

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

You don't need to use an Exception class for this, but it allows you to keep things really tidy

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