On 18.02.2011, at 22:12, Christophe COEVOET wrote: > Le 18/02/2011 22:09, Lukas Kahwe Smith a écrit : >> On 18.02.2011, at 22:04, ryan weaver wrote: >> >>> I have no solution, but the solution so far seems like a bummer. Obviously >>> this only affects dev, but it seems like there should be a better way. >> so we need to identify the "outer" request. now the inner ESI tags are >> defined via the render twig tag which generates the ESI url, which could >> include an additional GET parameter to disable the toolbar. potentially we >> could also use a cookie to pass the profiler "id" of the given subrequest to >> the "outer" page. hopefully we could ensure somehow that the cookie doesnt >> interfere with the reverse proxies work via some sort of filtering. >> >> regards, >> Lukas Kahwe Smith >> [email protected] > And what if the "outer" request is not done to the app because of the cache ? > How would you inject the toolbar in that case ?
well the outer request that is cached would still have the javascript and would read the cookie to update the toolbar. regards, Lukas Kahwe Smith [email protected] -- 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 developers" 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-devs?hl=en
