Re: [fw-mvc] FlashMessenger namespace not expiring when user is logged in

Is the problem resolved yet?

Can you send a var_dump of $_SESSION?

Also, when are you calling $this->_helper->FlashMessenger->getMessages()? Is it within the controller or the layout script?

Konr Ness

On Thu, Dec 17, 2009 at 12:24 PM, Adam Jensen <jazzslider@gmail.com> wrote:

Hello!

I'm sort of confused at some behavior I'm seeing with the FlashMessenger (currently running r19709 of the standard trunk, for reference); this is only happening on my production server, which is running the default mod_php setup from Ubuntu Karmic (PHP 5.2.10).

Here's a simple example workflow:

1. When a user logs in, I call $this->_helper->FlashMessenger->addMessage('Login successful!');

2. Immediately after that, I call $this->_helper->Redirector->gotoRouteAndExit(...) to redirect to the site's home page.

3. Meanwhile, on every request, I retrieve whatever happens to be in $this->_helper->FlashMessenger->getMessages() and output it to the user in my layout script.  So in this case, when the redirect completes, the user sees the message "Login successful!".

4. However, if at this point the user clicks another link, the next page _still_ has the "Login successful!" message.  In other words, even though we've now gone through two hops, the message persists.

In fact, that message sticks with the user throughout all subsequent page requests, unless one of the following occurs:

1. A different message is added to the FlashMessenger.  If this happens, the new message replaces the old one, and again persists throughout all subsequent page requests.

2. The user logs out.

Once the user is logged out, everything behaves as expected.  For example, the logout action appends a "Log out successful" message to the FlashMessenger and then redirects to the site's home page, just like the login action does …only in this case, the message appears for one hop and then disappears, just like it's supposed to.

My working theory is that this is a session management problem, especially since the issue only seems to affect logged-in users.  However, I'm not quite sure what settings to tweak to try and fix it …I generally leave session handling alone, leaving the framework's sensible defaults in place.

I'm also not absolutely sure that this has anything to do with the code, whether the framework or my own application …as I mentioned earlier, it's only occurring on my production server, which is currently running a newer version of PHP than my development server (which is on Debian Lenny's 5.2.6).  I do need to remedy that, but it hasn't been an option just yet.  Does anyone know of any differences in session handling between 5.2.6 and 5.2.10 that might be causing something like this?

Thanks!
Adam