piet: Variable aus fremder Webseite auslesen

0 62

Variable aus fremder Webseite auslesen

piet
  • html
  • javascript
  1. 1
    Felix Riesterer
    1. 0
      piet
      1. 0
        Linuchs
      2. 0
        Raketendatenbezieher
      3. 1
        Raktendatenbezieher
        1. 0

          Und grüß mir das Murmeltier!

          Raketendatenbezieher
        2. 0
          marctrix
          1. 0
            Raketendatenfuzzi
            1. 1

              Variable aus EIGENER Webseite auslesen

              Raketensubjektkorrigierer
            2. 1
              Der Martin
              • meinung
              • programmiertechnik
              1. 0
                Raketendatenverteiler
                1. 0
                  Der Martin
                  1. 0
                    Raketendatenverteiler
              2. 0
                JürgenB
                1. 0
                  Der Martin
                  1. 0
                    Raketendatenfuzzi
          2. 0
            Gunnar Bittersmann
            1. 0
              Der Martin
              • sprache
              1. 0
                Gunnar Bittersmann
                1. 0
                  Der Martin
                  1. 0
                    Gunnar Bittersmann
                    1. 0
                      Der Martin
                    2. 1
                      MudGuard
  2. 0
    JürgenB
    1. 0
      Linuchs
      1. 0
        Der Martin
        1. 0
          Linuchs
          1. 0
            Der Martin
      2. 0
        JürgenB
        1. 0
          Linuchs
    2. 0
      piet
      1. 0
        JürgenB
      2. 0
        JürgenB
        1. 0

          Kinder! Nicht nachmachen!

          Raketenwarnsystem
          1. 0
            JürgenB
            1. 0
              Raketenwarnsystem
              1. 0
                JürgenB
          2. 0
            pl
      3. 0
        marctrix
        1. 0
          Raketenkrückendestruktor
          1. 0
            piet
            1. 0
              Raketenwarnsystem
  3. 1

    BTW: Variable im Response-Header übertragen?

    TS
    • html
    • https
    1. 0
      Felix Riesterer
      1. 0
        Auge
        1. 1
          TS
          1. 1
            Auge
            1. 1
              robertroth
              • menschelei
              1. 1
                Auge
                • meinung
      2. 0
        robertroth
        • html
        • https
        • rfc
        1. 0
          Felix Riesterer
    2. 1
      pl
    3. 1
      robertroth
      1. 0
        pl
    4. 0
      Mitleser
    5. 1
      Rolf B
      1. -2
        pl
        1. 2
          Rolf B
          1. 0

            Danke für Deinen Hinweis auf den Accept'Header.

            pl
    6. 1
      1unitedpower
    7. 0
      Raketendatentransferfuzzi

Hallo,

ich zeige auf einer Webseite (Masterwebseite) mittels iframe andere Webseiten (fremde Webseiten) an. Die "fremden Webseiten" liefern mir eine Tabelle mit Messwerten.

Kann ich von diesen "fernen" Webseiten auch einen Wert/Messwert der mir angezeigt wird auslesen um den Messwert auf der Masterwebseite zu bearbeiten ??

Beispiel ############

Masterwebseite

<iframe src="http://x.y:32080/public/info.html"</iframe>

Fremde Webseite liefert ... <table><tr><td id="messwert_1"> 9.99 ...

Auf meiner "Masterwebseite" wird nun die fremde Webseite mit der Tabelle angezeigt. Wie, wenn überhaupt möglich, den Messwert der hinter der "id="messwert_1" angezeigt wird auslesen.

Eventuell gibt es auch eine ganz andere herangehensweise ??

Bin für jeden Tip dankbar ...

Danke

  1. Lieber piet,

    wenn die Inhalte eines Iframes von einer anderen Domain kommen, dann greift ein Sicherheitsfeature (same origin policy), das es Dir mit JavaScript unmöglich macht, die Inhalte von der Hauptseite aus zu verarbeiten.

    Wenn Du eine serverseitige Scriptsprache (z.B. PHP) einsetzt, kannst Du Dein Anliegen umsetzen, da Du dann keine Frames mehr benötigst, denn dann kann Dein serverseitiges Script die fremde Seite laden, parsen, und das Ergebnis in Deine Hauptseite hinein schreiben.

    Hast Du schon Erfahrung mit einer serverseitigen Scriptsprache gemacht?

    Liebe Grüße

    Felix Riesterer

    1. Hallo,

      vielen Dank für den Hinweis. Ich benutze perl. Dadurch könnte ich ein perlscript schreiben, das mir den Inhalt der Webseite (fremde Seite) liest und dann den Wert auslesen.

      Schöner wäre natürlich die Variable auf der fremden Seite direkt zu lesen. So brächte ich nur ein Script das immer funktioniert, ohne jeweils auf jeden iframe angepasst werden zu müssen.

      Ich habe jetzt etwas (viel) gegoggelt, da werden Methoden angezeigt, aber wie Du schon angedeutet hast bekomme ich immer einen Zugriffsfehler.

      Nochmals ... wenn doch der iframe auf meiner "Masterseite" angezeigt wird, ist doch der Inhalt der Seite schon mein "mir".

      Könntest Du etwas detalierter werden ?

      Danke

      1. Hallo piet,

        betrachte die Daten im iframe wie ein zugeschlagenes Buch, du kommst an die Inhalte nicht dran.

        Lies die fremde Webseite mit perl und werte sie aus. Davon unabhängig zeige den iframe an.

        Linuchs

      2. Dieser Beitrag wurde gelöscht: Der Beitrag ist ein Duplikat eines anderen Beitrags.
      3. Ich benutze perl.

        Herzliches Beileid.

        Dadurch könnte ich ein perlscript schreiben, das mir den Inhalt der Webseite (fremde Seite) liest und dann den Wert auslesen.

        Dann verzichte doch ganz auf den Iframe. Ein serverseitiges Skript holt die Inhalte vom fremden Server ab, zerlegt diese und baut die Daten in Deine Seite ein. Das könntest Du zur Freude des anbieters der Daten und Deiner Seitenbesucher auch serverseitig cachen.

        Freilich geht das auch per xmlhttprequest und iframe: Dann baue eine leere Seite für den Iframe mit einem Javascript darin, welches die fremde Seite abholt und den body der abgeholten Seite in den eigenen Body schreibt.

        Noch besser wäre es, Du jubelst dem Anbieter der Daten den Wunsch nach einer API unter und der liefert Dir z.B. JSON dessen Daten Du dann nach eigenem Gusto - und ohne die Krücke iframe verbauen kannst.

        1. Noch besser wäre es, Du jubelst dem Anbieter der Daten den Wunsch nach einer API unter und der liefert Dir z.B. JSON dessen Daten Du dann nach eigenem Gusto - und ohne die Krücke iframe verbauen kannst.

          Ich sollte mir dafür einen Textbaustein anlegen.

        2. Hej Raktendatenbezieher,

          Noch besser wäre es, Du jubelst dem Anbieter der Daten den Wunsch nach einer API unter und der liefert Dir z.B. JSON dessen Daten Du dann nach eigenem Gusto - und ohne die Krücke iframe verbauen kannst.

          In einer echten HTML-Tabelle liegen doch strukturierte Daten vor, deren Beziehungen programmatisch ermittelbar sind.

          Wenn thead, th, body und td bestimmungsgemäß verwendet werden. Glücklicherweise passiert das ziemlich häufig.

          Außerdem hat die Tabelle mit viel Glück vielleicht noch eine id - oder es gibt davor wenigstens eine hx nach der man suchen kann.

          Als jemand, der nicht programmieren kann, scheint diese Aufgabe relativ leicht lösbar. - Ich gehe jetzt mal davon aus, dass es sich um eine Website handelt, die es schon eine Weile gibt und die auch noch eine Weile weiter besteht. Selbst nach einem relaunch der Website gibt es eine recht hohe Chance, dass sich dieselbe Tabelle in einer neuen Struktur und einem neuen Layout irgendwo auf der Site wiederfindet und man an dem Skript, dass aus dieser Tabelle die Daten ausliest, nur eine andere URL übergeben muss…

          Klar wäre eine API noch etwas eleganter, dann kann man Daten womöglich direkt von der DB beziehen. Was mich zu einem anderen Gedanken bringt. Wenn der Anbieter der Daten die Weiterverarbeitung vorsähe, gäbe es diese API womöglich schon. Ich hoffe, wir helfen hier nicht gerade bei einer Urheberrechtsverletzung?!?

          Marc

          --
          Ceterum censeo Google esse delendam
          1. Klar wäre eine API noch etwas eleganter, dann kann man Daten womöglich direkt von der DB beziehen. Was mich zu einem anderen Gedanken bringt. Wenn der Anbieter der Daten die Weiterverarbeitung vorsähe, gäbe es diese API womöglich schon.

            Also, wenn eine Webseite im Kern eigentlich die Daten in einer Tabelle (oder mehreren) liefern soll, dann habe ich entweder irgendwo einen (oder mehrere) Array(s) (oder kann einen "bauen") und kann z.B. anhand der Existenz und/oder der Gültigkeit eines API-Keys in den Parametern…

            https://x.y.example.com/foo/?apikey=dfsfg&apitype=json
            

            …entscheiden, ob ich das Template bemühe und eine Webseite zusammembastele oder kurzerhand JSON, meinetwegen XML ausliefere.

            Eleganter und billiger geht es doch gar nicht und ich frage mich ersthaft warum piet, der nunmehr angibt, dass ihm die Quelle ja selbst gehört, das nicht einfach mal umsetzt statt immer noch mit dem iframe herumzumurksen.

            "Etwas anderes" Beispiel, bei dem das &download=1 den Unterschied macht:

            In einer echten HTML-Tabelle liegen doch strukturierte Daten vor,

            Ich werde doch nicht erst "teuer" eine HTML-Tabelle "bauen" und diese dann "noch teurer" mit Text-, DOM- und/oder XML-Methoden wieder in Daten zerlegen…

            (Piet hat inzwischen verraten, dass er auf das Aussenden Einfluss hat.)

            1. Eleganter und billiger geht es doch gar nicht und ich frage mich ersthaft warum piet, der nunmehr angibt, dass ihm die Quelle ja selbst gehört, das nicht einfach mal umsetzt statt immer noch mit dem iframe herumzumurksen.

              Ich hab mal das Subjekt geändert.

            2. Hallo,

              Also, wenn eine Webseite im Kern eigentlich die Daten in einer Tabelle (oder mehreren) liefern soll, dann habe ich entweder irgendwo einen (oder mehrere) Array(s) (oder kann einen "bauen") und kann z.B. anhand der Existenz und/oder der Gültigkeit eines API-Keys in den Parametern…

              das bringt mich wieder einmal zu der Frage, warum viele Web-APIs einen Key zur Nutzung brauchen, anstatt die Schnittstelle "offen" zu betreiben. Wenn ich irgendwelche Daten über eine Webseite frei zugänglich mache, warum dann nicht auch inhaltlich gleich über die dazu passende API-Schnittstelle[1]?

              Ciao,
               Martin

              --
              Ich stamme aus Ironien, einem Land am sarkastischen Ozean.

              1. Ja, ich weiß, eine blöde Wortkontruktion. Etwa wie das LCD-Display für die Elektroniker oder das DRS-System bei der Formel1. ↩︎

              1. das bringt mich wieder einmal zu der Frage, warum viele Web-APIs einen Key zur Nutzung brauchen, anstatt die Schnittstelle "offen" zu betreiben.

                Weil die Betreiber (und sei es nur zur Überlastvermeidung) zwar eine API aber gerade keinen gänzlich freien Zugang schaffen wollen? Freilich sind die API-Keys an sich nicht gerade sicher sondern nur eine Verdunkelung ... aber für die Masse der Möchtegerndatenabgreifer reicht es wohl.

                1. Hi,

                  das bringt mich wieder einmal zu der Frage, warum viele Web-APIs einen Key zur Nutzung brauchen, anstatt die Schnittstelle "offen" zu betreiben.

                  Weil die Betreiber (und sei es nur zur Überlastvermeidung) zwar eine API aber gerade keinen gänzlich freien Zugang schaffen wollen? Freilich sind die API-Keys an sich nicht gerade sicher sondern nur eine Verdunkelung ... aber für die Masse der Möchtegerndatenabgreifer reicht es wohl.

                  einen Teil der Möchtegerndatenabgreifer, nämlich die weniger Kreativen, vergrätzt man auf die Weise bestimmt. Aber ein Teil wird sich auch herausgefordert fühlen, die Webseite automatisiert abzurufen und zu parsen. Damit haben beide Seiten Nachteile: Der Anbieter wegen des höheren Transfervolumens (eine ganze HTML-Seite anstatt einer kleinen XML- oder JSON-Ressource), und der Nutzer, weil er ein mehr oder weniger aufwendiges Script entwickeln, testen und regelmäßig ausführen muss. Und das er sofort wieder überarbeiten muss, sobald der Anbieter die HTML-Struktur ändert.

                  Also unterm Strich kein wirklicher Nutzen.

                  Ciao,
                   Martin

                  --
                  Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
                  1. Nun, wenn ich die API nicht für Browser, sondern für Server bereitstelle, dann kann ich den API-Key an die IP des anfragenden Servers (= Client der API) binden.

                    Wenn ich die API für Browser (also Endutzer) bereit stelle, dann kann ich ein Login vorsehen und statt der Keys das Bestehen einer Session voraus setzen.

                    Beides bitte nur mit https…

              2. Hallo Martin,

                das bringt mich wieder einmal zu der Frage, warum viele Web-APIs einen Key zur Nutzung brauchen, anstatt die Schnittstelle "offen" zu betreiben. Wenn ich irgendwelche Daten über eine Webseite frei zugänglich mache, warum dann nicht auch inhaltlich gleich über die dazu passende API-Schnittstelle[^1]?

                um Daten zu sammeln. Und, wie z.B. Google Maps, irgendwann doch Geld zu verlangen.

                Gruß
                Jürgen

                1. Hallo Jürgen,

                  [...] warum dann nicht auch inhaltlich gleich über die dazu passende API-Schnittstelle?

                  um Daten zu sammeln. Und, wie z.B. Google Maps, irgendwann doch Geld zu verlangen.

                  Google Maps war jetzt ein schlechtes Beispiel, weil man einen Teil des Funktionsumfangs auch ganz gut über URL-Parameter steuern kann (Position auf der Karte, Zoomstufe, ein Marker). Für den Hausgebrauch ist das IMO völlig ausreichend, z.B. um einen Kartenausschnitt zu bookmarken oder in einem iframe einzubinden.
                  Ich weiß allerdings nicht, was die Google-Maps-API sonst noch für Möglichkeiten bietet.

                  Ciao,
                   Martin

                  --
                  Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
                  1. Ich weiß allerdings nicht, was die Google-Maps-API sonst noch für Möglichkeiten bietet.

                    Schöne:

                    https://home.fastix.org/Tests/adressen-verifizierung.php

                    Ach nee, das nutzt Openstreetmap.

          2. @@marctrix

            In einer echten HTML-Tabelle liegen doch strukturierte Daten vor, deren Beziehungen programmatisch ermittelbar sind.

            Vielleicht hat man die Daten ja auch nicht nur strukturell (HTML), sondern auch semantisch ausgezeichnet (RDFa). Dann liefert ein RDFa-Parser dasselbe wie ein JSON.

            Was jetzt nicht heißen soll, dass dies die bevorzugte Variante gegenüber über ein API[1] zu erhaltenes JSON wäre.

            LLAP 🖖

            --
            „Man kann sich halt nicht sicher sein“, sagt der Mann auf der Straße, „dass in einer Gruppe Flüchtlinge nicht auch Arschlöcher sind.“
            „Stimmt wohl“, sagt das Känguru, „aber immerhin kann man sich sicher sein, dass in einer Gruppe Rassisten nur Arschlöcher sind.“

            —Marc-Uwe Kling

            1. das API ↩︎

            1. Hallo Gunnar,

              einem Akronym ein Genus zuzuordnen, das aus einer Fremdsprache kommt, ist immer problematisch und oft umstritten. Mit welcher Begründung bestehst du hier auf das?

              Ja, wenn man das Wort Interface ausschreibt, bekommt es in einem deutschen Text normalerweise den sächlichen Artikel. Obwohl die Bedeutung übersetzt Schnittstelle ist, also weiblich.

              Ich halte daher in diesem Fall beides für richtig.

              Ciao,
               Martin

              --
              Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
              1. @@Der Martin

                Ja, wenn man das Wort Interface ausschreibt, bekommt es in einem deutschen Text normalerweise den sächlichen Artikel.

                Eben: das Interface – das API.

                Obwohl die Bedeutung übersetzt Schnittstelle ist, also weiblich.

                Dann heißt es aber nicht „die API“, sondern – wie du beiläufig, aber völlig richtig erwähntest – „die API-Schnittstelle“. 😆

                Und welche fadenscheinige Begründung hättest du für „die URL“ anzubieten? 😏

                LLAP 🖖

                --
                „Man kann sich halt nicht sicher sein“, sagt der Mann auf der Straße, „dass in einer Gruppe Flüchtlinge nicht auch Arschlöcher sind.“
                „Stimmt wohl“, sagt das Känguru, „aber immerhin kann man sich sicher sein, dass in einer Gruppe Rassisten nur Arschlöcher sind.“

                —Marc-Uwe Kling
                1. Hallo,

                  Und welche fadenscheinige Begründung hättest du für „die URL“ anzubieten? 😏

                  die Location

                  Ciao,
                   Martin

                  --
                  Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
                  1. @@Der Martin

                    Und welche fadenscheinige Begründung hättest du für „die URL“ anzubieten? 😏

                    die Location

                    Falsch. Das L in URL steht nicht für location.

                    Das hatten wir doch sicher schon mal …

                    LLAP 🖖

                    --
                    „Man kann sich halt nicht sicher sein“, sagt der Mann auf der Straße, „dass in einer Gruppe Flüchtlinge nicht auch Arschlöcher sind.“
                    „Stimmt wohl“, sagt das Känguru, „aber immerhin kann man sich sicher sein, dass in einer Gruppe Rassisten nur Arschlöcher sind.“

                    —Marc-Uwe Kling
                    1. Hi,

                      Und welche fadenscheinige Begründung hättest du für „die URL“ anzubieten? 😏

                      die Location

                      Falsch. Das L in URL steht nicht für location.

                      darüber gehen die Meinungen auseinander.

                      Das hatten wir doch sicher schon mal …

                      Hatten wir. Ich habe meine Meinung darüber aber seither nicht geändert.

                      Ciao,
                       Martin

                      --
                      Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
                    2. Dieser Beitrag wurde gelöscht: Der Beitrag ist außerhalb des durch dieses Forum abgedeckten Themenbereichs.
  2. Hallo Piet,

    ich würde auf Frames verzichten und die Daten mit einen Xmlhttprequest holen. Die Auswertung erfolgt dann mit String- oder nach dem Domparser mit den Dom-Methoden.

    Wenn die Daten von einer anderen Domain kommen, musst du dort den Cors-Header setzen (lassen).

    Gruß
    Jürgen

    1. Wenn die Daten von einer anderen Domain kommen, musst du dort den Cors-Header setzen (lassen).

      Wieso? Hat perl oder PHP weniger Rechte als ein Browser, Seiten abzurufen?

      Von PHP kenne ich das, das dem eigenen Server erlaubt werden muss, fremde Seiten zu lesen, irgendwas mit allow...

      Genauer: Auf fremde Ressourcen zuzugreifen, ich nutze eigene Datenbanken für unterschiedliche Domains.

      1. Hallo,

        Wenn die Daten von einer anderen Domain kommen, musst du dort den Cors-Header setzen (lassen).

        Wieso? Hat perl oder PHP weniger Rechte als ein Browser, Seiten abzurufen?

        nein, aber Javascript unterliegt Beschränkungen.

        Von PHP kenne ich das, das dem eigenen Server erlaubt werden muss, fremde Seiten zu lesen, irgendwas mit allow...

        Nicht dass ich wüsste.

        Genauer: Auf fremde Ressourcen zuzugreifen, ich nutze eigene Datenbanken für unterschiedliche Domains.

        Dann meinst du möglicherweise eine Beschränkung von mysql (nicht PHP), dass der Datenbank-Server in der Regel nicht von außen erreichbar ist.

        So long,
         Martin

        --
        Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
        1. ich erinnere mich, dass zwei Hoster allow_url_fopen für PHP genehmigen mussten, damit ich auf meine Datenbanken zugreifen konnte.

          Die Abrufer sind meine Domains, aber ich hatte keinen Zugriff auf die Innereien.

          1. Moin,

            ich erinnere mich, dass zwei Hoster allow_url_fopen für PHP genehmigen mussten, damit ich auf meine Datenbanken zugreifen konnte.

            das eine hat mit dem anderen nichts zu tun. Mit allow_url_fopen erlaubst du PHP nur, mit den Dateifunktionen auf Remote-Ressourcen zuzugreifen, also z.B. mit fopen() oder readfile() auf eine HTTP-Ressource einer anderen Domain.

            Mit der Datenbankanbindung hat das aber nichts zu tun.

            Die Abrufer sind meine Domains, aber ich hatte keinen Zugriff auf die Innereien.

            Ob du der Inhaber bist, ist zunächst mal nicht entscheidend; wichtiger ist eher die Tatsache, dass es ein Cross-Domain-Zugriff ist. Dass der aus Sicherheitsgründen nicht generell erlaubt ist, finde ich naheliegend.

            So long,
             Martin

            --
            Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
      2. Hallo

        Wenn die Daten von einer anderen Domain kommen, musst du dort den Cors-Header setzen (lassen).

        Wieso? Hat perl oder PHP weniger Rechte als ein Browser, Seiten abzurufen?

        Ein Xmlhttprequest läuft unter Javascript.

        Gruß
        Jürgen

        1. Moin,

          der Startbeitrag hat die Schlagworte HTML und Javascript, zusätzlich im Text die Bitte

          Eventuell gibt es auch eine ganz andere herangehensweise ??

          Bin für jeden Tip dankbar ...

          Ich wollte mit einem dankbaren Tip beitragen.

          Linuchs

    2. Hallo Piet,

      ich würde auf Frames verzichten und die Daten mit einen Xmlhttprequest holen. Die Auswertung erfolgt dann mit String- oder nach dem Domparser mit den Dom-Methoden.

      Wenn die Daten von einer anderen Domain kommen, musst du dort den Cors-Header setzen (lassen).

      Gruß
      Jürgen

      Hallo Jürgen,

      ... wirft etwas Fragezeichen auf 😀. Kannst Du das etwas mehr erklären. Die Domain ist unterschiedlich, aber kein Problem, alles in meiner Hand ;-)

      Gruß
      
      1. Hallo Piet,

        Ich bin gerade beim Sport. Wenn ich wieder zu Hause bin, sehe ich nach, wie ich das gemacht habe.

        Gruß
        Jürgen

      2. Hallo Piet,

        ich würde auf Frames verzichten und die Daten mit einen Xmlhttprequest holen. Die Auswertung erfolgt dann mit String- oder nach dem Domparser mit den Dom-Methoden.

        Wenn die Daten von einer anderen Domain kommen, musst du dort den Cors-Header setzen (lassen).

        ... wirft etwas Fragezeichen auf 😀. Kannst Du das etwas mehr erklären. Die Domain ist unterschiedlich, aber kein Problem, alles in meiner Hand ;-)

        ich habe jetzt meine alte .htaccess nicht mehr gefunden, aber ich habe folgende Zeile für die .htaccess in Erinnerung:

        Header set Access-Control-Allow-Origin '*'
        

        statt '*' kannst du auch die Domain einsetzen, die zugreifen darf. Siehe auch:

        https://developer.mozilla.org/de/docs/Web/HTTP/CORS/Errors/CORSFehltQuelleErlauben

        Gruß
        Jürgen

        1. Header set Access-Control-Allow-Origin '*'
          

          Um dann Wochen oder Jahrfünfte später festzustellen, dass eine andere I-Frame Ressource von einer anderen Webseite sich mehr oder weniger merkwürdige oder gar schädliche Späße erlaubt?

          Tut das nicht!

          1. Hallo,

            warum nicht, es geht doch um frei zugängliche Daten.

            Gruß
            Jürgen

            1. Header set Access-Control-Allow-Origin '*'
              

              Tut das nicht!

              warum nicht, es geht doch um frei zugängliche Daten.

              • Dummerweise ist dann 3 Klicks weiter auf Deiner Webseite eine Login-Seite mit, weils so schön bunt ist, einem genau für diese Seite beim Drittanbieter „moneyfornothing“ gebuchten Werbebanner für „chicks for free“ - welches "zufällig" Javascript enthält.
              • Dummwerweise haben plötzlich irgendwelche anderen Leute Admin-Rechte an Deinem CMS... und statt Matheaufgaben für die Kids gibt es KatzenTittenbilder...
              • Dummerweise bekommst Du merkwürdige Protestbriefe von #meetoo, dem Jugenschutzbeauftragten oder der Staatsanwaltschaft...
              1. Hallo,

                also etwas, was auf jedem Server für Messdaten installiert ist.

                Gruß
                Jürgen

          2. Header set Access-Control-Allow-Origin '*'
            

            Um dann Wochen oder Jahrfünfte später festzustellen, dass eine andere I-Frame Ressource von einer anderen Webseite sich mehr oder weniger merkwürdige oder gar schädliche Späße erlaubt?

            Tut das nicht!

            So isses! Und ganz dreiste Gesellen schicken einen dann eine Beschwerde wenn man sowas (z.B. eine DEMO) wieder abschaltet.

            MFG

      3. Hej piet,

        Die Domain ist unterschiedlich, aber kein Problem, alles in meiner Hand ;-)

        Dann scheinst du die Rechte an den Daten ja zu haben. Gut zu wissen! - Aber dann kannst du die doch auch direkt aus der DB ziehen?!?

        Marc

        --
        Ceterum censeo Google esse delendam
        1. Die Domain ist unterschiedlich, aber kein Problem, alles in meiner Hand ;-)

          Dann scheinst du die Rechte an den Daten ja zu haben. Gut zu wissen! - Aber dann kannst du die doch auch direkt aus der DB ziehen?!?

          1. Hallo,

            Dank an alle, für die Ansätze.

            1. Alle Daten und Server gehören mir/uns und ich kann/könnte machen was ich will. Es sind auch keine sensiblen Daten, eher Maschinendaten aus der Produktion, womit keiner etwas anfangen kann.

            2. iframe war nur meine erste Idee, was ich selbst nicht für elegant halte, aber es hat für den Anfang funktioniert.

            3. Bis jetzt waren alle Daten nur für den Benutzer reserviert, der sich angemeldet/eingeloggt hat. Das System ist über die Jahre immer gewachsen und es war bis jetzt nie eine Anforderung von einer fremden Domain Daten zu holen.

            4. Aktuell sollen ein paar Daten auch für jedermann zugänglich sein, ohne sich aber anzumelden.

            5. Wie ich das mache ist egal, es sollte natürlich zukunftsträchtig und keine Insellösung sein.

            6. Wie Daten/Webseiten die öffentlich sind, habe ich im Verzeichnis /srv/www/htdocs/public/ stehen, das ich im Apache2 auch gezielt freigegeben habe.

            7. Jetzt bin ich dabei ein cgi-script auf dem Server zu schreiben, das ich von "ferne" per Webseite und ajax starte, das wiederum mir die benötigten Daten zurück liefert. Wenn ich aber das cgi-script im Verzeichnis /srv/www/htdocs/public/ kopiere, kommt ein Zugriffsfehler, sobald ich es ausserhalb der Domain starte. Ich muss vermutlich auch das cgi-script irgendwie "freigeben" damit ich von einer fremden Domain das Script startenn kann um Daten zu lesen.

            Ihr liefert alle gute Argumente, leider sind aber alle Ansätze meist/komplett unterschiedlich. Hier fehlt mir die Erfahrung das "Beste" herauszufinden. Dabei bin ich aber für jede Schandtat bereit 😉

            Ich hoffe ich habe etwas Licht ins dunkele gebracht ;-)

            Danke

            1. eher Maschinendaten aus der Produktion, womit keiner etwas anfangen kann.

              • Dachten die Jungs einer Firma - bis der Iran anfing selbst anfing, Maschinen zu bauen mit denen man Uran waffenfähige oder nur schwere Isotope auftrennen kann.
              • Dachten die Jungs in einer Firma, bis der Materiallieferant an Hand der Daten die Qualität seines Materials so lange „optimierte“ bis die Produkte der Firma genau den Herstellungsprozess überstanden.
  3. Hello,

    das bringt mich ganz nebenbei auf die Frage:

    kann man eigentlich eine Variable im Response-Header übertragen?

    Die müsste doch als "X-Header" unterzubringen sein, oder?

    Damit könnten sich dann viele Webseiten zusätzliche RSS-Feeds oder APIs ersparen. Der fremde Webserver schaut einfach nach, ob die Variable im Header gesetzt ist und gut ists. Parsen der Seite entfällt, und damit auch die Notwendigkeit, den gesamten Page-Content zu übertragen. Ein Head-Request genügt dann.

    Ist das jetzt eine doofe Idee, oder wird das sowieso schon so gemacht?

    Glück Auf
    Tom vom Berg

    --
    Es gibt nichts Gutes, außer man tut es!
    Das Leben selbst ist der Sinn.
    1. Lieber TS,

      Ist das jetzt eine doofe Idee, oder wird das sowieso schon so gemacht?

      HTTP-Header transportieren Meta-Daten, die den Transport selbst betreffen. HTTP eben. Du willst nun Nutzdaten in die Metadaten einschleusen. Ich empfinde das tatsächlich als eine doofe Idee.

      Liebe Grüße

      Felix Riesterer

      1. Hallo

        Ist das jetzt eine doofe Idee, oder wird das sowieso schon so gemacht?

        HTTP-Header transportieren Meta-Daten, die den Transport selbst betreffen. HTTP eben. Du willst nun Nutzdaten in die Metadaten einschleusen. Ich empfinde das tatsächlich als eine doofe Idee.

        … zumal dann, wenn @TS einen RSS-Feed-Ersatz andenkt. Das können ja schon mal einige hundert bis tausend Kilobyte sein. Wer soll die überhaupt mit welcher Software lesen?

        Tschö, Auge

        --
        Ein echtes Alchimistenlabor musste voll mit Glasgefäßen sein, die so aussahen, als wären sie beim öffentlichen Schluckaufwettbewerb der Glasbläsergilde entstanden.
        Hohle Köpfe von Terry Pratchett
        1. Hello,

          Hallo

          Ist das jetzt eine doofe Idee, oder wird das sowieso schon so gemacht?

          HTTP-Header transportieren Meta-Daten, die den Transport selbst betreffen. HTTP eben. Du willst nun Nutzdaten in die Metadaten einschleusen. Ich empfinde das tatsächlich als eine doofe Idee.

          … zumal dann, wenn @TS einen RSS-Feed-Ersatz andenkt. Das können ja schon mal einige hundert bis tausend Kilobyte sein. Wer soll die überhaupt mit welcher Software lesen?

          Lesen sollen das andere Server.

          Ein Cookie-Header kann auch mindestens 4096 Bytes übertragen. Wieso sollte dies ein X-Header dann nicht können?

          Und wenn die Daten nur beim Head-Request eingefügt werden, belasten sie die normalen Requests auch nicht. Der Vorteil wäre, dass Browser diese Header sowieso nicht anzeigen würden. Rohdaten gäbe es also nur für Server.

          Glück Auf
          Tom vom Berg

          --
          Es gibt nichts Gutes, außer man tut es!
          Das Leben selbst ist der Sinn.
          1. Hallo

            Ist das jetzt eine doofe Idee, oder wird das sowieso schon so gemacht?

            HTTP-Header transportieren Meta-Daten, die den Transport selbst betreffen. HTTP eben. Du willst nun Nutzdaten in die Metadaten einschleusen. Ich empfinde das tatsächlich als eine doofe Idee.

            … zumal dann, wenn @TS einen RSS-Feed-Ersatz andenkt. Das können ja schon mal einige hundert bis tausend Kilobyte sein. Wer soll die überhaupt mit welcher Software lesen?

            Lesen sollen das andere Server.

            Also braucht der eine neue Software, die mit diesen Nutzdaten etwas anfangen kann. Ansonsten werden hier für nichts und wieder nichts unnötig Daten übertragen.

            Ein Cookie-Header kann auch mindestens 4096 Bytes übertragen. Wieso sollte dies ein X-Header dann nicht können?

            Schlechter Vergleich. Ich sprach nicht von den 4 Kilobytes eines Cookies sondern von den hundert(en) bis tausend(en) Kilobytes, die ein RSS-Feed haben kann. Das sind Größenordnungen mehr.

            Und wenn die Daten nur beim Head-Request eingefügt werden, belasten sie die normalen Requests auch nicht. Der Vorteil wäre, dass Browser diese Header sowieso nicht anzeigen würden. Rohdaten gäbe es also nur für Server.

            Die erst einmal wissen müssten, dass sie auf diesem dafür überhaupt nicht gedachten Weg Daten zu lesen haben. Das ist von hinten durchs Knie ins Auge. Außerdem, warum willst du „normale Requests“ entlasten, die doch genau dafür da sind, Daten zu erfragen und stattdessen die Daten auf einem dafür nicht vorgesehenen Weg ausliefern? Zudem auch an Browser, die nun Daten erhalten, die sie, wie du richtig sagtest, nicht anzeigen, die sie aber auch überhaupt nicht brauchen.

            Ist dir der „normale“ Weg, das über eine API zu erledigen, bei der man explizit die Daten, die man braucht, erfragt, zu normal?

            Tschö, Auge

            --
            Ein echtes Alchimistenlabor musste voll mit Glasgefäßen sein, die so aussahen, als wären sie beim öffentlichen Schluckaufwettbewerb der Glasbläsergilde entstanden.
            Hohle Köpfe von Terry Pratchett
            1. Lieber Auge,

              Ist dir der „normale“ Weg, das über eine API zu erledigen, bei der man explizit die Daten, die man braucht, erfragt, zu normal?

              Es fällt mir immer wieder auf, dass Du ungenau liest, was Andere posten und sofort gegenhältst. Diskussion ist gut, aber Du solltest dabei neutral formulieren und nicht immer gleich persönlich werden.

              Spirituelle Grüße
              Euer Robert

              --
              Möge der Forumsgeist ewig leben!
              1. Hallo

                Ist dir der „normale“ Weg, das über eine API zu erledigen, bei der man explizit die Daten, die man braucht, erfragt, zu normal?

                Es fällt mir immer wieder auf, dass Du ungenau liest, was Andere posten und sofort gegenhältst. Diskussion ist gut, aber Du solltest dabei neutral formulieren und nicht immer gleich persönlich werden.

                Ist die Frage, ob ein üblicher Weg für jemanden, der einen unüblichen Weg vorschlägt, zu normal ist, persönlich?

                Meine Frage mag ja zugespitzt sein, aber ich sehe keinen Grund, sie nicht ganz ernsthaft zu stellen. TS stellt eine Frage zu einem hypothetischen Vorgehen in den Raum. Schon Felix findet das Ansinnen als falsche Herangehensweise. Ich stelle daraufhin auf einen bestimmten Aspekt, nämlich die Übertragung von möglicherweise großen Datenmengen in HTTP-Headern, ab und finde die Idee, das auf diesem Wege mache zu wollen, obwohl es dafür andere, etablierte Wege gibt, fragwürdig.

                Für TS ist es augenscheinlich hinnehmbar, dass im Header der Antwort auf einen Request Daten (nach seiner Idee bis hin zu RSS-Feeds) gesendet werden, die ein Großteil der Clients nicht auswerten kann und soll, die aber Traffic verursachen, statt dafür die vorhandenen Wege zu benutzen. Für mich ist es das nicht.

                Und ja, da stelle ich mir die Frage, warum TS solche Ideen wälzt.

                Tschö, Auge

                --
                Ein echtes Alchimistenlabor musste voll mit Glasgefäßen sein, die so aussahen, als wären sie beim öffentlichen Schluckaufwettbewerb der Glasbläsergilde entstanden.
                Hohle Köpfe von Terry Pratchett
      2. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

        Ist das jetzt eine doofe Idee, oder wird das sowieso schon so gemacht?

        HTTP-Header transportieren Meta-Daten, die den Transport selbst betreffen. HTTP eben. Du willst nun Nutzdaten in die Metadaten einschleusen. Ich empfinde das tatsächlich als eine doofe Idee.

        Kann ich das irgendwo nachlesen, dass in HTTP-Headern keine Daten übermitelt werden dürfen?

        Man muss sich wohl freimachen von der Vorstellung, dass Requests immer nur von Browsern abgesendet werden. Der Client kann hier aber ebensogut ein Syndication-Server sein.

        Spirituelle Grüße
        Euer Robert

        --
        Möge der Forumsgeist ewig leben!
        1. Lieber robertroth,

          Kann ich das irgendwo nachlesen, dass in HTTP-Headern keine Daten übermitelt werden dürfen?

          dürfen habe ich nie verneint. Ich habe nur die Sinnhaftigkeit infrage gestellt.

          Man muss sich wohl freimachen von der Vorstellung, dass Requests immer nur von Browsern abgesendet werden. Der Client kann hier aber ebensogut ein Syndication-Server sein.

          Man muss sich im Klaren darüber sein, dass hier ein etabliertes Protokoll zum Einsatz kommt, das zwischen Nutzdaten und Metadaten unterscheidet. Man kann prinzipiell alles Mögliche damit anstellen. Ebenso kann man sein Wohnzimmer auch mit den Abgasen des in der Garage laufenden Autos heizen. Machbar ist das alles. Es stellt sich aber die Frage nach dem Sinn. Und nicht nach dem Client. HTTP will nichts über den Client wissen. Das kommuniziert der via Accept-Header. Und eventuell mit dem User-Agent-Header.

          Liebe Grüße

          Felix Riesterer

    2. Selbsverständlich kann man das.

      X-Header

      Das nennt sich Custom'Header und da kann man ne ganze Menge damit machen. Zeichenkodierung ist beliebig, zu beachten ist lediglich, daß keine Zeilenumbrüche drin sind, falls doch sind diese zu kodieren (Prozentkodierung).

      MFG

    3. Lieber TS,

      ich finde die Idee gut. Die Einwände, die hier kommen, kann ich nicht teilen.

      Und da Browser im Normalbetrieb auch keine Head-Requests absetzen, dürfte das Argument von Auge auch nicht ziehen, dass der normale Request mit zusätzlichen Headern belastet würde. Du willst die Custom-Header ja nur beim Headrequest einfügen.

      Ich würde jetzt noch einen Schritt weitergehen:

      Füge beim Request (von Server zu Server) auch einen X-Header ein, der die passende Antwort erbittet. Dann könnte man sogar Daten und Format trennen. Die Daten werden in den Custom-Headern übermittelt und das Format (HTML) im Body mit passenden Platzhaltern ausgeliefert. Der requestende Server kann so ganz bequem entscheiden, ob er die Originaldaten oder seine einfügt und zB. bei Syndication ganz einfach das Corporate Design waren.

      Ich glaube, Du hast mir mit deiner Idee für eines meiner Projekte gerade viel Arbeit erspart. Ich muss das noch etwas durchentwickeln, aber ich werde die Idee aufgreifen :-)

      Die Sache mit der erforderlichen Kodierung und Rückkodierung muss ich mir noch genauer ansehen.

      Spirituelle Grüße
      Dein Robert

      --
      Möge der Forumsgeist ewig leben!
      1. problematische Seite

        Die Sache mit der erforderlichen Kodierung und Rückkodierung muss ich mir noch genauer ansehen.

        echo http_build_query( array(
            'foo'  => 'bar',
            'name' => 'boo',
            'amt'  => '€ 2.59'
        ) );
        
        foo=bar&name=boo&amt=%E2%82%AC+2.59
        

        MFG

    4. kann man eigentlich eine Variable im Response-Header übertragen?

      Die müsste doch als "X-Header" unterzubringen sein, oder?

      Ja. Wir nutzen das primär für den Informationsaustausch der eigentlichen Worker-Backends und den vorgeschalteten Proxys / Loadbalancern.

    5. Hallo Tom,

      ich muss mich da Felix anschließen - das ist keine gute Idee. Ich will sie nicht „doof“ nennen, das wäre sie dann, wenn man es schon 3x erklärt hätte und du immer noch drauf rumreiten würdest (ohne gute Argumente dafür zu haben).

      Es geht nicht um die technischen Möglichkeiten. Natürlich kannst Du rein technisch die Response mit X-Foo-Data-001,-002,... Headern volldonnern. Nur - wenn man ein konkretes Protokoll verwendet, dann sollte man auch den Ideen folgen, die dieses Protokoll verwirklicht.

      Content gehört in den Body, und es ist völlig ok, wenn eine Seite ihren Content je nach Request in unterschiedlichen Formaten darstellt.

      Hier bieten sich tatsächlich Header an: und zwar der Request Header. Wenn eine Infoseite ihren Inhalt für Browser als HTML, für RSS-Feedreader als RSS-Feed und für API Requests als JSON-Objekt ausgeben kann, dann sollte sie den Accept-Header auswerten.

      Feedreader (RSS oder Atom) - ich nehme es zumindest mal an, ich habe selbst keinen:

      Accept: application/rss+xml
      Accept: application/atom+xml
      

      Ein XMLHttpRequest setzt einen anderen Accept-Header:

      Accept: application/json
      

      Und wenn's das nicht ist, dann geht man von einem Browser aus. Oder sucht in Strings wie dem Folgenden (Chrome, gekürzt) nach text/html:

      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*
      

      Der Server kann dann mit dem gleichen Content-Type (oder eben text/html) antworten.

      Man braucht da weder Query-Parameter noch geheimen Datentransfer in X-Response-Headern.

      RDFa ist was anderes, hat auch meiner Meinung nach einen anderen Daseinszweck. Wenn ich Daten in einem CMS anbiete und redaktionell pflege, dann ist es sinnvoll, die Daten vom Autor semantisch aufbereiten zu lassen. Für strukturierte Daten, die ohnehin in generiertem HTML repräsentiert werden, baut man besser unterschiedliche Renderer.

      Rolf

      --
      sumpsi - posui - clusi
      1. Danke für den Hinweis zum Accept'Header!

        Und wenn's das nicht ist, dann geht man von einem Browser aus. Oder sucht in Strings wie dem Folgenden (Chrome, gekürzt) nach text/html:

        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*
        

        Der Server kann dann mit dem gleichen Content-Type (oder eben text/html) antworten.

        Man braucht da weder Query-Parameter noch geheimen Datentransfer in X-Response-Headern.

        Schönes Beispiel: Weil es schlecht ist. Wenn man nämlich am Server anhand dieses Header's entscheiden will welcher Content'Type in der Response zu senden ist, darf der Accept'Header nicht mehrere Angaben liefern sondern nur genau eine.

        MFG

        1. Hallo pl,

          Wenn man nämlich am Server anhand dieses Header's entscheiden will welcher Content'Type in der Response zu senden ist, darf der Accept'Header nicht mehrere Angaben liefern sondern nur genau eine.

          Jein. Wenn ich als Client unbedingt ein bestimmtes Format haben will, dann muss ich natürlich auch einen eindeutigen Accept Header schicken. Wenn ich mehrere Formate verstehe, dann darf ich mehr schicken. Allgemein ist Accept ja eine Wunschliste. Der Server liest die Wunschliste durch und liefert den Wunsch, den er am besten erfüllen kann.

          Ein Client, der unbedingt einen Atom-Feed haben will, sendet

          Accept: application/atom+xml

          Ein Client, der einen Feed haben will, egal ob Atom oder RSS, sendet

          Accept: application/rss+xml,application/atom+xml

          und der Server sucht sich was davon aus (auf den q-Parameter gehe ich jetzt nicht ein).

          Ein Browser kann eine Menge verstehen und schickt darum eine längere Liste. Der Server findet darin text/html und schickt die HTML-Version der Ressource. Wenn er das nicht findet, gibt's eine Menge RfCs, die dazu was erzählen, darauf gehe ich jetzt auch nicht ein.

          Rolf

          --
          sumpsi - posui - clusi
          1. Ein Browser kann eine Menge verstehen und schickt darum eine längere Liste. Der Server findet darin text/html und schickt die HTML-Version der Ressource.

            Interessant wäre mal eine Recherche welche der einschlägig bekannten Webframeworks auf diesen Accept'Header eingehen den sie in der Umgebungsvariablen HTTP_ACCEPT bekommen.

            Mein FW arbeitet schon immer damit und fragt bei jedem Request einen bestimmten Wert für diesen Header ab.

            Deswegen schrieb ich ja: Danke für Deinen Hinweis auf den Accept'Header.

    6. das bringt mich ganz nebenbei auf die Frage:

      kann man eigentlich eine Variable im Response-Header übertragen?

      Die müsste doch als "X-Header" unterzubringen sein, oder?

      Irgendwo müsste ja die Syntax und Semantik der benutzerdefinierten Header wieder spezifiziert werden, damit die Kommunikationspartner sich gegenseitig verstehen. Es braucht also ein zusätzliches Protokoll, das auf HTTP aufsetzt. Wenn du in dem Protokoll Metadaten untersützen willst, die die Interpretation des Inhalts steuern, wie Caching, musst du ein redudantes Caching-System erschaffen, weil das HTTP-Caching-System den Message-Body steuert, nicht die Header. Ähnliches gilt für Mehrsprachigkeit, Streaming-Fähigkeit, Status-Codes etc. pp. All das bringt HTTP bereits mit.

      Mir ist auch nicht klar, welches Problem du damit zu lösen gedenkst. Oder war das eine reine informative Frage? Dann lautet die Antwort: Technisch möglich, aber nicht unbedingt sinnvoll.

      btw: Die Verwendung des X-Prefix wird inzwischen missbilligt.

    7. kann man eigentlich eine Variable im Response-Header übertragen?

      Blos nicht!

      1. Dann nimm lieber ein verstecktes HTML-Element und schreib das Zeug da rein.

      2. Du kannst Daten auch direkt in und für JS formulieren:

      <script>
      var data=JSON.parse('<?=json_encode( $array );?>');
      </script>`
      
      1. Beides kann man leicht raussuchen und verarbeiten (ideal für JS in der Seite), das Schreiben in den Header ist dagegen (siehe UPs Antwort) unerhört suboptimal, normfern, stressverursachend - und missbilligt.

      2. Man wird es dennoch vermeiden, immer Daten und Webseite zu senden, wenn je nach Request eigentlich nur die Webseite oder die Daten gefragt sind.