Error messages stored in SESSION

Question

Is it a good practice 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

score 7 · Accepted Answer · answered Nov 29 '10 at 10:55

7

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.

answered Nov 29 '10 at 10:55

KingCrunch

128,817
21
151
173

1

I dont know exactly, if I really understand your question. When an error occurs, just output it. Only redirect, when no error occurs (and if necessary, e.g. "Redirect-After-Post" to avoid sending a form multiple times). `if ($error) { echo $error; } else { /* do something */ redirect($target); }` – KingCrunch Nov 29 '10 at 11:05
You could do the success message with jquery, and redirect with jquery after x-seconds – Jeroen Bellemans May 22 '15 at 15:29

score 5 · Answer 2 · answered Nov 29 '10 at 10:53

5

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.

answered Nov 29 '10 at 10:53

Quentin

914,110
126
1,211
1,335

Don't redirect if there is an error. The results don't need to be bookmarked, the user doesn't need to go back to the error page. Just display the error. – Quentin Nov 29 '10 at 11:08
1

thats good approach but in case of custom success message? or in case that the page has a part for login then submiting the login information to the page may cause trouble with other forms – GorillaApe Nov 29 '10 at 11:20

score 3 · Answer 3 · answered May 21 '15 at 22:15

3

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...

answered May 21 '15 at 22:15

Florin Andrei

287
2
11

This is a case *only* if there are defined errors count with constant message – msangel May 22 '15 at 19:44
of course, i thought this would be self understanding... thanx for pointing out – Florin Andrei May 23 '15 at 03:12

score 2 · Answer 4 · answered May 21 '15 at 02:19

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.

`I believe you should not run into any problem ever if you use this approach. ` - concurrent requests are problem — msangel, May 22 '15 at 19:48
Ideally, if I am using a browser to submit a form there would be some delay between clicks, might be micro-seconds. Also the last request should ideally supersede others if it is from the same user, if that's the case. Also multiple clicks can be easily stopped using javascript/jquery. Also sessions shouldn't have problem if concurrent requests are coming from different machines.I might be missing something here but can you explain how a concurrent request would actually happen from the same user, like set of events which would lead to problems. — Kamal Soni, May 26 '15 at 01:15

score 1 · Answer 5 · answered May 21 '15 at 06:05

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.

score 0 · Answer 6 · answered May 21 '15 at 14:04

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.

score -1 · Answer 7 · answered May 22 '15 at 12:19

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
    );
}

Error messages stored in SESSION

7 Answers7

Linked