Well, the basic issue was that Chrome and FF processed the ajax requests slightly differently. To reiterate how we were processing these requests...
1. Session is timed out for a user. 2. User accesses a function that employs AJAX. 3. The filter we have in place will analyse the request and determine that the user is unauthenticated AND that the current request is an XML HTTP Request. 4. It then redirects the request to an action 5. This action then sets header Content Type to application/json and responds using a renderText with a JSON string. 6. Our global jQuery ajaxSetup catches the response in the success callback parameter. 7. The success callback determines that yes, this is a JSON string and contains information telling us that the session timed out on this AJAX request and so does a window.location to redirect the entire browser to the login page. Firefox works fine with this. However, with Chrome, it seems that at step 4, the filters redirect to an action, it sees that redirect as some kind of response to the original ajax request, sends nothing back to the original AJAX request, and then processes the redirect to 5. All we did to fix it was remove the need to redirect to an action and the filter immediately responds with json string instead. So instead of delegating the work of responding with an ajax string to another action, the filter does it itself. On Tue, Jan 25, 2011 at 6:10 PM, Eric B. <[email protected]> wrote: > Now I'm curious; what was the bug/ what was the fix? > > Just b/c it was working in FF, doesn't mean that Chrome is sending the same > headers/info that your server is expecting. So although it might be the > client side (ie: the browser), it comes through as a server issue as your > action/filter/interceptor/etc is not acting as you would expect it to. But > like I said, these were a lot of problems I had encountered in the first > releases of Chrome; so much that we had decided at the time to not support > it until Google fixed its issues. Today's version is much better... > > Thanks, > > Eric > > > "Gareth McCumskey" <[email protected]> wrote in message > news:[email protected]... > It works on Firefox therefore it is not server side. > > Regardless we fixed the problem. > > On Mon, Jan 24, 2011 at 5:33 PM, Eric B. < > [email protected] <[email protected]>>wrote: > >> I remember back in the early days of Chrome I used to have problems with >> JS and Ajax as well. But the newer versions seemed to have resolve the >> problems that I was encountering. >> >> Have you checked if the problem is Chrome to executing the JS properly, or >> if it is a server side issue in which the filter is not properly executed? >> Are the Chrome AJAX request properly setting the XML HTTP header? (in >> theory, given that it is JQ, it should all be standard, but you never >> know....). >> >> I assume you have a separate mechanism for session timeouts; are the >> requests from Chrome properly handled? >> >> Off the top of my head, my first instinct would be to indicate that Chrome >> JS isn't doing it's job properly, but there may also be a case where you >> might be getting double ajax submissions/requests and your session >> monitoring may not properly be handling the double requests (I also had a >> problem with double requests in the early days of Chrome). >> >> Have you been able to isolate where the exact problem is occurring? >> >> Tx, >> >> Eric >> >> >> "Gareth McCumskey" <[email protected]> wrote in message >> news:aanlktim3dwnxbjq-ftg4uo8of6cjd9uptuhyv8073coc-jsoawuisxosn+bqq9rb...@public.gmane.org >> ... >> Hi all, >> >> I have interesting problem. Something we have all encountered before ... >> browser inconsistencies. This is related to handling session timeouts on an >> ajax request. I'll just layout our current setup. >> >> We have a symfony filter that detects whether the current request is an >> XML HTTP Request and if the current user session has timed out. The code for >> this is: >> >> if ($user->isAuthenticated() == false && $request->isXmlHttpRequest()) >> { >> return $context->getController()->redirect('users/ajaxTimeout'); >> exit; >> } >> >> As you can see if the IF conditions are met it redirects to another action >> whose code is: >> >> sfContext::getInstance()->getResponse()->setHttpHeader("Content-Type", >> "application/json"); >> return $this->renderText(json_encode(array("error"=>"session", >> "url"=>"users/login"))); >> >> We also have our jQuery .ajaxSetup as follows on the success callback: >> >> success : function(response, textStatus, xmlobject) { >> try { >> var json_res = jQuery.parseJSON(response); >> if (json_res.error == "session") >> { >> window.location.href = json_res.url; >> } >> } >> catch (e) >> { >> >> } >> >> The workflow is that as soon as an ajax request is made, the filter >> catches the request, and detects the request is AJAX and session has timed >> out so redirects the request to the action code above. The action responds >> with a JSON string which the global .ajaxSetup success callback catches and >> sees that there is a session error and redirects the entire page to the >> login screen. >> >> It works well in Firefox and IE however in Chrome it doesn't. I was >> wondering if anyone here might have some insight into what might be causing >> the problem. >> >> -- >> Gareth McCumskey >> http://garethmccumskey.blogspot.com >> twitter: @garethmcc >> identi.ca: @garethmcc >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony users" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> symfony-users+unsubscribe-/[email protected]<symfony-users%2Bunsubscribe-/[email protected]> >> >> For more options, visit this group at >> http://groups.google.com/group/symfony-users?hl=en >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony users" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> symfony-users+unsubscribe-/[email protected]<symfony-users%2Bunsubscribe-/[email protected]> >> >> For more options, visit this group at >> http://groups.google.com/group/symfony-users?hl=en >> > > > > -- > Gareth McCumskey > http://garethmccumskey.blogspot.com > twitter: @garethmcc > identi.ca: @garethmcc > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-users%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-users%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- Gareth McCumskey http://garethmccumskey.blogspot.com twitter: @garethmcc identi.ca: @garethmcc -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
