Javascript Fehler im Browser

Hallo,
ich habe, denke ich, seit Beginn an, diese Konsolen-Fehler im Browser und dachte immer:
“Ach, mit der nächsten Version” verschwinden die schon"

Dies ist nun aber fast 2 Jahre her und irgendwie werden die Fehler nicht besser.

Ich habe z.B. beim Aufrufen des Dashboard diese Fehler:

Dashboard

Und beim Aufrufen der Dateien diese:
Dateien

Seltsam ist auch, das immer ein 404 Fehler erzeugt wird, wenn der aufgerufene Ordner keine “Readme.md” Datei enthält.

Nunja, diesen kann man ja “lassen” - aber die 2 Fehler hätte ich dann schon gerne einmal bereinigt.

Danke!

Hi. I think this error is known. Look here.

You use 23.0.1 RC1 perhaps this is also a problem.
Do you use a security software in your browser and/or operating system?
Perhaps you must exclude your nextcloud.

Known Error does not mean it is solved, right :wink:

I am not quite sure, what security software has to do with the DOM registration handler.

In wieweit hast du zugriff auf die Cloud.
Ich frage das weil das hübsch nach nen ssl header Fehler ausschaut :wink:

Und ja da devnull hat das schon ganz gut erkannt. Der Browser spielt da eine Rolle.

Schau mal was unter /etc/apache2/sites-enabled/******.conf
Bei

SSLProtocol
SSLCipherSuite

usw… steht.

Ansonsten kann man da auch was in der .htaccess richten.

Das alles muss nicht zwangläufig ein Fehler von Javascript sein.
Check mal auf https://securityheaders.com/
deine Seite.

Hallo,
also, die Cloud läuft auf meinem Server zu Hause in einem TrueNAS (ehemals FreenAS) Jail mit Nginx.
Davor ist ein Apache Reverse Proxy geschaltet.

Beim Test mit dem Securityheader bekomme ich aktuell ein “A”.
So brachte mich die Suche auf etwas mit den “Content Security Policy” :wink:

Man solle wohl

### Apache Content-Security-Policy Header

Add the following to your `httpd.conf` in your `VirtualHost` or in an `.htaccess` file:

Header set Content-Security-Policy “default-src ‘self’;”

### Nginx Content-Security-Policy Header

In your `server {}` block add:

add_header Content-Security-Policy “default-src ‘self’;”;

nutzen. Jedoch zeigt meine Seite dann gar nichts mehr an. Es kommen 99+ Javascript Fehler in der Konsole.

Aber, der Punkt scheint irgendwie in die richtige Richtung zu gehen - jedoch weiss ich jetzt nicht weiter, wenn ich den o.g. Code einfüge, bekomme ich ein “A+” bei securityheaders, was augenscheinlich richtig ist - jedoch funktioniert meine Seite nicht mehr :smiley:

Oh ja das kenn ich :wink:
Deswegen hab ich das angesprochen.
Mein Vorschlag wäre es immer schön langsam. Fang mit die Header immer schrittweise an.
Es bingt nix jede menge Sicherheitsfeatures reinzuquetschen wenn dann z.b die Video und Micro Konferenz (Talk) nicht mehr geht.

Bei den Content-Security-Policy Header
hab ich auch die Erfahrung machen müssen das die Reihenfolge der Header set auch schon eine Rolle spielen kann.

Vergiss A+ beim Header in Zusammenhang mit “Talk” A ist schon gut.

Wenn ich mit curl schaue, dann kommt der CSP Header ja direkt von Nextcloud und “verursacht” das unsafe inline.
Den header hier habe ich nirgends angegeben.

content-security-policy: default-src 'self'; script-src 'self' 'nonce-ZWtxQlMvdkNlbWtsZ0dzd01SM1J4MzRJYkt0RFpXSHNydkFDYktkcDNpND06UENlcUdZbUJGZ3h1dVZ0MkNINkZzUmM1UitrUkZTK1A2TGRuVzhRK2lFbz0='; style-src 'self' '**unsafe-inline**'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';

Zu finden in der Datei:
/lib/private/legacy/OC_Response.php

$policy = 'default-src \'self\'; '
			. 'script-src \'self\' \'nonce-'.\OC::$server->getContentSecurityPolicyNonceManager()->getNonce().'\'; '
			. 'style-src \'self\' \'unsafe-inline\'; '
			. 'frame-src *; '
			. 'img-src * data: blob:; '
			. 'font-src \'self\' data:; '
			. 'media-src *; '
			. 'connect-src *; '
			. 'object-src \'none\'; '
			. 'base-uri \'self\'; ';
		header('Content-Security-Policy:' . $policy);

Aber gut, irgendwie kommen wir auf eine andere Strecke, die ich wollte :slight_smile:

Die Fehler von oben sehen mir irgendwie “anders” aus.

Da gibt es mehrere “Anlaufstellen” Angefangen in Apache bis hin zur .htaccess datei in Web root.
Vergleich doch mal /etc/apache2/sites-enabled

mit deinen .htaccess datein

Vergiss dein Apache Reverse Proxy nicht.

Gerade meinen Beitrag editiert.

Jedoch ist dies, denke ich, nicht der Fehler den ich da habe, das dort “Setter & Getter”, nicht aufgerufen werden können.

Hab ich wohl überlesen…

Was steht in deine .htaccess datei ?

Dieses steht da drin. Habe ich nicht geändert. Das wäre die, auf dem Nginx mit Nextcloud läuft.

<IfModule mod_headers.c>
  <IfModule mod_setenvif.c>
    <IfModule mod_fcgid.c>
       SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
       RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
    </IfModule>
    <IfModule mod_proxy_fcgi.c>
       SetEnvIfNoCase Authorization "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>
    <IfModule mod_lsapi.c>
      SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
      RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
    </IfModule>
  </IfModule>

  <IfModule mod_env.c>
    # Add security and privacy related headers

    # Avoid doubled headers by unsetting headers in "onsuccess" table,
    # then add headers to "always" table: https://github.com/nextcloud/server/pull/19002
    Header onsuccess unset Referrer-Policy
    Header always set Referrer-Policy "no-referrer"

    Header onsuccess unset X-Content-Type-Options
    Header always set X-Content-Type-Options "nosniff"

    Header onsuccess unset X-Download-Options
    Header always set X-Download-Options "noopen"

    Header onsuccess unset X-Frame-Options
    Header always set X-Frame-Options "SAMEORIGIN"

    Header onsuccess unset X-Permitted-Cross-Domain-Policies
    Header always set X-Permitted-Cross-Domain-Policies "none"

    Header onsuccess unset X-Robots-Tag
    Header always set X-Robots-Tag "none"

    Header onsuccess unset X-XSS-Protection
    Header always set X-XSS-Protection "1; mode=block"

    SetEnv modHeadersAvailable true
  </IfModule>

  # Add cache control for static resources
  <FilesMatch "\.(css|js|svg|gif|png|jpg|ico|wasm|tflite)$">
    Header set Cache-Control "max-age=15778463"
  </FilesMatch>

  # Let browsers cache WOFF files for a week
  <FilesMatch "\.woff2?$">
    Header set Cache-Control "max-age=604800"
  </FilesMatch>
</IfModule>

# PHP 7.x
<IfModule mod_php7.c>
  php_value mbstring.func_overload 0
  php_value default_charset 'UTF-8'
  php_value output_buffering 0
  <IfModule mod_env.c>
    SetEnv htaccessWorking true
  </IfModule>
</IfModule>

# PHP 8+
<IfModule mod_php.c>
  php_value mbstring.func_overload 0
  php_value default_charset 'UTF-8'
  php_value output_buffering 0
  <IfModule mod_env.c>
    SetEnv htaccessWorking true
  </IfModule>
</IfModule>

<IfModule mod_mime.c>
  AddType image/svg+xml svg svgz
  AddType application/wasm wasm
  AddEncoding gzip svgz
</IfModule>

<IfModule mod_dir.c>
  DirectoryIndex index.php index.html
</IfModule>

<IfModule pagespeed_module>
  ModPagespeed Off
</IfModule>

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT} DavClnt
  RewriteRule ^$ /remote.php/webdav/ [L,R=302]
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
  RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

AddDefaultCharset utf-8
Options -Indexes
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 //
ErrorDocument 404 //

Also auf den ersten blick schaut die ganz gut aus.
versuch mal
sudo -u www-data php occ maintenance:mimetype:update-js

Danke für den Befehl. Habe ich ausgeführt. Leider bleiben die o.g. Fehler bestehen.

Also ich hab da immernoch die Header in Verdacht. :wink:
Schnapp dir mal nen andern Browser (Nicht Firefox :wink: )
Und zeig mal die Ausgabe.

Aber mal ehrlich. Auch die Webseite der Deutschen Bank zeigt ein paar Fehler an :smiley:
2

Danke für deine Ideen :slight_smile:

Ich habe nun auch mal genauer geschaut. Also, die 2 Dashboard Fehler kommen erstmal durch den allgemeinen Viewer, der die DOM nicht richtig registriert. Soll aber im nächsten Release gefixt sein.

Des weiteren ist dieser “insecure” inline code wohl aktuell gewollt, weil noch nicht alle “Apps” auf die neuen Header können.

Somit sind das “Probleme”, die dadurch kommen, wenn die Haupt-Applikation nicht den richtigen Weg vorgibt :slight_smile:

Naja 2 jahre Später :stuck_out_tongue:

Solang sich die Jahreszahlen im einstelligen Bereich bewegen, geht es doch noch :wink:

1 Like