nextcloud
[Bug]: Can't enable or disable apps after upgrade to v30.0.0
⚠️ This issue respects the following points: ⚠️
- [X] This is a bug, not a question or a configuration/webserver/proxy issue.
- [X] This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
- [X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- [X] I agree to follow Nextcloud's Code of Conduct.
Bug description
See #44685 - I can't enable apps because of this CSP error. It worked before the update.
Steps to reproduce
- I click "enable"
- It says "This app cannot be enabled because it makes the server unstable"
- Browser console tells me "Content-Security-Policy: Die Einstellungen der Seite haben das Laden einer Ressource (connect-src) auf http://example.com/apps/files/ blockiert, da sie gegen folgende Direktive verstößt: "connect-src 'self' blob: https://stun.nextcloud.com:443""
Expected behavior
App is enabled
Nextcloud Server version
master
Operating system
None
PHP engine version
PHP 8.1
Web server
None
Database engine version
None
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
- [ ] Default user-backend (database)
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other
Configuration report
No response
List of activated Apps
No response
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response
any workaround are there? i have installed new nextcloud at v30 through docker compose but i cannot enable external storage support app
occ app enable external
when i enable external storage and occ app enable app , server can't be accessed, it return 500
Die Einstellungen der Seite haben das Laden einer Ressource (connect-src) auf http://example.com/apps/files/ blockiert, da sie gegen folgende Direktive verstößt: "connect-src 'self' blob: https://stun.nextcloud.com:443""
Are you, in fact, using http?
You didn't really give us much to go on since you left the Issue template basically blank.
This CSP error suggests a misconfiguration, generally speaking.
Check your browser inspect Network tab while recreating the problem. Make sure reasonable URLs are appearing, no mixing of http and https, etc.
@joshtrichards
here is my capture. this image shows this site is running under https scheme but when i try enabling an app, the request is blocked due to mixed scheme.
Same issue here. Worked fine before the upgrade. After upgrade apps are no longer manageable.
My Instance runs under plain http behind a reverse proxy which handles TLS.
This CSP error suggests a misconfiguration, generally speaking.
Why is it suddenly misconfigured after an upgrade when everything was working fine before? Do we need to migrate our configuration to some new format introduced in 30? How?
Why is it suddenly misconfigured after an upgrade when everything was working fine before?
No idea because not one person reporting this in this issue has provided basics like their configuration. ;-)
Under Network in the browser inspect, check the request[s] to https://cloud.domain.tld/apps/files[/] and post the request+response headers.
Related: #45378
here my some configuration.
forceing https (on config.php) doesn't change anything, behavior is same. only enable or disable apps on administration
browser info on devtools network tab: server responses redirecting to http even though on https scheme server
Request URL:
https://!!!!!!/apps/files
Request Method:
GET
Status Code:
301 Moved Permanently
Referrer Policy:
no-referrer
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sun, 13 Oct 2024 15:33:31 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: http://!!!!!!/apps/files/
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: noindex, nofollow
X-XSS-Protection: 1; mode=block
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: noindex, nofollow
X-XSS-Protection: 1; mode=block
GET /apps/files HTTP/1.1
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Cookie: !!!!!!
Host: !!!!!!
Pragma: no-cache
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
X-Requested-With: XMLHttpRequest, XMLHttpRequest
requesttoken: !!!!!!
sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
new nextcloud setup configuration
dc
services:
app:
image: docker.io/library/nextcloud:fpm
restart: always
volumes:
- /mnt/storage:/data
- /svc/nextcloud/html:/var/www/html
environment:
NEXTCLOUD_DATA_DIR: /data
POSTGRES_DB: nextcloud
POSTGRES_USER: !!!!!!
POSTGRES_PASSWORD: !!!!!!
POSTGRES_HOST: !!!!!!
web:
image: nginx
restart: always
ports:
- "!!!!!:8080:80"
links:
- app
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
volumes_from:
- app
nginx.conf
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
# Prevent nginx HTTP Server Detection
server_tokens off;
keepalive_timeout 65;
# Set the `immutable` cache control options only for assets with a cache busting `v` argument
map $arg_v $asset_immutable {
"" "";
default "immutable";
}
#gzip on;
upstream php-handler {
server app:9000;
}
server {
listen 80;
# HSTS settings
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
#add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
# set max upload size and increase upload timeout:
client_max_body_size 512M;
client_body_timeout 300s;
fastcgi_buffers 64 4K;
# The settings allows you to optimize the HTTP2 bandwidth.
# See https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
# for tuning hints
client_body_buffer_size 512k;
# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml text/javascript application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/wasm application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
# Pagespeed is not supported by Nextcloud, so if your server is built
# with the `ngx_pagespeed` module, uncomment this line to disable it.
#pagespeed off;
# HTTP response headers borrowed from Nextcloud `.htaccess`
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "noindex, nofollow" always;
add_header X-XSS-Protection "1; mode=block" always;
# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;
# Path to the root of your installation
root /var/www/html;
# Specify how to handle directories -- specifying `/index.php$request_uri`
# here as the fallback means that Nginx always exhibits the desired behaviour
# when a client requests a path that corresponds to a directory that exists
# on the server. In particular, if that directory contains an index.php file,
# that file is correctly served; if it doesn't, then the request is passed to
# the front-end controller. This consistent behaviour means that we don't need
# to specify custom rules for certain paths (e.g. images and other assets,
# `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
# `try_files $uri $uri/ /index.php$request_uri`
# always provides the desired behaviour.
index index.php index.html /index.php$request_uri;
# Rule borrowed from `.htaccess` to handle Microsoft DAV clients
location = / {
if ( $http_user_agent ~ ^DavClnt ) {
return 302 /remote.php/webdav/$is_args$args;
}
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
# The rules in this block are an adaptation of the rules
# in `.htaccess` that concern `/.well-known`.
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
location /.well-known/acme-challenge { try_files $uri $uri/ =404; }
location /.well-known/pki-validation { try_files $uri $uri/ =404; }
# Let Nextcloud's API for `/.well-known` URIs handle all other
# requests by passing them to the front-end controller.
return 301 /index.php$request_uri;
}
# Rules borrowed from `.htaccess` to hide certain paths from clients
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) { return 404; }
# Ensure this block, which passes PHP files to the PHP process, is above the blocks
# which handle static assets (as seen below). If this block is not declared first,
# then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
# to the URI, resulting in a HTTP 500 error response.
location ~ \.php(?:$|/) {
# Required for legacy support
rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
fastcgi_param front_controller_active true; # Enable pretty urls
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
fastcgi_max_temp_file_size 0;
}
# Javascript mimetype fixes for nginx
# Note: The block below should be removed, and the js|mjs section should be
# added to the block below this one. This is a temporary fix until Nginx
# upstream fixes the js mime-type
location ~* \.(?:js|mjs)$ {
types {
text/javascript js mjs;
}
try_files $uri /index.php$request_uri;
add_header Cache-Control "public, max-age=15778463, $asset_immutable";
access_log off;
}
# Serve static files
location ~ \.(?:css|svg|gif|png|jpg|ico|wasm|tflite|map|ogg|flac)$ {
try_files $uri /index.php$request_uri;
add_header Cache-Control "public, max-age=15778463, $asset_immutable";
access_log off; # Optional: Don't log access to assets
location ~ \.wasm$ {
default_type application/wasm;
}
}
location ~ \.woff2?$ {
try_files $uri /index.php$request_uri;
expires 7d; # Cache-Control policy borrowed from `.htaccess`
access_log off; # Optional: Don't log access to assets
}
# Rule borrowed from `.htaccess`
location /remote {
return 301 /remote.php$request_uri;
}
location / {
try_files $uri $uri/ /index.php$request_uri;
}
}
}
server responses redirecting to http even though on https scheme server
Location: http://!!!!!!/apps/files/
That redirect to http is coming from your infrastructure, not Nextcloud.
See https://github.com/nextcloud/server/issues/44685#issuecomment-2067203058 (and the discussion that follows).
This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.
This is not a reverse-proxy configuration issue, it's a regression: it worked prior to 30.*. Even setting overridehost and overrideprotocol does not help. It can be worked around on the reverse proxy side, but is a regression nonetheless.
The issue is that after enabling an app, NC does an XHR to the wrong URL. In my case, it goes to http://cloud.scriptfanix.fr:8990. That XHR fails so NC says the app makes it unstable and proceeds to disable the app, see HAR attached.
cloud.scriptfanix.fr_Archive [25-04-23 16-57-47].har.zip
Same here. I (falsely) opened https://github.com/nextcloud/notify_push/issues/581 (should have been here). I have also tried all kinds of things on the reverse proxy side, to no avail.
@joshtrichards wdyt? New issues?
@kesselb posted in https://github.com/nextcloud/notify_push/issues/581#issuecomment-2847332162 that https://github.com/nextcloud/server/pull/52440 might fix this. Excited to test this.