OAuth session migration issue on upgrade to 1.6.10

[thomas-pike]

Prerequisites

• I have searched for duplicate or closed issues
• I can recreate the issue with all plugins disabled

Describe the issue

Upgrading to v1.6.10 from v1.6.9 severely hurt our instance's performance. Reverting commit 83f56f1 (as described in #9530) fixed the performance issue. Our setup uses OAuth with a Dovecot IMAP server.

What browser(s) are you seeing the problem on?

Chrome

What version of PHP are you using?

v8.1

What version of Roundcube are you using?

v1.6.10

JavaScript errors

No response

PHP errors

No response

[alecpl]

I don't see how that commit can slow down anything. What exactly is slower? We'll need more details.

[thomas-pike]

I've been trying to figure that out. I'll attempt to get back with more details when I know more. Pretty much every mail operation is slower. Eg. simply loading a different mail from the inbox takes several seconds instead of being near instantaneous. It seemed like perhaps it was suddenly having to authenticate with every request or something along those lines. It's also possible though that one of our plugins is interacting badly with the change.

[thomas-pike]

I haven't been able to reproduce the slowdown on our staging setup, but what I have noticed is that if I am logged in before the upgrade, then after the upgrade I am not able to load any mail at all until I log out and in again (presumably because the new $_SESSION['oauth_token']['auth_type'] parameter is not set in my session). Perhaps the "performance issues" we are seeing are simply from all the currently logged-in users trying to access mails from their existing sessions and triggering an attempt at a password claim login against our authentication servers (we have roughly 16000 active daily users).

[thomas-pike]

I've confirmed that this is the root cause of the issue, and I added a patch to our instance to smooth the migration from 1.6.9 to 1.6.10. I don't think this patch is suitable for being upstreamed, but I include the diff here for the record:

index 1c2244eac..992857701 100644
--- a/program/include/rcmail_oauth.php
+++ b/program/include/rcmail_oauth.php
@@ -521,6 +521,9 @@ class rcmail_oauth
     public function storage_init($options)
     {
         if (isset($_SESSION['oauth_token']) && $options['driver'] === 'imap') {
+            // Vivaldi 1.6.10 transition helper
+            $_SESSION['oauth_token']['auth_type'] = 'XOAUTH2';
+
             // check token validity
             if ($this->check_token_validity($_SESSION['oauth_token'])) {
                 $options['password'] = $this->rcmail->decrypt($_SESSION['password']);
@@ -544,6 +547,9 @@ class rcmail_oauth
     public function smtp_connect($options)
     {
         if (isset($_SESSION['oauth_token'])) {
+            // Vivaldi 1.6.10 transition helper
+            $_SESSION['oauth_token']['auth_type'] = 'XOAUTH2';
+
             // check token validity
             $this->check_token_validity($_SESSION['oauth_token']);
 
@@ -568,6 +574,9 @@ class rcmail_oauth
     public function managesieve_connect($options)
     {
         if (isset($_SESSION['oauth_token'])) {
+            // Vivaldi 1.6.10 transition helper
+            $_SESSION['oauth_token']['auth_type'] = 'XOAUTH2';
+
             // check token validity
             $this->check_token_validity($_SESSION['oauth_token']);

With this patch temporarily in our repository, we were able to upgrade without issue, and we can then remove the patch later.

[thomas-pike]

Another solution may have been to run a migration on the contents of the session table in the database, or even simpler, truncate the table entirely.