Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)?

share|improve this question
    
I think this is off topic cause is about jquery. (Take care about your switch. What if status 304)? –  marcocs Mar 19 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 –  Maximus Mar 19 at 19:47

3 Answers 3

up vote 1 down vote accepted

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.

share|improve this answer
    
What if during destruction of autologin cookie in database the connection is lost? –  Maximus Mar 20 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 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? –  Maximus Mar 20 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 at 2:28
    
Thnaks, I think I'll procceed with this approach then –  Maximus Mar 21 at 6:09

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;

share|improve this answer

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.

share|improve this answer
    
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 –  Maximus Mar 20 at 11:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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