I completely missed that redirect when I first read your post. Yes, I do remember having that problem as well with Ajax, but not in Chrome; it was in Opera. At the time (and I am assuming that Opera still works the same way), the Ajax request was unable to follow a redirect, and any request for a redirect would simply be ignored. IE and FF worked fine with following 302s but not Opera. I don't remember if Chrome was the same, but we had to work out a solution for Opera, and probably by the time we started working with Chrome, the Opera solution was already in place.
You can still keep your logic in an action instead of the filter, and just instantiate it from within your filter.... Eric "Gareth McCumskey" <gmccums...@gmail.com> wrote in message news:AANLkTi=AyM5Ust_-cf=mxwjeVXH0e=7gccbzrk+en...@mail.gmail.com... 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. <ebe...@hotmail.com> 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" <gmccums...@gmail.com> wrote in message news:AANLkTimTg8ZtSwHjN6x2xeW=xsmpRx=cctmnwzhzy...@mail.gmail.com... 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. <ebenze-pkbjnfxxiarbdgjk7y7...@public.gmane.org> 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" <gmccums...@gmail.com> wrote in message news:aanlktim3dwnxbjq-ftg4uo8of6cjd9uptuhyv8073...@mail.gmail.com... 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscribe-/jypxa39uh5tlh3mboc...@public.gmane.org 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
