I found some interesting behavior with the CakePHP Cookie Component in my app today. It all started with a logout bug. My app was essentially allowing users to refresh the page and be re-logged-in if they had opted to "Remember me" (sets cookie). But it was only for that session. Next visit (new session), the bug would not appear - i.e. it "forgot them".
After careful review, and about a dozen echo
lines, I found something that didn't seem so intuitive to me. Even though I had called destroy()
on the cookie for the logout, read()
was still returning a value. In my case, this was resetting the session and re-logging-in the user. This appears to be due to some logic in the read()
method of the Cookie component (~ line 241). So even though I called destroy()
, technically the PHP super-global $_COOKIE
still had a stale version which was then read and returned.
I don't want to go so far as to call this a bug. But to me it is unexpected behavior. If you write a wrapper class (component), and call write(value)
, delete(value)
/destroy()
, and read(value)
, I'd like to think read(value)
does not return anything. This seems intuitive, would you agree?
I imagine not many people see this odd behavior because typically you redirect the user after a logout action. But all the same, I think some additional $_COOKIE
cleanup or logic adjustments should be added to the Cookie component.
Here's my code:
if (isset($this->params['pass'][0]) && $this->params['pass'][0] == 'logout') {
// logout was sent, kill session and any cookies
$this->Session->destroy();
$this->Cookie->destroy();
$message = 'You have been logged out.';
$logout = true;
}
// more beforeFilter code...
if (!$logout && $this->Cookie->read('sessUID')) {
// auto login user from cookie
// NOTE: only do this if $logout due to weak Cookie::destroy()
$this->Session->write('sessUID', $this->Cookie->read('sessUID'));
}