![]() |
"set_flashdata" PREVENTS hook from being able to "get_output" - Printable Version +- CodeIgniter Forums (https://forum.codeigniter.com) +-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20) +--- Forum: Archived Development & Programming (https://forum.codeigniter.com/forumdisplay.php?fid=23) +--- Thread: "set_flashdata" PREVENTS hook from being able to "get_output" (/showthread.php?tid=30802) |
"set_flashdata" PREVENTS hook from being able to "get_output" - El Forum - 05-26-2010 [eluser]Unknown[/eluser] I have a set of hooks designed to counter XSRF hacks. 1: A Post-Controller-Construct Hook that examines incoming requests for a valid token 2: A Display-Override Hook that appends tokens to outgoing responses. This system works perfectly except for one case: When flashdata is used. If the application controller uses "set_flashdata" then the Display-Override Hook receives a NULL-STRING from the "get_output" method. It therefore cannot append a token. Yet, somehow the original output is sent to the browser, apparently bypassing the Display-Override Hook completely! CodeIgnitor acts as if Session is retaining the output until AFTER Display-Override in order to insert the flashdata, and then releasing the output directly to the client. This is in apparent contradiction to the supposed function of the Display-Override Hook as descibed in the user manual. According to the manual, the final output should be available to the hook at this point "by calling $this->CI->output->get_output()" (quotation from the user guide). In fact, the final output is NOT available to the hook in cases where "set_flashdata" has been invoked inside the application controller. When poking around in the Session.php core, I notice that if I deactivate the function "flashdata_mark" then the output is once again available, and the hook works... however the flashdata is never displayed or cleared of course... What is going on here? James POST NOTE: We got to the bottom of this. Someone on our team had extended the Session class, and had forgotten to flush a buffer. When we removed the offending line.. this bad behaviour dissapeared and now everything works as expected. |