Cross-Origin Problem

[Linuchs]

Moin,

Liederbücher bestehen aus Seiten, die je ein iframe enthalten. Jedes iframe ein Lied.

Die Schriftgröße im Lied-Dokument ist abhängig davon, ob das Liederbuch im Titel a3, a5, a6 enthält:

  <script>
  // die Links zu den Titeln können verweisen auf A3, A4, A5, A6 -->
  console.log( top.location.href );
  if( top.location.href.indexOf ("a3") != -1 ) {
    document.writeln( '<link rel=stylesheet  href="css/basis_a3.css">' );
  } else if( top.location.href.indexOf ("a5") != -1 ) {
    document.writeln( '<link rel=stylesheet  href="css/basis_a5.css">' );
  } else if( top.location.href.indexOf ("a6") != -1 ) {
    document.writeln( '<link rel=stylesheet  href="css/basis_a6.css">' );
  }
  </script>

Der Firefox weigert sich local, top.location.href zur Kenntnis zu nehmen. Top- und iframe-Dokumente sind im selben Ordner:

Uncaught DOMException: Permission denied to get property "href" on cross-origin object

Nach Hochladen des Liederbuchs und der Lied-Dokumente ist das kein Problem mehr, wie kann ich das auch ohne Hochladen erreichen?

fragt Linuchs

[MudGuard]

Hi,

Die Schriftgröße im Lied-Dokument ist abhängig davon, ob das Liederbuch im Titel a3, a5, a6 enthält:

  <script>
  // die Links zu den Titeln können verweisen auf A3, A4, A5, A6 -->
  console.log( top.location.href );
  if( top.location.href.indexOf ("a3") != -1 ) {
    document.writeln( '<link rel=stylesheet  href="css/basis_a3.css">' );
  } else if( top.location.href.indexOf ("a5") != -1 ) {

Du schreibst, daß das im Titel (also title oder h1) steht, liest dann aber in der Url?

Der Firefox weigert sich local, top.location.href zur Kenntnis zu nehmen.

Ohne Webserver (also im File-Protokoll?) ist alles, auch eine Datei im gleichen Pfad, cross-origin.

Was spricht gegen die Verwendung eines lokalen Webservers?

cu,
Andreas a/k/a MudGuard

[Linuchs]

Was spricht gegen die Verwendung eines lokalen Webservers?

Nach Programmänderungen und lokalem Test wird mit Sicherheit irgendein Snippet vergessen hochzuladen und die Fehlersuche geht los ...

[Tabellenkalk]

Hallo,

Was spricht gegen die Verwendung eines lokalen Webservers?

Nach Programmänderungen und lokalem Test wird mit Sicherheit irgendein Snippet vergessen hochzuladen und die Fehlersuche geht los ...

Spricht was dagegen, den lokalen Test am lokalen Webserver zu tätigen?

Gruß
Kalk

[Raketenwilli]

Hattest Du nicht sowieso PHP?

Mach ein Terminal auf, wechsle in das Verzeichnis mit den Dateien und starte einfach

C:
cd "C:\Pfad\zum\Webroot"
php -S localhost:9001

Unter Windows womöglich (wenn Du den Pfad nicht registriert hast):

C:\Pfad\zu\php.exe -S localhost:9001

Danach kannst Du im Browser Deine Seite zumindest grundlegend testen:

http://localhost:9001/index.php

oder

http://localhost:9001/musik/liedtexte/fiddlers_green_en_a3.htm

Natürlich kannst Du da nichts testen, was Einstellungen in der Datei .htaccess erfordert, denn das versteht nur der Apache.

Um den Server zu beenden drücke [STRG]+[C]. Noch einfacher geht es nicht. Oder doch? Klar. Unter Linux kannst das „C:“ und Pfad-Geraffel weglassen.

[Rolf B]

Hallo Linuchs,

das hatten wir dieses Jahr schon mehrfach. file:/// ist grundsätzlich nicht same-origin.

Das kann man im Firefox per Flag abschalten.

• about:config aufrufen
• security.fileuri.strict_origin_policy auf false setzen.

In einer kontrollierten Umgebung kann man das machen.

Alternative 1 ist JavaScript und das Messaging API. D.h. Du lässt Hauptseite und iframe per Messaging miteinander reden, das geht auch über Origins hinweg, weil das nur geht wenn beide Parteien kooperieren.

Alternative 2 ist ein lokaler Webserver, der einfach das Liederverzeichnis als Web-Root nimmt. Einfachste Lösung: Kopiere ein PHP auf die Kiste und starte

php -S 127.0.0.1:8888 -t /usr/lieder/

oder ähnlich, je nach deinen Gegebenheiten. PHP belegt allerdings (unter Windows) über 50 MB. Der nginx, der zum Offline-Selfwiki gehört, keine 4MB. Den musst Du nur konfigurieren lernen. Es muss ja nicht immer ein ausgewachsener Indianerhäuptling sein.

Was spricht gegen die Verwendung eines lokalen Webservers?

Nach Programmänderungen und lokalem Test wird mit Sicherheit irgendein Snippet vergessen hochzuladen und die Fehlersuche geht los ...

Wenn Du das Deployment sauber scriptest, sollte das überhaupt kein Problem sein. Und das Problem hängt nicht vom lokalen Webserver ab, das stellt sich bei Verwendung von file:/// genauso.

Rolf

[ThomasM]

Hallo zusammen,

als Ergänzung für den file-Zugriff mit Chromium-Browsern: dort an die Programmverknüpfung --allow-file-access-from-files hängen.

Grüße,
Thomas