4

I need to write a handler for server error during user logout. What is a common practice?

ajax.post({
    url: '/auth/logout'
}).done(function (response) {
    switch (response.statusCode) {
        case 200:
        {
            //update UI related to userinformation
        }
        case 500:
        {
            //what should I do here?
        }
    }
})

Note: The ajax function is reimplementation of $.ajax() with the exception that it always calls done callback (custom promise object is always resolved and never rejected)

UPDATE: On server I destroy session and delete auto login cookie if it's present. Is it a sensible approach (if server error is received) to delete cookies related to session name and auto login on client using javascript (presuming that I know their names)?

2
  • I think this is off topic cause is about jquery. (Take care about your switch. What if status 304)?
    – kedoska
    Mar 19 '14 at 19:46
  • 3
    it's not about jQuery. jQuery is just a tool here, I'm interested in the approach itself with any language Mar 19 '14 at 19:47
2

Fundamentally you should do the same thing you did for sucess -- let the user know about it.

Note that this is specific to the front end, because the front end session continues. The back end should return sucess, even if it doesn't have a valid session to close out. Only if it truly is, for some strange reason, going to maintain the session, should it return failure. In which case it is vital that your front end let the user know about it.

5
  • What if during destruction of autologin cookie in database the connection is lost? Mar 20 '14 at 11:51
  • If you can't verify closure, return failure -- better that the user try something and be told they've been logged out, particularly since logging out is what they just attemted to do, than someone else try something and succeed.
    – jmoreno
    Mar 20 '14 at 14:46
  • Thanks, I think I can destroy cookies related to logging on server (setting cookies on server shouldn't fail) while session on server will still be active for some 20 minutes and autologin cookie will remain in database (I'll think of some way to destroy it later). What do you think about that approach? Mar 20 '14 at 18:40
  • 1
    Generally the important part is how it affects the user, so if a cookie remains in the database, but unusable, after they logout, that's not a problem. If they logout and only have to hit refresh to be logged back in, that's a problem.
    – jmoreno
    Mar 21 '14 at 2:28
  • Thnaks, I think I'll procceed with this approach then Mar 21 '14 at 6:09
2

When an error occurs in a web application, this is what happens:

  1. Error
  2. Try/Catch (or any other comparison mechanism)
  3. window.error
  4. Browser error

Your application should consider 2 kind of errors (minimum):

  1. FATAL Error
  2. NON-FATAL Error

A fatal error is an error that does not allow the execution of the application, and does not consider the possibility that the client retry to execute the action. Probably, the user is informed that an error has occurred, and all the information already present in the client are destroyed to force a creation of the data structure needed from scratch.

A NON-fatal error must allow the user to understand that something has happened and, in the case log-in case, he/she/it must rerun the action.

Then, as described:

A 500 ​​from the server can not be considered a fatal error in a web app for the Log-in action. It should be treated as an action like the others, probably NON-fatal.

A good practice to understand what errors to consider, and what is their degree of severity, is to create a table that describes actions, and consider columns with the different options of possible errors:

a. invalid url;

b. server response error;

c. response content error;

d. physical connection/network errors;

2

This is related to the age-old question, "How do I handle the error if I try to delete a resource that isn't found?" Practically speaking, the job is done. Usually, I'll just move on, at most logging a WARN if it matters.

The risk here comes from a login session being a security artifact. So if the logout failed, you may have a lingering session that would be vulnerable to attack.

Most of the time, that may not matter. Generally, once you drop the reference to the session token (or whatever security artifact you're using), then it can't be recovered anyway.

Depending on what user experience you want, you could just fail silently, or else let the user know that logout failed, and let them try again.

But if you were writing a website for a bank, it's more of a problem. Implement some sort of retry mechanism. Maybe run it in the background, to retry until you get a positive result.

1
  • Usually, I'll just move on, at most logging a WARN if it matters. - so I should change UI elements to represent unloggedin statel, correct? Please also see my updated question Mar 20 '14 at 11:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.