Closed euh2 closed 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.
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.
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.
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!
I think a help with proxy setup is out of scope of this issue tracker. Closing.
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??
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?
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/
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)
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: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: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?