Nextcloud version: 18.0.6
Operating system and version: Debian 10 buster
Apache or nginx version: Apache2 2.4.38-3
PHP version: 7.3
Reverse Proxy
Operating system and version: Debian 10 buster
Apache or nginx version: Nginx 1.14.2-2
BTW - I added spaces to some of the URIs to circumvent the limit of 4 links in a new post.
The issue I am facing:
I run NC on apache2. To access NC and all my internal web sites I use a nginx reverse proxy in front. The reverse proxy does SSL termination and client certificate authentication for most of the applications.
Example:
NC URI on internal web server: “int . domain . test/nextcloud”
Reverse Proxy listens on: “www . domain . com”
URI to access NC from outside: “www . domain . com/nextcloud”
“www . domain . com/nextcloud” gets redirected by the rev proxy to “int . domain . test/nextcloud”. The rev proxy asks for and verifies the client certificate the user has to provide.
Users without an approved client certificate don’t get the NC login page to see. Users providing an approved client certificate see the NC login page and can log in (they need to enter their login credentials though).
The nginx configuration on the rev proxy consists of:
location /nextcloud/ {
if ($ssl_client_verify != "SUCCESS") {
return 403;
}
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass https://int . domain . test/nextcloud/;
proxy_pass_header $server;
proxy_read_timeout 90;
}
That works smoothly.
The issue though is if a user shared a document or folder the link gets sent by email and the URL for the shared document is something like “www . domain . com/nextcloud/s/3fh57dj34”.
If the user who received the link had a valid client certificate, they can access NC through “www . domain . com/nextcloud/s/3fh57dj34” and view the document.
If the user who received the link had not a valid client certificate, they can’t access NC through “www . domain . com/nextcloud/s/3fh57dj34” to view the document.
To circumvent this I added the following to the nginx rev proxy:
location /nextcloud/s/ {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass https://int . domain . test/nextcloud/s/;
proxy_pass_header $server;
proxy_read_timeout 90;
}
location /nextcloud/apps/ {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass https://int . domain . test/nextcloud/apps/;
proxy_pass_header $server;
proxy_read_timeout 90;
}
For the two URLs nextcloud/apps/ and nextcloud/s/ there is no verification of the client certificate anmyore. This works somehow and a guest user without a client certification can see some basic share page but the page is not the nicest, the reader app is missing and some functionality is lost
(it doesn’t work for shared folders as some general things are missing).
To generally solve this some more URLs needed to be excluded from certificate verification - which leads client certification authentication ad absurdum.
Question:
is there a way to create a URL for shared document as a “root” URL with everything else “below” that URL?
If /nextcloud/s was the “root” URL everything else like needed apps (for the reader) would then be something like /nextcloud/s/apps/… and not /nextcloud/apps anymore. In that case just one excluded redirect would be sufficient to allow guest to access shared documents.