persistent_login plugin causing session-related issues with new Roundcube 1.5 release

[ashdowntech]

The latest update of MIAB included RoundCube 1.5. Once we updated, we began having trouble with two items:

Issue 1

When selecting a layout in the Larry or the Classic theme, you can choose "List (no mail preview)" as an option in Preferences > Mailbox View > Main Options. If you save this option and then return to the main Mail screen, there will just be list of email with no preview pane as expected.

However, if you simply allow the browser screen to sit idle with no interaction for 5 or 10 minutes, the preview pane will suddenly appear.

Once the preview pane has appeared, you cannot get rid of it by using the small gear dropdown in the header row of the email listing and trying to set it back to list in the pop-up window that appears. Only going to Settings and saving Preferences > Mailbox View, will reset it. However, after several minutes, the preview pane will reappear automatically again.

Issue 2

For those customers who have their Roundcube refresh set to "every 10 minutes" or higher and then don't interact with their browser for a while, an error occurs and appear in the area of the screen where the email listing usually is. It is titled, "File Not Found" and says, "The requested resource was not found! Please contact your system administrator. _Failed request mail.redactedmailservername.com/mail/?_task=mail&action=keep-alive"

This is always accompanied by an error in the logs on the server that say, "PHP Error: Error loading template for in /usr/local/lib/roundcubemail/program/include/rcmail_output_html.php on line 804 (GET /mail/?_task=mail&_action=keep-alive)"

You'll note that there is a blank between "for" and "in" that is where a template name should appear. However, there isn't one.

The workaround is to set the refresh to less than 10 minutes. That works, but this was not an issue in previous RC versions and some people would prefer less frequent auto-refreshing or to manually refresh the page themselves as needed.

Notes

After posing both of these to the Roundcube folks, they indicated they thought it might be a plugin-related issue. I went in and temporarily deactivated all of the defined plugins in config.inc.php. The problems went away. I then reactivated all of the plugins EXCEPT persistent_login. The problems were still gone.

The persistent_login plugin appears to no longer be fully compatible with RC as of 1.5. We can temporarily disable the plugin and increase the session_lifetime from the very short 10 minutes, but that is only a stopgap measure and those changes will be lost when the next update is done.

A remedy that preserves the important log-in persistence feature while not causing these other issues in RC would be most appreciated.

Thank you!

[myfirstnameispaul]

Only because you didn't state it, did you enable only the persistent_login plugin and test?

[ashdowntech]

An excellent point. I've just done that and will report back. Issues usually show in 10 minutes or so.

[ashdowntech]

I can confirm that Issue #2 above occurs if the persistent_login plugin is the only one enabled.

Issue #1 did not happen and may require persistent_login and another plugin to be both be active to show the problem. I will continue to research and report back.

[ashdowntech]

I have confirmed that Issue #1 also appears if persistent_login is the only active plugin.

[downtownallday]

Hi. I was recently examining the persistent login code so decided to take a look at your issues. I agree with you that the problem lies with persistent login. Here's what I found:

With Issue 1 the persistent login plugin is redirecting (internally, server-side) to the action "login" on a POST, which is causing a different redirect to be issued to the client in the response (via server-returned js code) than what you'd get if you let roundcube handle the session lifetime expiration normally. A simple fix is to add the following code to the "startup" function (very top), in plugins/persistent_login/persistent_login.php:

function startup($args)
{
    if ($_SERVER["REQUEST_METHOD"] != "GET") return $args;

    ... [ retain the remainer of the function ] ...
}

This allows roundcube to notify the client that the session is expired (see config setting "session_lifetime"), and have it redirect to the login page as it normally would. Then, the persistent login plugin logs you back in automatically during handling of the client's redirect and returns you back to your Inbox (no login required). You may briefly see a message on the client while the browser is loading the new page that your session has expired, which would not have been shown before.

Some details for Issue 1:

When the session has expired (see config setting "session_lifetime") and a client-side refresh occurs, the client is instructed to log back in. This is the response behavior on a POST when the session has expired and with the persistent login plugin's source code unmodified:

 on server:
    persistent login plugin:
        redirect to action 'login'
        handle 'authenticate': login user using existing _pt cookie
        handle 'login_after': set new _pt cookie
    roundcube:
        set new session cookies
        redirect client to "/mail/?_task=mail&_action=refresh"
  on client:
    set window.location to "/mail/?_task=mail&_action=refresh"
  final browser url:
    /mail/?_task=mail&_mbox=INBOX&_action=refresh

The new behavior when the above fix has been applied:

   on server:
      roundcube:
           redirect client to "/mail/?_task=login&_err=session"
   on client:
        1. Display session expired message to end user
        2. set window.location to "/mail/?_task=login&_err=session"
   on server:
      persistent login plugin:
           handle 'authenticate': login user using existing _pt cookie
           handle 'login_after': set new _pt cookie
      roundcube:
           set new session cookies
           redirect client to "/mail/?_task=mail&_mbox=INBOX"
   final browser url:
      /mail/?_task=mail&_mbox=INBOX

You can recreate Issue 1 (preview pane shown) just by pasting "/mail/?_task=mail&_mbox=INBOX&_action=refresh" into your browser's location bar.

For Issue 2, the persistent login plugin is attaching the "keep-alive" action to the "mail" task, which is not a valid location. Thus the "not found" error. The fix for this is to modify persistent login's "login_after" function to ignore restoring the original action in this case.

Change this line in the original "login_after" function:

    if (isset($this->original_action)) {

to:

    if (isset($this->original_action) && $this->original_action != 'keep-alive') {

[ashdowntech]

I will absolutely try out those changes to see their impact on the stated problems. My question is whether these same changes will be rolled into the next update of MIAB? Otherwise the changes will be lost and will have to be applied after every update. Thanks!

[JoshData]

The best way to get this fixed is to work with the maintainer of the plugin at https://github.com/mfreiholz/persistent_login. If it's not fixed there, I'll probably have to remove the plugin from Mail-in-a-Box.

[ashdowntech]

I've just put an issue in with the persistent_login folks. The package hasn't had any activity in a couple of years, but I'm hopeful they are still paying attention to it.

If the plugin has to be removed due to incompatibility, I certainly understand that. However, this is functionality that every web-based login system has for people who use webmail as their everyday email client. To lose that would be a big step backwards. Some replacement for this functionality, even the ability to set the Roundcube session timeout from the MIAB admin panel, would be most helpful in reducing the impact.

Many thanks for your excellent mail server package!

[JoshData]

Of course I agree with you that it's important functionality, but I don't want to be in the business of maintaining a webmail application. :)

Either the original plugin, another plugin, or the Roundcube project itself has to take responsibility for the feature for us to include it without it becoming a new burden on this project.

[ashdowntech]

I totally understand the conundrum here. Let's hope the persistent login folks are responsive to the issue. I seriously doubt that RC is going to address this as core if they haven't already done so by now. I'm sure they would just say, "turn up the session lifetime", which is fine, but the nature of MIAB means that a change like that would be lost with the next update. Catch-22.

[jvolkenant]

Might be fixed downstream downtownallday/persistent_login@e06b460 upstream now mfreiholz/persistent_login@59ca1b0

[ashdowntech]

Looks like this is a perfect solution. @downtownallday commented up this thread with this solution and has implemented it in the referenced downstream pull.

[ashdowntech]

@mfreiholz has rolled the @downtownallday fixes into the master, so including the latest release of persistent_login in the next update of MIAB should resolve these issue with RC 1.5

[jvolkenant]

Thanks @ashdowntech @downtownallday @mfreiholz

[JoshData]

Good work, all. Someone could open a PR that updates the commit hash that we pull, and add a line to CHANGELOG.md.