roundcube / roundcubemail

The Roundcube Webmail suite
https://roundcube.net
GNU General Public License v3.0
5.79k stars 1.62k forks source link

[oauth2] Invalid redirect URI when RCM runs in sub-directory #7924

Closed euh2 closed 3 years ago

euh2 commented 3 years ago

I'm testing the oauth2 features in the upcoming v1.5. The RCM Installation runs in a sub-directory (i.e. webmail). The auth uri is something like $config['oauth_auth_uri'] = 'https://THE.OAUTH2.SERVER/auth/realms/REALM/protocol/openid-connect/auth'; When trying to login with openid, RCM builds the URI like:

[...]openid-connect/auth?response_type=code&client_id=A_BIT_SECRET&scope=email+profile+address+phone+roles&redirect_uri=https%3A%2F%2F<THE.RCM-BASE.DOMAIN>%2Findex.php%2Flogin%2Foauth&state=uuzs9m4F7fWc

Notice how the sub-directory is missing in the redirect_uri. The installation is behind a reverse-proxy and running debian-fpm-flavour. I'm passing $http_x_forwarded_prefix to fpm through:

fastcgi_param REQUEST_URI       $http_x_forwarded_prefix$request_uri;

But still, RCM doesn't recognize that it is doomed to live in a sub-directory. Any thoughts on this? Bug or missconfiguration on my hand?

skug67 commented 3 years ago

I've got no problem with running roundcube at a suburl and with oauth (once I finally figured out the oauth stuff). I don't have the reverse proxy issue, but running under apache at a suburl using the "Location" directive works a charm with no special configuration.

thomascube commented 3 years ago

This might a missing piece in Roundcube's url() function which is used here. It relies on PHP environment variables REDIRECT_SCRIPT_URL and SCRIPT_NAME if the former is missing. Maybe there are some tweaks in the nginx or php-fpm configuration to get these set correctly but I honestly don't have a solution right away as I'm lacking the setup you have. Maybe setting

fastcgi_param REDIRECT_SCRIPT_URL $http_x_forwarded_prefix$request_uri;

will already do the trick.

euh2 commented 3 years ago

I don't have the reverse proxy issue

It might have something to do with the reverse proxy. RCM doesn't see the full URI, that's my hunch.

euh2 commented 3 years ago

Maybe setting

fastcgi_param REDIRECT_SCRIPT_URL $http_x_forwarded_prefix$request_uri;

will already do the trick.

That brings me a bit closer, I think. With that parameter I at least get the sub-directory in the redirect_uri. But then I hit a 404 Wall. Now I think there is something wrong with my nginx reverse proxy config. From the logs I see that the 404 comes from the reverse proxy, it never reaches RCM fpm!

From the reverse proxy logs:

10.24.109.25 - - [09/Mar/2021:13:48:32 +0000] "GET /index.php/login/oauth?state=L1umpHteHzaH&session_state=21624e49-36b5-488b-b6f1-dcc88a78d20b&code=35b83b78-e78b-4453-86dd-504062b3a51f.21624e49-36b5-488b-b6f1-dcc88a78d20b.c90d66b7-7908-4be1-b8d1-8cc9d026483f HTTP/1.1" 404 153 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"

I thought my nginx config would direct index.php to the backend RCM fpm container. Here my obviously faulty nginx.conf:

server {
    listen 80 default_server;
    server_name _;
    root /var/www/html;
    index index.php index.html;
    location / {
        try_files $uri /index.php$is_args$args;
    }
    location ~ \.php(/|$) {
        try_files $uri =404;
        fastcgi_pass webmail:9000;
        fastcgi_read_timeout 300;
        proxy_read_timeout 300;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME   $realpath_root$fastcgi_script_name;
        # fastcgi_param SCRIPT_FILENAME   $realpath_root$http_x_forwarded_prefix;
        fastcgi_param PATH_INFO         $fastcgi_path_info;
        # fastcgi_param REQUEST_URI       $http_x_forwarded_prefix$request_uri;
        fastcgi_param REDIRECT_SCRIPT_URL $http_x_forwarded_prefix$request_uri;
        # fastcgi_param DOCUMENT_URI      $http_x_forwarded_prefix$document_uri;
        # fastcgi_param DOCUMENT_ROOT     $realpath_root;
        internal;
    }
    client_max_body_size 60m;
    error_log  /var/log/nginx/error.log;
    access_log /var/log/nginx/access.log;
}

Appreciate any thought on this problem!

alecpl commented 3 years ago

I think a help with proxy setup is out of scope of this issue tracker. Closing.

kxitiz commented 1 year ago

Hello, There is the problem with roundcube when it redirects from oauth nginx throws 404 not found. I have enabled oauth provider as generic. Also this is not even a sub path.. Whats happening here?? 2023-08-13_12-46

jmallach commented 1 year ago

I'm seeing what @kxitiz reported last week as well. @kxitiz, can you share some of your setup details? Apache or Nginx? Clean URLs or not?

kxitiz commented 1 year ago

Hello @jmallach in this i have setup roundcube in docker and reverse proxy is nginx which points to docker port exposed. and the complete config is https://goauthentik.io/integrations/services/roundcube/

pathwayx99 commented 10 months ago

Hey @kxitiz did you get anywhere with this? I am seeing the exact same issue. Similar setup to yours (docker, reverse proxy Traefik, used authentik and the same instructions) and I'm also getting the 404 error. The message in the nginx logs is /opt/www/webmail/index.php/login/oauth" failed (20: Not a directory)