Oauth2 redirect issues: roundcube login page and not loading js or css (nosniff)

[netchild]

Hi,

I have roundcube oauth configured to authenticate against keycloak. The button appears on the login screen, I can login with keycloak, but then it redirects back to roundcube and roundcube shows the login page without any js or css applied. Tracing it with webdeveloper tools makes the issue obvious why there is no js or css: on redirect it tries to load the js and css from the wrong path; /index.php/login/skins/elastic/deps/bootstrap.min.css?s=1688210993 instead of /skins/elastic/deps/bootstrap.min.css?s=1688210993

The log shows that whatever the browser returns is rejected as the mime type doesn't match due to the X-Content-Type-Options setting of nosniff. This is off course expected, even if the index.php would return valid js or css code.

How can I get this to work (without losing the nosniff setting)?

The full webdeveloper tools console log:
Storage access automatically granted for First-Party isolation "https://keycloak.domain.tld" on "https://roundcube.domain.tld".
The resource from "https://roundcube.domain.tld/index.php/login/skins/elastic/deps/bootstrap.min.css?s=1688210993" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
The resource from "https://roundcube.domain.tld/index.php/login/skins/elastic/styles/styles.min.css?s=1688210976" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
The resource from "https://roundcube.domain.tld/index.php/login/plugins/libkolab/skins/elastic/libkolab.min.css?s=1693517410" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
The resource from "https://roundcube.domain.tld/index.php/login/plugins/tls_icon/tls_icon.css?s=1678132961" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
The resource from "https://roundcube.domain.tld/index.php/login/plugins/jqueryui/themes/elastic/jquery-ui.min.css?s=1688210976" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
The resource from "https://roundcube.domain.tld/index.php/login/program/js/jquery.min.js?s=1688210980" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
Loading failed for the <script> with source "https://roundcube.domain.tld/index.php/login/program/js/jquery.min.js?s=1688210980".
The resource from "https://roundcube.domain.tld/index.php/login/program/js/common.min.js?s=1688210976" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
Loading failed for the <script> with source "https://roundcube.domain.tld/index.php/login/program/js/common.min.js?s=1688210976".
The resource from "https://roundcube.domain.tld/index.php/login/program/js/app.min.js?s=1688210976" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
Loading failed for the <script> with source "https://roundcube.domain.tld/index.php/login/program/js/app.min.js?s=1688210976".
The resource from "https://roundcube.domain.tld/index.php/login/program/js/jstz.min.js?s=1688210980" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
Loading failed for the <script> with source "https://roundcube.domain.tld/index.php/login/program/js/jstz.min.js?s=1688210980". oauth:25:535
Uncaught ReferenceError: rcube_webmail is not defined
    <anonymous> https://roundcube.domain.tld/index.php/login/oauth?state=h3DuZfPs5LP5&session_state=bc11bc83-d99d-4acf-8ad9-2f63b96cb09c&code=1db87f15-ea02-45f4-b90b-fc4c95665d20.bc11bc83-d99d-4acf-8ad9-2f63b96cb09c.8c63d35c-d892-4e4a-a02c-21c7506b6176:44
The resource from "https://roundcube.domain.tld/index.php/login/plugins/jqueryui/js/jquery-ui.min.js?s=1688210976" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
Loading failed for the <script> with source "https://roundcube.domain.tld/index.php/login/plugins/jqueryui/js/jquery-ui.min.js?s=1688210976".
The resource from "https://roundcube.domain.tld/index.php/login/plugins/libcalendaring/libcalendaring.js?s=1642162726" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
The resource from "https://roundcube.domain.tld/index.php/login/plugins/jqueryui/js/i18n/datepicker-de.js?s=1688210976" was blocked due to MIME type ("text/html") mismatch (X-Content-Type-Options: nosniff).
Loading failed for the <script> with source "https://roundcube.domain.tld/index.php/login/plugins/jqueryui/js/i18n/datepicker-de.js?s=1688210976".

Bye,
Alexander.

[netchild]

Hi,

I debugged this a bit. There seems to be some kind of bad interaction of nginx and php-fpm involved here.

There is an issue that nginx doesn't seems to do the right thing when using fastcgi_split_path_info with try_files. See https://trac.nginx.org/nginx/ticket/321 for more info about that part.

The part specific to roundcube and oauth2 redirects seems to be, that the setting "fastcgi_param  PATH_TRANSLATED $document_root$fastgi_path_info" is not doing what it shall do. Due to the interaction between try_files and fastcgi_split_path_info, the $fastcgi_path_info is empty. The solution for $fastcgi_path_info in the trac ticket above is to save the content into your own variable and use that. If I do this with PATH_TRANSLATED, I get access denied even for the login page. If I remove the PATH_TRANSLATED, all works, but not the OAauth2 login due to the previously mentioned wrong path.

My relevant nginx config is:

location ~ ^.+\.php(/|$) {
                        # first split, then do try_Files later
                        # see https://trac.nginx.org/nginx/ticket/321
                        fastcgi_split_path_info ^((?U).+\.php)(/.+)$;
                        set $orig_path $fastcgi_path_info;
                        fastcgi_keep_conn       on;
                        fastcgi_index           index.php;

                        # first set var, then do try_Files later
                        # see https://trac.nginx.org/nginx/ticket/321
                        set $orig_path $fastcgi_path_info;
                        # Zero-day exploit defense.
                        # http://forum.nginx.org/read.php?2,88845,page=3
                        try_files $uri $uri/ $fastcgi_script_name index.php =404;

                        include                 fastcgi_params;
                        fastcgi_param           PATH_INFO $orig_path;
                        fastcgi_pass            unix:/var/run/php-webmail2.fcgi;

                        # for oauth2
#                       fastcgi_param  PATH_TRANSLATED    $document_root$orig_path;
                }

                location / {
                        try_files                          $uri $uri/ index.php;
                }

                location ~ /\.ht {
                        deny all;
                }

                # Media: images, icons, video, audio, HTC, archives
                location ~* \.(?:jpe?g|gif|png|ico|cur|gz|bz2|tbz|tgz|svg|svgz|mp4|ogg|ogv|webm|htc|css|js|pdf|zip|rar|tar|txt)$ {
                        try_files $uri =404;

                        expires 1w;
                        access_log off;
                        add_header Cache-Control "public";
                }

                location ~ ^/(README|INSTALL|LICENSE|CHANGELOG|UPGRADING)$ {
                      deny all;
                }

                location ~ ^/(bin|SQL|config|temp|logs)/ {
                      deny all;
                }

How is PATH_TRANSLATED supposed to look like for this use case?
If I use a debug header instead of PATH_TRANSLATED with the setting, I get the document root in the "/script.php" case and the document root with the path info added in the "/script.php/whatever" case, which seems to work badly with php-fpm. I assume that php-fpm tries to use PATH_TRANSLATED instead of SCRIPT_FILENAME when PATH_TRANSLATED is present. For the login page ("https://domain.tld/") this means PATH_TRANSLATED points to the document root directory instead of the file .../index.php.

Bye,
Alexander.

[JohnDoh]

Does the fix mentioned on this ticket help at all https://github.com/roundcube/roundcubemail/issues/8144 ?

[netchild]

My roundcube version has already the fix for '/\?_task=[a-z]+/', so this doesn't fix my issues.
I have validated, that the config.inc.php pgre_match workaround fixes the issue.
I have validated, that the $config['assets_path'] = '/'; part fixes the issue.