Robert R.: Welchen HTTP-Status senden?

0 59

Welchen HTTP-Status senden?

Robert R.
  • https
  1. 0
    Der Martin
  2. 0
    hotti
    1. 2
      1UnitedPower
      1. 0
        hotti
        1. 0
          Sven Rautenberg
          1. 0
            hotti
            1. 0
              ChrisB
              1. 0
                hotti
                1. 0
                  ChrisB
        2. 2
          1UnitedPower
      2. 0
        hotti
        1. 0

          What was the question?

          Camping_RIDER
          • zur info
        2. 1
          1UnitedPower
      3. 0
        Robert R.
        1. 0
          bubble
        2. 0
          Camping_RIDER
          1. 0
            Robert R.
          2. 0
            bubble
            1. 0
              Camping_RIDER
              1. 1
                Camping_RIDER
  3. 0
    Baba
    1. 0
      Camping_RIDER
  4. 0
    M.
    1. 0
      Robert R.
      1. 0
        bubble
      2. 0
        Auge
    2. 2
      suit
      1. 0
        Auge
        1. 0
          suit
          1. 0

            Auf den <img>-Request mit Content-Type text/html antworten...

            Robert R.
            1. 0
              Der Martin
              1. 0
                Robert R.
                1. 0
                  Camping_RIDER
                  1. 0
                    Robert R.
                    1. 0
                      Camping_RIDER
                      1. 0
                        Der Martin
                        1. 0
                          Camping_RIDER
                          1. 0
                            Auge
                            1. 0
                              Camping_RIDER
                              1. 0
                                Auge
                                1. 0
                                  Camping_RIDER
                                  1. 0
                                    Auge
                                    1. 0
                                      Camping_RIDER
                                  2. 0
                                    Robert R.
                                2. 0
                                  Mitleser
            2. 0
              Camping_RIDER
      2. 0
        M.
        1. 0
          Camping_RIDER
          • meinung
          1. 0
            M.
            1. 0
              Camping_RIDER
            2. 0
              Der Martin
              1. 0
                M.
                1. 0
                  Camping_RIDER
                  1. 0
                    Auge
                    1. 0
                      Camping_RIDER
                      1. 0
                        Auge
                        1. 0
                          Camping_RIDER
  5. 1
    bubble

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Welchen HTTP-Status sollte man benutzen, wenn die Ressource zwar vorhanden ist, aber ohne Authentifizierung nicht zur Verfügung steht.

404 Not Found -> ist flasch, weil es sie ja gibt
401 Unauthorized -> falsch, weil das Basic Auth ist und der Browser dann das Fenster aufklappt.

403 Forbidden -> erscheint mir noch am sinnvollsten. Aber was machen die Suchmaschinen dann mit einer solchen Antwort?

Und eine Ersatzseite soll man doch nicht senden, oder? Das wäre dann wieder "Soft 404".

Spirituelle Grüße
Euer Robert

--
Möge der Forumsgeist wiederbelebt werden!
  1. Moin,

    Welchen HTTP-Status sollte man benutzen, wenn die Ressource zwar vorhanden ist, aber ohne Authentifizierung nicht zur Verfügung steht.

    404 Not Found -> ist flasch, weil es sie ja gibt
    401 Unauthorized -> falsch, weil das Basic Auth ist und der Browser dann das Fenster aufklappt.
    403 Forbidden -> erscheint mir noch am sinnvollsten. Aber was machen die Suchmaschinen dann mit einer solchen Antwort?

    ich verstehe deine Gedanken nicht so ganz. Aus meiner Sicht ist 401 genau richtig, und das ist auch der übliche Fall. Das sagt dem Client deutlich, was Sache ist, und ja, der Browser reagiert darauf im Normalfall, indem er das Fenster zur Eingabe der Zugangsdaten anzeigt. Bricht der Nutzer diese Eingabe ab, wird der Inhalt angezeigt, der mit dem 401-Header gesendet wurde (sonst normalerweise nicht). Das ist dann in der Regel ein Ausdruck des Bedauerns, oder eventuell ein Ersatz-Inhalt für nicht authentifizierte Nutzer.

    Und auch Suchmaschinen erkennen so: Ja, da gibt's Inhalt, aber nicht für jeden.

    Ciao,
     Martin

    --
    Man gewöhnt sich an allem, sogar am Dativ.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
  2. Liebe Mitdenker,
    liebe Wissende,
    liebe Neugierige,

    ja!

    Welchen HTTP-Status sollte man benutzen, wenn die Ressource zwar vorhanden ist, aber ohne Authentifizierung nicht zur Verfügung steht.

    404 Not Found -> ist flasch, weil es sie ja gibt

    Warum sollte es die Ressource geben, für einen der sich nicht authentifiziert hat und nicht autorisiert ist? Wenn Dein Konzept vorsehen würde, dass bestimmte Ressourcen nur authentifizierten Benutzern zur Verfügung stehen, wäre 404 absolut korrekt.

    MFG

    1. Hakuna matata!

      Warum sollte es die Ressource geben, für einen der sich nicht authentifiziert hat und nicht autorisiert ist?

      Das ist ein Denkfehler. Die bloße Existenz einer Ressource hängt nicht davon ab, ob sie gesehen werden kann oder nicht. Nordkorea existiert, auch wenn ich keine Einreisegenehmigung erhalte. Genauso verursacht der umfallende Baum im Wald Schallwellen, auch wenn diese von niemanden gehört werden.

      Es hat aber auch einen praktischen Nutzen, hier den aussagekräftigeren 401-Status-Code anstatt 404 zu benutzen: Angenommen ein Arbeitskollege schickt mir einen Link zu einer unserer Kundenseiten, und ich bekomme nur eine 404-Seite zu sehen, dann würde ich meinem Kollegen die Rückmeldung geben, dass er mir einen kaputten Link geschickt hat. Dann würden wir uns eine Weile darüber wundern, wieso der Link bei ihm funktioniert und bei mir nicht. Irgendwann stoßen wir vielleicht auf die Ursache, dass man eingeloggt sein muss, um die Ressource sehen zu können. Eine 401-Fehlermeldung hätte uns schneller auf den richtigen Dampfer gebracht.

      --
      “All right, then, I'll go to hell.” – Huck Finn
      1. Hakuna matata!

        Warum sollte es die Ressource geben, für einen der sich nicht authentifiziert hat und nicht autorisiert ist?

        Das ist ein Denkfehler. Die bloße Existenz einer Ressource hängt nicht davon ab, ob sie gesehen werden kann oder nicht. Nordkorea existiert, auch wenn ich keine Einreisegenehmigung erhalte. Genauso verursacht der umfallende Baum im Wald Schallwellen, auch wenn diese von niemanden gehört werden.

        Dein Vergleich hinkt. Wenn URLs geroutet werden, existiert eine Ressource nur, wenn sie in der Routing-Table steht. Das ist die Verbindlichkeit: Wenn Korea nicht im Fahrplan steht, fährt da auch kein Zug dahin.

        Es gibt aber noch eine Sache und die ist richtig böse: Content-Negotiation. D.h., Benutzer der Gruppe 'dogs' sehen auf der Ressource /animals nur Schafe, nicht angemeldete Benutzer hingegen sehen Kühe.

        In beiden Fällen liefert ein Request auf /animals den Status 200. Was sonst.

        MfG

        1. Moin!

          Dein Vergleich hinkt. Wenn URLs geroutet werden, existiert eine Ressource nur, wenn sie in der Routing-Table steht. Das ist die Verbindlichkeit: Wenn Korea nicht im Fahrplan steht, fährt da auch kein Zug dahin.

          404 ist gerechtfertigt, wenn keinerlei Request existiert, der eine Ressource unter der gegebenen URL abrufen könnte.

          Es gibt aber noch eine Sache und die ist richtig böse: Content-Negotiation. D.h., Benutzer der Gruppe 'dogs' sehen auf der Ressource /animals nur Schafe, nicht angemeldete Benutzer hingegen sehen Kühe.

          In beiden Fällen liefert ein Request auf /animals den Status 200. Was sonst.

          Nicht zwingend. Wenn "Accept: image/x-schafe" vom Server nicht erfüllt werden kann, wird er eventuell Status "406 Not Acceptable" zurücksenden.

          Wobei sich das ja ausschließlich auf die technische Erscheinungsform bezieht, nicht auf den Inhalt.

          - Sven Rautenberg

          1. Moin!

            Wobei sich das ja ausschließlich auf die technische Erscheinungsform bezieht, nicht auf den Inhalt.

            Zum besseren Verständnis: Content Negotiation by User

            Einloggen hier
            Benutzer: xf
            Passwort: xf

            Du siehst dann auf rolfrost.de/ dem xf sein Forum.

            Ein anderer Benutzer
            Benutzer: xforum
            Passwort: xforum

            sieht auf demselben URL ein anderes Forum. Nicht angemeldete Benutzer sehen auf diesem URL meine Startseite.

            Ich könnte dem xf sein Forum auch auf /xf.html unterbringen, Das Forum für Benutzer xforum auf /xforum.htm usw. Klar, kann ich machen, hätte dann evntl. wieder neue Abhängigkeiten und hätte den Path /xforum.html möglicherweise auch gar nicht in der Routing-Table für nicht angemeldete Benutzer (Status 404).

            Ergo: Es ist eine Frage der Organisation. Feilich kann das jeder machen wie er will.

            MfG

            1. Hi,

              Zum besseren Verständnis: Content Negotiation by User

              Einloggen hier
              Benutzer: xf
              Passwort: xf

              Du siehst dann auf rolfrost.de/ dem xf sein Forum.

              Ein anderer Benutzer
              Benutzer: xforum
              Passwort: xforum

              sieht auf demselben URL ein anderes Forum. Nicht angemeldete Benutzer sehen auf diesem URL meine Startseite.

              Und Nutzer, die sich in beiden Foren anmelden wollen? (Nicht unbedingt gleichzeitig, meinetwegen auch nacheinander.)

              Ich könnte dem xf sein Forum auch auf /xf.html unterbringen, Das Forum für Benutzer xforum auf /xforum.htm usw. Klar, kann ich machen, hätte dann evntl. wieder neue Abhängigkeiten und hätte den Path /xforum.html möglicherweise auch gar nicht in der Routing-Table für nicht angemeldete Benutzer (Status 404).

              Ergo: Es ist eine Frage der Organisation.

              Ja. Deine scheint fehlerhaft zu sein.

              MfG ChrisB

              --
              Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/
              1. Hi,

                Ich könnte dem xf sein Forum auch auf /xf.html unterbringen, Das Forum für Benutzer xforum auf /xforum.htm usw. Klar, kann ich machen, hätte dann evntl. wieder neue Abhängigkeiten und hätte den Path /xforum.html möglicherweise auch gar nicht in der Routing-Table für nicht angemeldete Benutzer (Status 404).

                Ergo: Es ist eine Frage der Organisation.

                Ja. Deine scheint fehlerhaft zu sein.

                Scheinbar verstehst Du nicht, was mit Content-Negotiation (außer der in RFC beschriebenen Lang.N.) alles möglich ist. Hier noch ein paar Beispiele ohne Anspruch auf Vollständigkeit:

                1. Multi-User-Betrieb, Anwendungen werden mandantenfähig,
                2. Multi-Domain-Betrieb, wenn mehrere Domains auf einem Host betrieben werden, werden deren Inhalte abhängig vom DN über einunddasselbe Framework ausgeliefert, zentrale Softwareverteilung und -Updates,
                3. Staging: Software-Tests auf dem Produktivsystem ohne dass der Produktionsbetrieb beeinträchtigt wird; z.B. kann ein spezieller User die Bestellung mit einem Warenkorb testen, ohne dass Test-Daten in produktiven Datenbanken anfallen: Auf demselben URL wie der Life-Shop.

                Weniger Code, weniger Redundanzen, mehr Effizienz. Zu (1) kannst Du bspw. damit für jeden Kunden (oder Gruppe) ein eigenes Backend zusammenstellen (mehrere Anwendungen), ganz nach Kundenwunsch und das zu Festpreisen.

                MfG

                1. Hi,

                  Scheinbar verstehst Du nicht, was mit Content-Negotiation (außer der in RFC beschriebenen Lang.N.) alles möglich ist.

                  Doch, das verstehe ich sehr gut.

                  Du hast aber offenbar meinen Einwand nicht verstanden.

                  MfG ChrisB

                  --
                  Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/
        2. Hakuna matata!

          Dein Vergleich hinkt.

          Das kommt vor, daurm will ich mich auch nicht weiter mit Vergleichen aufhalten.

          Wenn URLs geroutet werden, existiert eine Ressource nur, wenn sie in der Routing-Table steht.

          Website-URLs werden vom Webserver immer in irgendeiner Weise geroutet. Das kann ein ganz effes statisches Routing sein, das URLs auf Dateipfade mapt, oder auch ein völlig dynamisches Routing, welches den Routing-Prozess an entsprechende Middelware delegiert. Eine Routingtabelle ist in der Webentwicklung ungebräuchlich, ich kann mir nur schwer vorstellen, was du dir darunter vorstellst.

          Aber, wie das Routing letztlich auch implementiert ist, ist dem Webseiten-Nutzer ziemlich egal. Er hat eine Erwartung, wie sich Links zu verhalten haben, wenn er ihnen folgt: Entweder er landet da, wo er es beabsichtigt hat, oder er bekommt eine Erklärung serviert, wieso er nicht da gelandet ist, wo er hin wollte. Und diese Meldung sollte möglichst selbsterklärend sein. Zutreffendes ist angekreuzt:

          [ ] "Hörens, die Seite, die Sie aufrufen wollten, steht hier aber nicht in der Routingtabelle".
          [x] "Hörens, ich hätte hier eine Seite für Sie, aber dafür müssen Sie mir erstmal zeigen, dass Sie auch den nötigen Rechte besitzen. Möchten Sie sich vielleicht mal endlich einloggen?"

          --
          “All right, then, I'll go to hell.” – Huck Finn
      2. Hakuna matata!

        Es hat aber auch einen praktischen Nutzen, hier den aussagekräftigeren 401-Status-Code anstatt 404 zu benutzen: Angenommen ein Arbeitskollege schickt mir einen Link zu einer unserer Kundenseiten,

        Als Kunde würde ich sowas nicht haben wollen, dass mein Backend verlinkt werden kann. Das schafft kein Vertrauen, daran würde auch ein Status 401 nichts verbessern, den ein Anderer, nicht autorisierter Benutzer bekommen würde, wenn er MEIN Backend aufruft.

        Irgendwann stoßen wir vielleicht auf die Ursache, dass man eingeloggt sein muss, um die Ressource sehen zu können.

        Wer hätte das gedacht: Man muss eingeloggt sein, dass man die Seite genauso sieht wie der Kunde ;)

        Eine 401-Fehlermeldung hätte uns schneller auf den richtigen Dampfer gebracht.

        Einem Kunden ists egal, wie IHR EURE interne Kommunikation abwickelt. Ein Kunde schenkt seinem Provider Vertrauen, weil er davon ausgeht, dass sein Backend (seine Kundenseite) nur von ihm selbst, mit seinen ganz persönlichen Zugangsdaten, aufgerufen werden kann.

        MfG

        1. Aloha ;)

          Aus irgendeinem Grund habe ich hier wieder das Gefühl, dass beide Seiten auf ihre Art und Weise je Recht haben, aber aus unerfindlichen Gründen (Scheuklappen?) vollkommen aneinander vorbeireden. Wer auch immer wen falsch verstanden hat müsst ihr untereinander ausmachen, ich komm inhaltlich wenigstens nicht mehr mit :D

          Grüße,

          RIDER

          --
          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
          ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
        2. Hakuna matata!

          Als Kunde würde ich sowas nicht haben wollen, dass mein Backend verlinkt werden kann.

          Von Backend und Fronend war bisher gar nicht die Rede, da interpetierst du irgendwas in meine Aussagen, worauf ich gar nicht hinaus wollte. Aber auch ein Backend sollte meiner Meinung nach bookmarkable (gibt es dafür ein schönes deutsches Wort?) sein.

          Das schafft kein Vertrauen, daran würde auch ein Status 401 nichts verbessern, den ein Anderer, nicht autorisierter Benutzer bekommen würde, wenn er MEIN Backend aufruft.

          Wieso sollte das Misstrauen hervorrufen? Security by Obscurity? Wichtig ist doch, dass niemand unbefugtes tatsächlich Zugriff auf das Backend gelangt. Das Backend sollte deshalb hinter einem sicheren Login-System verborgen sein und nicht hinter einem "geheimen Link".

          Irgendwann stoßen wir vielleicht auf die Ursache, dass man eingeloggt sein muss, um die Ressource sehen zu können.

          Wer hätte das gedacht: Man muss eingeloggt sein, dass man die Seite genauso sieht wie der Kunde ;)

          Wenn mir ein Kollege, ein Freund oder ein Kunde einen Link schickt, dann weiß ich nicht, ob er eingelogt war, als er den Link aus seiner Adresszeile kopiert hat. Wenn ich dem Link folge, und ich erhalte als Fehler nur "404 – Not Found", dann muss ich davon ausgehen, dass der Link kaputt ist, weil das Ziel eben nicht gefunden werden kann. Eine aussagekräftige Fehlermeldung ala "401 Unauthorized" symbolisert mir dagegen, dass ich eingelogt sein muss, um die Ressource sehen zu können.

          Wie Sven bereits sinnvoll ergänzt hat, geht es bei den Status-Codes nur um ein technisches Detail. Wichtiger ist wohl, dass dem Nutzer eine verständliche Erklärung in menschlicher Sprache erfolgt, das kann sowohl auf einer 401-Seite, als auch auf einer 404-Seite geschehen. Ich erkenne aber keinen Nutzen darin, hier Mensch und Maschine mit widersprüchlichen Informationen zu versorgen.

          Eine 401-Fehlermeldung hätte uns schneller auf den richtigen Dampfer gebracht.

          Einem Kunden ists egal, wie IHR EURE interne Kommunikation abwickelt.

          Das war nur ein Beispiel, mach aus "mir" und meinem "Arbeitskollegen" einfach "Kunde" und "sein bester Freund" und das Praxisbeispiel funktioniert immernoch.

          Ein Kunde schenkt seinem Provider Vertrauen, weil er davon ausgeht, dass sein Backend (seine Kundenseite) nur von ihm selbst, mit seinen ganz persönlichen Zugangsdaten, aufgerufen werden kann.

          Alles andere wäre auch inakzeptabel. Aber was hat das mit 404 vs. 401 zu tun?

          --
          “All right, then, I'll go to hell.” – Huck Finn
      3. Liebe Mitdenker,
        liebe Wissende,
        liebe Neugierige,

        ja!

        Warum sollte es die Ressource geben, für einen der sich nicht authentifiziert hat und nicht autorisiert ist?

        Das ist ein Denkfehler. Die bloße Existenz einer Ressource hängt nicht davon ab, ob sie gesehen werden kann oder nicht. Nordkorea existiert, auch wenn ich keine Einreisegenehmigung erhalte. Genauso verursacht der umfallende Baum im Wald Schallwellen, auch wenn diese von niemanden gehört werden.

        Es hat aber auch einen praktischen Nutzen, hier den aussagekräftigeren 401-Status-Code anstatt 404 zu benutzen: Angenommen ein Arbeitskollege schickt mir einen Link zu einer unserer Kundenseiten, und ich bekomme nur eine 404-Seite zu sehen, dann würde ich meinem Kollegen die Rückmeldung geben, dass er mir einen kaputten Link geschickt hat. Dann würden wir uns eine Weile darüber wundern, wieso der Link bei ihm funktioniert und bei mir nicht. Irgendwann stoßen wir vielleicht auf die Ursache, dass man eingeloggt sein muss, um die Ressource sehen zu können. Eine 401-Fehlermeldung hätte uns schneller auf den richtigen Dampfer gebracht.

        401 wäre aber Basic Auth Anforderung
        Daher hatte ich eher an 403 gedacht.
        http://de.m.wikipedia.org/wiki/HTTP-Statuscode

        Spirituelle Grüße
        Euer Robert

        --
        Möge der Forumsgeist wiederbelebt werden!
        1. 401 wäre aber Basic Auth Anforderung
          Daher hatte ich eher an 403 gedacht.
          http://de.m.wikipedia.org/wiki/HTTP-Statuscode

          Die Spec sagt unter anderem (Ich hab sie nicht komplett gelesen nur den Anfang von diesem Kapitel):
          "3.2.1 The WWW-Authenticate Response Header

          If a server receives a request for an access-protected object, and an
             acceptable Authorization header is not sent, the server responds with
             a "401 Unauthorized" status code, and a WWW-Authenticate header as
             per the framework defined above, which for the digest scheme is
             utilized as follows …"

          "and an acceptable Authorization header is not sent"
          Nunja mit einem Session-Cookie[*] kann man definitiv authorisiert sein. Je nach dem welchen man hat. Aus dieser Definition kann ich nicht entnehmen dass _nur_ Basic Auth auf das zutreffen kann.

          "an acceptable Authorization header" kann auch extrem vereinfacht sein, dass ein Header-Eintrag a la "X-Bla: 12345abcde" dafür genügt.

          MfG
          bubble

          [*] Der Session-Cookie allein natürlich nicht, das wäre nur Authentication, nur das was in der Session gepseichert ist kann über die Authorization Auskunft geben

          --
          If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
        2. Aloha ;)

          401 wäre aber Basic Auth Anforderung

          Nö. Nicht unbedingt. Zitat von der von dir verlinkten Seite:

          Wie die Authentifizierung durchgeführt werden soll, wird im „WWW-Authenticate“-Header-Feld der Antwort übermittelt.

          Du hast also die gesamte Bandbreite der Authenticate-Methoden zur Verfügung, auch abseits von Basic Auth.

          Natürlich ist das nicht unbedingt was du hören wolltest - denn tatsächlich ist hier zunächst mal die Frage, was du senden kannst, damit KEINE Abfrage aufkommt.

          Du kannst dabei vielleicht Browserverhalten ausnutzen: Eine vollkommen unbekannte Authenticate-Methode führt (aktuell und wahrscheinlich auch in Zukunft) wohl dazu, dass nirgends ein Eingabefenster aufpoppt.

          Daher hatte ich eher an 403 gedacht.

          Zitat von der von dir verlinkten Seite:

          Diese Entscheidung wurde – anders als im Fall des Statuscodes 401 – unabhängig von Authentifizierungsinformationen getroffen,

          DAS ist auch nicht das, was du sagen willst. Das würde ja heißen: "Auch das einloggen hat keinen Sinn. So wie du gefragt hast, bekommst du diese Ressource nie!"

          Wenn du ganz sicher gehen willst, dass die Browser sich richtig verhalten und du zwar vielleicht nicht viel, aber zumindest nichts falsches über dein Problem aussagst, dann nimm doch einen 400-er Fehler. Der ist generisch und behandelt damit alle denkbaren Sonderfälle, auch die, die keine Nummer tragen. Wenn du die Info mit dem möglichen Einloggen geben willst, würde ich zur 401-er Variante mit eigenem WWW-Authenticate raten.

          Disclaimer: Meine Meinung. Andere mögen das für Bullshit halten ;)

          Grüße,

          RIDER

          --
          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
          ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
          1. Liebe Mitdenker,
            liebe Wissende,
            liebe Neugierige,

            ja!

            Wenn du ganz sicher gehen willst, dass die Browser sich richtig verhalten und du zwar vielleicht nicht viel, aber zumindest nichts falsches über dein Problem aussagst, dann nimm doch einen 400-er Fehler. Der ist generisch und behandelt damit alle denkbaren Sonderfälle, auch die, die keine Nummer tragen. Wenn du die Info mit dem möglichen Einloggen geben willst, würde ich zur 401-er Variante mit eigenem WWW-Authenticate raten.

            Ich werde mal damit experimentieren und auch beobachten, was mit den betroffenen Inhalten in den Suchmaschinen passiert.

            Spirituelle Grüße
            Euer Robert

            --
            Möge der Forumsgeist wiederbelebt werden!
          2. Wenn du ganz sicher gehen willst, dass die Browser sich richtig verhalten und du zwar vielleicht nicht viel, aber zumindest nichts falsches über dein Problem aussagst, dann nimm doch einen 400-er Fehler.

            Ich versteh den 400er anders, nämlich so, dass die Anfrage z.B. einen Syntaxfehler - aber auf jeden Fall keine übergeordnete Rolle bezüglich der anderen 4XXer - hat.

            "10.4.1 400 Bad Request

            The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications." (Quelle)
            Das unterstützt wohl meine Meinung und widerlegt deine.

            Disclaimer: Meine Meinung. Andere mögen das für Bullshit halten ;)

            Egal was man sagt, wie man argumentiert, oder ob es Bullshit ist, es ist deren Meinung, das muss man doch nicht extra sagen ;)

            MfG
            bubble

            --
            If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
            1. Aloha ;)

              Ich versteh den 400er anders, nämlich so, dass die Anfrage z.B. einen Syntaxfehler - aber auf jeden Fall keine übergeordnete Rolle bezüglich der anderen 4XXer - hat.

              "10.4.1 400 Bad Request

              The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications." (Quelle)
              Das unterstützt wohl meine Meinung und widerlegt deine.

              Tja, das ist so die Sache mit den verschiedenen Übersetzungen und Tradierungen. Falls es hilft: In diesem Fall legt nicht das W3C die Standards fest, sondern die Status Codes sind in RFC's festgehalten. Das Dokument des W3C ist mehr eine Erläuterung dazu.

              Und in RFC 7231 heißt es:

              6.5.1.  400 Bad Request

              The 400 (Bad Request) status code indicates that the server cannot or
                 will not process the request due to something that is perceived to be
                 a client error (e.g., malformed request syntax, invalid request
                 message framing, or deceptive request routing).

              Du siehst also, der 400er Fehler ist tatsächlich generisch. Das, was vom W3C als Wahrheit hingestellt wird, ist tatsächlich nur eine der Möglichkeiten. Kurz gesagt: Error 400 sagt nur aus, dass der Request nicht das gewünschte Ergebnis bringt, da der Client etwas falsch gemacht hat. Was er falsch gemacht hat, könnte man mit anderen 4xx-Fehlern genauer spezifizieren.

              Das ist übrigens auch das, was die Fehlermeldung sagt. "Bad Request" heißt ja nur, dass der Request in dieser Form (das umschließt auch den Status des Angemeldet-sein oder nicht) kein Ergebnis bringen wird. Hätte das W3C recht, gäbe es keinen Grund, das Kind "Bad Request" zu nennen. Dann hieße es sinnigerweise ja wohl eher "Malformed Request Syntax"... Fehlermeldungen sind aus gutem Grund immer so spezifisch wie möglich - und eine derart unspezifische Aussage wie "Bad Request" macht nur dann Sinn, wenn der zugehörige Fehler ebenso unspezifisch ist...

              Vergleiche dazu auch: 100 bedeutet soviel wie: Der Request ist am Laufen (generischer Statuscode für ablaufende Requests), 200 bedeutet soviel wie: Alles okay (also auch generisch, denn das sagt noch nicht zwangsläufig was drüber aus, ob ne Antwort kommt, oder ob nicht, oder ob erst später was passiert - ähnlich wie 400 ggü. den 4xx-ern. Und 500 ist wohl der generischste Status von allen mit der Bedeutung: Der Server hat irgendwas falschgemacht (im Gegensatz zu 400, wo der client was falsch gemacht hat).

              Disclaimer: Meine Meinung. Andere mögen das für Bullshit halten ;)
              Egal was man sagt, wie man argumentiert, oder ob es Bullshit ist, es ist deren Meinung, das muss man doch nicht extra sagen ;)

              Stimmt - hilft aber manchmal :D Wenn man Leute extra dran erinnert, sind die Reaktionen meist milder :D Zumal ich zum Zeit meines Postings auch noch nicht im RFC nachgelesen hatte, sondern nur Sekundärquellen aufweisen konnte :D

              Grüße,

              RIDER

              --
              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
              ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
              1. Aloha ;)

                Vielleicht sollten wir alle in Zukunft zunächst mal Primärquellen lesen.

                Jedenfalls ist der 403er offiziell so definiert:

                The 403 (Forbidden) status code indicates that the server understood
                   the request but refuses to authorize it.  A server that wishes to
                   make public why the request has been forbidden can describe that
                   reason in the response payload (if any).

                If authentication credentials were provided in the request, the
                   server considers them insufficient to grant access.  The client
                   SHOULD NOT automatically repeat the request with the same
                   credentials.  The client MAY repeat the request with new or different
                   credentials.  However, a request might be forbidden for reasons
                   unrelated to the credentials.

                An origin server that wishes to "hide" the current existence of a
                   forbidden target resource MAY instead respond with a status code of
                   404 (Not Found).

                (RFC 7231)

                Der 403er passt also entgegen einiger Antworten tatsächlich doch laut Definition auf das Problem.

                Auch noch dazu - eine ziemlich gute Erklärung (Quelle):

                A clear explanation from Daniel Irvine :

                401 Unauthorized, the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please reauthenticate and try again.” To help you out, it will always include a WWW-Authenticate header that describes how to authenticate.

                This is a response generally returned by your web server, not your web application.

                It’s also something very temporary; the server is asking you to try again.

                So, for authorization I use the 403 Forbidden response. It’s permanent, it’s tied to my application logic, and it’s a more concrete response than a 401.

                Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”

                In summary, a 401 Unauthorized response should be used for missing or bad authentication, and a 403 Forbidden response should be used afterwards, when the user is authenticated but isn’t authorized to perform the requested operation on the given resource.

                Ach ja, und @bubble: Das von dir verlinkte W3C-Dokument ist nicht etwa falsch, sondern bezieht sich auf eine veraltete RFC (die RFC 2616). Diese wurde durch von mir verlinkte RFC 7231 abgelöst. Die Infos sind also nur inzwischen falsch, da veraltet.

                Grüße,

                RIDER

                --
                Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
  3. Welchen HTTP-Status sollte man benutzen, wenn die Ressource zwar vorhanden ist, aber ohne Authentifizierung nicht zur Verfügung steht.

    Antwort, m.E. 403.

    Welchen HTTP-Status sollte man benutzen, wenn die Ressource zwar vorhanden ist, aber ohne Autorisierung nicht zur Verfügung steht.

    Antwort m.E. 401

    Cheers,
    Baba

    --
    Baba kommt von Basketball
    1. Aloha ;)

      Dazu noch als Ergänzung eine Erklärung zum Unterschied.

      Grüße,

      RIDER

      --
      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
      ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
  4. Mahlzeit,

    403 Forbidden -> erscheint mir noch am sinnvollsten. Aber was machen die Suchmaschinen dann mit einer solchen Antwort?

    Ohne die anderen Beiträge gelesen zu haben: Wenn du solche Seiten nicht per robots.txt aus dem Index ausschliesst, hast du was falsch gemacht.

    --
    eigentlich ist mir bewusst, dass ich hin und wieder einfach mal die Klappe halten sollte. Doch genau in den unpassendsten Momenten erwische ich mich dabei, wie ich dennoch etwas sage ...
    1. Liebe Mitdenker,
      liebe Wissende,
      liebe Neugierige,

      ja!

      403 Forbidden -> erscheint mir noch am sinnvollsten. Aber was machen die Suchmaschinen dann mit einer solchen Antwort?

      Ohne die anderen Beiträge gelesen zu haben: Wenn du solche Seiten nicht per robots.txt aus dem Index ausschliesst, hast du was falsch gemacht.

      Wie geht das denn per robots.txt?

      Die Rechte sind dynamisch. Die ergeben sich erst nach der Auswertung des Requests

      Spirituelle Grüße
      Euer Robert

      --
      Möge der Forumsgeist wiederbelebt werden!
      1. Ohne die anderen Beiträge gelesen zu haben: Wenn du solche Seiten nicht per robots.txt aus dem Index ausschliesst, hast du was falsch gemacht.
        Die Rechte sind dynamisch. Die ergeben sich erst nach der Auswertung des Requests

        Stell dir vor jemand besucht zum ersten mal deine Seite, keine Cookies, keine Session, gar nichts. Was sieht er/sie?
        Das lieferst du aus, und wenn das einen 4XX-Status-Code auslöst sollte es halt in der robots.txt auftauchen, evt. mit Wildcards
        Wenn die Rechte allein über Reqeust-Parameter wie POST oder GET "berechnet" werden, hast du ein derbes Problem.

        MfG
        bubble

        --
        If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
      2. Hallo

        403 Forbidden -> erscheint mir noch am sinnvollsten. Aber was machen die Suchmaschinen dann mit einer solchen Antwort?

        Ohne die anderen Beiträge gelesen zu haben: Wenn du solche Seiten nicht per robots.txt aus dem Index ausschliesst, hast du was falsch gemacht.

        Wie geht das denn per robots.txt?

        Man trägt die Ressource (den Pfad zu deinem per HTTP erreichbaren PHP-Skript) in die robots.txt ein.

        Die Rechte sind dynamisch. Die ergeben sich erst nach der Auswertung des Requests

        Es geht an dieser Stelle nicht um die Rechte, die ein Besucher hat oder nicht hat. Es geht darum, die Ressource vor den Robotern der Suchmaschinen und ähnlichen Diensten zu verbergen.

        Tschö, Auge

        --
        Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
        Terry Pratchett, "Wachen! Wachen!"
        ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
        Veranstaltungsdatenbank Vdb 0.3
    2. 403 Forbidden -> erscheint mir noch am sinnvollsten. Aber was machen die Suchmaschinen dann mit einer solchen Antwort?

      Ohne die anderen Beiträge gelesen zu haben: Wenn du solche Seiten nicht per robots.txt aus dem Index ausschliesst, hast du was falsch gemacht.

      Das ist Unfug - ob eine Ressource von Robots/Crawlern indiziert werden soll, hängt nicht davon ab, ob sie öffentlich einsehbar ist oder nicht.

      Ein klassisches Beispiel sind Wissenschaftliche publikationen, die mit einer Paywall geschützt sind.

      Da bekomme ich einen Abstract mit einer Zahlungsaufforderung und einem Login, die Ressource ist indiziert aber den kompletten Inhalt kann ich trotzdem nicht sehen, wenn ich über die nötigen Rechte verfüge.

      1. Hallo

        … Wenn du solche Seiten nicht per robots.txt aus dem Index ausschliesst, hast du was falsch gemacht.

        Das ist Unfug

        … Wissenschaftliche publikationen … mit einer Paywall …

        Da bekomme ich einen Abstract mit einer Zahlungsaufforderung und einem Login, die Ressource ist indiziert aber den kompletten Inhalt kann ich trotzdem nicht sehen, wenn ich über die nötigen Rechte verfüge.

        Wenn du über die Rechte verfügst, also gezahlt hast, und dennoch den kompletten Inhalt nicht sehen kannst, hast du /*_definitiv_*/ etwas falsch gemacht. *scnr*

        Tschö, Auge

        --
        Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
        Terry Pratchett, "Wachen! Wachen!"
        ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
        Veranstaltungsdatenbank Vdb 0.3
        1. Da bekomme ich einen Abstract mit einer Zahlungsaufforderung und einem Login, die Ressource ist indiziert aber den kompletten Inhalt kann ich trotzdem nicht sehen, wenn ich über die nötigen Rechte verfüge.

          Wenn du über die Rechte verfügst, also gezahlt hast, und dennoch den kompletten Inhalt nicht sehen kannst, hast du /*_definitiv_*/ etwas falsch gemacht. *scnr*

          :) nein, so funktioniert das: du wirst mehrfach abgezockt :p

          1. Liebe Mitdenker,
            liebe Wissende,
            liebe Neugierige,

            ja!

            Da bekomme ich einen Abstract mit einer Zahlungsaufforderung und einem Login, die Ressource ist indiziert aber den kompletten Inhalt kann ich trotzdem nicht sehen, wenn ich über die nötigen Rechte verfüge.

            Für Bezahlaufforderung gibt es eigentlich den Status 402.

            Wenn du über die Rechte verfügst, also gezahlt hast, und dennoch den kompletten Inhalt nicht sehen kannst, hast du /*_definitiv_*/ etwas falsch gemacht. *scnr*

            :) nein, so funktioniert das: du wirst mehrfach abgezockt :p

            Kann aber auch sein, dass Du am Montag guckst. Aber Montag arbeitet Chantal nie ;-P

            Mich würde jetzt noch interessieren, wie ich das mit 401 machen muss, damit der Browser NICHT das Fenster für die Credentials aufklappt. Meine Authentifizierung findet cookies.only statt :-)

            Wenn also kein Auth-Cookie mitkommt, bekommt der Client demnächst die Antwort 401 - mit Angabe, wie bzw. wo er sich ein Token holen kann - vorausgesetzt, ich krieg das hin ohne das Fenster!

            Wenn ein formal passendes Token mitkommt, das aber nicht mehr gültig ist, bekommt der Client 403, ebenfalls mit dem Verweis, wo er das Token bekommen kann.

            Bleibt nur das Problem, dass ich noch nnciht weiß, wie der Browser darauf reagiert, wenn er anstelle eines Bildes dann einen Text bekommt. Muss ich erstmal nachschauen und ausprobieren, ob das überhaupt zulässig ist und geht, dass man einem <img>-Request einfach durch einen anderen Content-Type mitteilt, dass ätsch ist!

            Spirituelle Grüße
            Euer Robert

            --
            Möge der Forumsgeist wiederbelebt werden!
            1. Hallo,

              Mich würde jetzt noch interessieren, wie ich das mit 401 machen muss, damit der Browser NICHT das Fenster für die Credentials aufklappt. Meine Authentifizierung findet cookies.only statt :-)

              Wenn also kein Auth-Cookie mitkommt, bekommt der Client demnächst die Antwort 401 - mit Angabe, wie bzw. wo er sich ein Token holen kann - vorausgesetzt, ich krieg das hin ohne das Fenster!

              es geht nicht. Status 401 und HTTP-AUTH sind untrennbar miteinander verknüpft. Sobald du 401 sendest, wird der Browser immer sein eingebautes(!) Abfragefenster für die nötigen Credentials aufpoppen lassen, das AFAIK auch nicht mit einem eigenen Design gepimpt werden kann.

              Wenn du eine andere Form der Authentifizierung willst, z.B. wie angedeutet über Cookies, musst du das serverseitig selbst managen, aber um Himmels Willen keinen 401 senden.

              Bleibt nur das Problem, dass ich noch nnciht weiß, wie der Browser darauf reagiert, wenn er anstelle eines Bildes dann einen Text bekommt. Muss ich erstmal nachschauen und ausprobieren, ob das überhaupt zulässig ist und geht, dass man einem <img>-Request einfach durch einen anderen Content-Type mitteilt, dass ätsch ist!

              Klar geht das - du kannst mit einem img-Element eine Bildressource anfordern, und in Wirklichkeit sendet der Server unter http://example.org/iwantaphoto.jpg eine HTML-Ressource mit dem "passenden" Content-Type text/html. Technisch kein Problem.
              Der anfragende Browser wird dann aber sein "broken image"-Symbol anzeigen, weil er die Serverantwort nicht als Bild interpretieren kann, was in dem Kontext aber notwendig ist.

              So long,
               Martin

              --
              Er:  Mit wem warst du gestern abend aus?
              Sie: Du bist mal wieder eifersüchtig wie immer!
              Er:  Wer ist Immer?
              Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
              1. Liebe Mitdenker,
                liebe Wissende,
                liebe Neugierige,

                ja!

                Hallo,

                Mich würde jetzt noch interessieren, wie ich das mit 401 machen muss, damit der Browser NICHT das Fenster für die Credentials aufklappt. Meine Authentifizierung findet cookies.only statt :-)

                Wenn also kein Auth-Cookie mitkommt, bekommt der Client demnächst die Antwort 401 - mit Angabe, wie bzw. wo er sich ein Token holen kann - vorausgesetzt, ich krieg das hin ohne das Fenster!

                es geht nicht. Status 401 und HTTP-AUTH sind untrennbar miteinander verknüpft. Sobald du 401 sendest, wird der Browser immer sein eingebautes(!) Abfragefenster für die nötigen Credentials aufpoppen lassen, das AFAIK auch nicht mit einem eigenen Design gepimpt werden kann.

                Wenn du eine andere Form der Authentifizierung willst, z.B. wie angedeutet über Cookies, musst du das serverseitig selbst managen, aber um Himmels Willen keinen 401 senden.

                Bleibt nur das Problem, dass ich noch nnciht weiß, wie der Browser darauf reagiert, wenn er anstelle eines Bildes dann einen Text bekommt. Muss ich erstmal nachschauen und ausprobieren, ob das überhaupt zulässig ist und geht, dass man einem <img>-Request einfach durch einen anderen Content-Type mitteilt, dass ätsch ist!

                Klar geht das - du kannst mit einem img-Element eine Bildressource anfordern, und in Wirklichkeit sendet der Server unter http://example.org/iwantaphoto.jpg eine HTML-Ressource mit dem "passenden" Content-Type text/html. Technisch kein Problem.
                Der anfragende Browser wird dann aber sein "broken image"-Symbol anzeigen, weil er die Serverantwort nicht als Bild interpretieren kann, was in dem Kontext aber notwendig ist.

                "Schlauberger" ;-p

                Dass man auf die Frage "hast Du Hunger" auch mit "mein Auto braucht einen Ölwechsel" antworten kann, ist auch klar. Aber das wollte der Fragesteller nicht wissen ...

                Na, dann bleibt es jetzt bei Status 403. Ich muss noch testen, ob ich trotzdem noch ein Ersatzbild senden kann, dass dann auch angezeigt wird. Da kann man ja mit GD einen passenden Text reinschreiben...

                Spirituelle Grüße
                Euer Robert

                --
                Möge der Forumsgeist wiederbelebt werden!
                1. Aloha ;)

                  Na, dann bleibt es jetzt bei Status 403. Ich muss noch testen, ob ich trotzdem noch ein Ersatzbild senden kann, dass dann auch angezeigt wird. Da kann man ja mit GD einen passenden Text reinschreiben...

                  Also jetzt fühl ich mich irgendwie ignoriert :D

                  Grüße,

                  RIDER

                  --
                  Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                  ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
                  1. Liebe Mitdenker,
                    liebe Wissende,
                    liebe Neugierige,

                    ja!

                    Aloha ;)

                    Na, dann bleibt es jetzt bei Status 403. Ich muss noch testen, ob ich trotzdem noch ein Ersatzbild senden kann, dass dann auch angezeigt wird. Da kann man ja mit GD einen passenden Text reinschreiben...

                    Also jetzt fühl ich mich irgendwie ignoriert :D

                    Nun weine nicht. Das steht schon lange auf meinem Testzettel. Aber sowas dauert, da immer auch recherchiert werden muss, ob ein entdecktes Verhalten durch RFC oder ähnlich verbrieft ist. Sonst darf ich es nicht einsetzen!

                    Hacks müssen draußen bleiben. Es muss immer die einfachste Lösung gewählt werden, bei JS-Verwendung muss es auch ohne funktionieren, usw.

                    Aber Der Martin hat doch schon geschrieben, dass 401 fix an das Credential-Fenster gebunden ist. https://forum.selfhtml.org/?t=218943&m=1512333

                    Spirituelle Grüße
                    Euer Robert

                    --
                    Möge der Forumsgeist wiederbelebt werden!
                    1. Aloha ;)

                      Ich weine nie, ich lache blos :D

                      Aber Der Martin hat doch schon geschrieben, dass 401 fix an das Credential-Fenster gebunden ist. https://forum.selfhtml.org/?t=218943&m=1512333

                      Genau genommen hat er imho seine Erfahrung geschildert und keine mit Nachweisen untermauerte, standardkonforme Tatsache behauptet ;)

                      Außerdem: Was ist sinnvoller und wahrscheinlicher - dass Browser sowie Standard sich auf ein bis zwei spezielle Auth-Methoden einschießen und den allgemein gehaltenen 401-Statuscode nur auf den Einsatz für diese Methoden beschränken? Oder dass Browser und Standard vielfältige Möglichkeiten offenhalten, schon um zukünftigen Sicherheitsstandards Raum zu lassen?

                      Kann man von einem Hack reden, wenn man dem Browser sagt: "Dein user muss sich authentifizieren, aber du kennst die Methode dafür nicht"? Eher nicht. Dass ein Browser dann den 401er-Statuscode akzeptiert und kein Eingabefenster öffnet scheint mir die logische Reaktion zu sein. Ob das vielleicht sogar RFC-gestützt ist, muss ich auch zuerst mal recherchieren...

                      Bedenke, dass das Wort "Hack" nicht immer bedeutet, dass das Verhalten, dass der Hacker nutzt, unerwünscht ist - es bedeutet vielmehr, dass man ein Verhalten für eine bestimmte Situation nutzt, dass für eigentlich für eine andere Situation konzipiert wurde - das bedeutet nicht, dass man das nicht (sogar standardkonform) einsetzen darf. Siehe auch der Begriff "Life-Hack".

                      Grüße,

                      RIDER

                      --
                      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                      ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
                      1. Hallo,

                        Aber Der Martin hat doch schon geschrieben, dass 401 fix an das Credential-Fenster gebunden ist. https://forum.selfhtml.org/?t=218943&m=1512333
                        Genau genommen hat er imho seine Erfahrung geschildert und keine mit Nachweisen untermauerte, standardkonforme Tatsache behauptet ;)

                        sagen wir mal, ich habe anhand logischer Überlegungen verallgemeinert. ;-)

                        Und wir widersprechen einander ja auch nicht wirklich, wir betrachten nur unterschiedliche Teilaspekte. Ich habe (pauschal) behauptet, ein Browser, der per 401-Status zur Authentifizierung aufgefordert wird, fragt die Daten sofort vom Nutzer ab, um den Request dann _mit_ Credentials und der (einer) akzeptierten Auth-Methode zu wiederholen.

                        Und dein Gedanke war, wenn ich es richtig verstanden habe, dem Browser nur einen Auth-Type anzubieten, den er garantiert nicht kennt, so dass er von vornherein darauf verzichtet, die Daten abzufragen - er wüsste ja sowieso nicht, wie er dann damit umgehen muss. Das ist auch irgendwie nachvollziehbar, nur: Welches Ziel hätte man damit erreicht? Welchen Zweck hätte die Auth-Aufforderung, wenn sie nicht erfüllbar ist? Dann kann ich doch das Auth-Gedöns auch gleich lassen - oder übersehen ich den eigentlichen Trick?

                        Kann man von einem Hack reden, wenn man dem Browser sagt: "Dein user muss sich authentifizieren, aber du kennst die Methode dafür nicht"? Eher nicht.

                        Nein, eher nicht. Aber von einer unlösbaren Aufgabe. ;-)

                        So long,
                         Martin

                        --
                        F: Was sagt die kleine Kerze zur großen Kerze?
                        A: Ich gehe heute nacht aus!
                        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                        1. Aloha ;)

                          Und dein Gedanke war, wenn ich es richtig verstanden habe, dem Browser nur einen Auth-Type anzubieten, den er garantiert nicht kennt, so dass er von vornherein darauf verzichtet, die Daten abzufragen - er wüsste ja sowieso nicht, wie er dann damit umgehen muss.

                          Ganz genau, ja.

                          Das ist auch irgendwie nachvollziehbar, nur: Welches Ziel hätte man damit erreicht? Welchen Zweck hätte die Auth-Aufforderung, wenn sie nicht erfüllbar ist? Dann kann ich doch das Auth-Gedöns auch gleich lassen - oder übersehen ich den eigentlichen Trick?

                          Die Antwort ist einfach. Ich kann dem User über die Seite, die mit dem 401-Header gesendet wird, eine Authentifizierungsmöglichkeit zukommen lassen - z.B. per Eingabemaske für Username und Passwort für den systemeigenen, z.b. PHP-/Session-basierten Login-Prozess, der sich ja durchaus von BASIC-AUTH unterscheiden kann, und trotzdem einen bedeutungsvollen HTTP-Statuscode senden - der z.B. Suchmaschinen davon abhält, die Loginmaske zu indizieren oder noch anderweitigen Zwecken dienen kann. Grundsätzlich bin ich schon der Meinung, dass eine Login-Wall (lies: eine Seite, die unangemeldete User zum Login auffordert und nur bei Angemeldeten Content ausliefert) mit einem 401-Statuscode daherkommen sollte.

                          Das ist auch der Zweck, den unser TO hier afaik zugrundeliegen hat: eine Loginanforderung, bei der kein Eingabefenster für BASIC-AUTH aufpoppen soll...

                          Kann man von einem Hack reden, wenn man dem Browser sagt: "Dein user muss sich authentifizieren, aber du kennst die Methode dafür nicht"? Eher nicht.

                          Nein, eher nicht. Aber von einer unlösbaren Aufgabe. ;-)

                          Nur weil der Browser die Methode nicht kennt, kennt sie der User eventuell trotzdem :P z.B. dann, wenn auf der mit 401 ausgelieferten Seite ein Loginformular (oder ein Captcha, oder ...) liegt ;)

                          Grüße,

                          RIDER

                          P.S.: Mir kam grad die abgefahrene Idee, User erst dann hinter die Tür meiner Login-Wall zu lassen, wenn sie das dort hinterlegte Türöffner-Kreuzworträtsel gelöst haben. Oder wenn sie eine Passage aus Homer's Odyssee übersetzt haben... oh man - hätte das Style :D okay, ich hätte bald keine Besucher mehr... aber wer braucht die schon xD

                          --
                          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                          ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
                          1. Hallo

                            Das ist auch irgendwie nachvollziehbar, nur: Welches Ziel hätte man damit erreicht? Welchen Zweck hätte die Auth-Aufforderung, wenn sie nicht erfüllbar ist? Dann kann ich doch das Auth-Gedöns auch gleich lassen - oder übersehen ich den eigentlichen Trick?

                            Die Antwort ist einfach. Ich kann dem User über die Seite, die mit dem 401-Header gesendet wird, eine Authentifizierungsmöglichkeit zukommen lassen - z.B. per Eingabemaske für Username und Passwort für den systemeigenen, z.b. PHP-/Session-basierten Login-Prozess, der sich ja durchaus von BASIC-AUTH unterscheiden kann, und trotzdem einen bedeutungsvollen HTTP-Statuscode senden - der z.B. Suchmaschinen davon abhält, die Loginmaske zu indizieren oder noch anderweitigen Zwecken dienen kann.

                            Das macht ein Browser dann wie? Wenn 401 kommt, will der Browser den nächsten Request auf eine bestimmte Art und Weise absetzen. Nun magst du den einen oder anderen *deiner* Browser wegen Open Source so anpassen können, dass er die Eingaben aus einem HTML-Formular in die richtigen Felder des Requests setzt, aber wie sollen das andere Benutzer deiner hypothetischen Seite tun? Die kriegen doch allesamt 'nen 403-er.

                            Nur weil der Browser die Methode nicht kennt, kennt sie der User eventuell trotzdem :P z.B. dann, wenn auf der mit 401 ausgelieferten Seite ein Loginformular (oder ein Captcha, oder ...) liegt ;)

                            … mit dem der Browser nichts anfangen kann? :-)

                            Tschö, Auge

                            --
                            Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                            Terry Pratchett, "Wachen! Wachen!"
                            ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
                            Veranstaltungsdatenbank Vdb 0.3
                            1. Aloha ;)

                              Das ist auch irgendwie nachvollziehbar, nur: Welches Ziel hätte man damit erreicht? Welchen Zweck hätte die Auth-Aufforderung, wenn sie nicht erfüllbar ist? Dann kann ich doch das Auth-Gedöns auch gleich lassen - oder übersehen ich den eigentlichen Trick?

                              Die Antwort ist einfach. Ich kann dem User über die Seite, die mit dem 401-Header gesendet wird, eine Authentifizierungsmöglichkeit zukommen lassen - z.B. per Eingabemaske für Username und Passwort für den systemeigenen, z.b. PHP-/Session-basierten Login-Prozess, der sich ja durchaus von BASIC-AUTH unterscheiden kann, und trotzdem einen bedeutungsvollen HTTP-Statuscode senden - der z.B. Suchmaschinen davon abhält, die Loginmaske zu indizieren oder noch anderweitigen Zwecken dienen kann.

                              Das macht ein Browser dann wie? Wenn 401 kommt, will der Browser den nächsten Request auf eine bestimmte Art und Weise absetzen. Nun magst du den einen oder anderen *deiner* Browser wegen Open Source so anpassen können, dass er die Eingaben aus einem HTML-Formular in die richtigen Felder des Requests setzt, aber wie sollen das andere Benutzer deiner hypothetischen Seite tun? Die kriegen doch allesamt 'nen 403-er.

                              Ich glaube du (Martin auch?) verstehst mich vollkommen falsch. Nein, er soll nicht die Eingaben aus dem HTML-Formular in den Request setzen. Das HTML-Formular wird per Post mit den Anmeldedaten an PHP geschickt, dieses setzt bei richtiger Eingabe für diese Session-ID den Angemeldet-Status und liefert dann, statt wie bisher den 401-Header und die Eingabeaufforderung, einen 200-Header und den Content.

                              Ich rede die ganze Zeit von einem selbstgeschriebenen Anmeldesystem (PHP-/sessionbasiert), das ohne jegliche spezielle Browserunterstützung auskommt, aber trotzdem in der Lage sein sollte, aussagekräftige Statuscodes zu verwenden. Ohne, dass dabei ein Anmeldefenster für BASIC-AUTH aufpoppen soll...

                              Grüße,

                              RIDER

                              --
                              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                              ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
                              1. Hallo

                                … Ich kann dem User über die Seite, die mit dem 401-Header gesendet wird, eine Authentifizierungsmöglichkeit zukommen lassen - z.B. per Eingabemaske für Username und Passwort für den systemeigenen, z.b. PHP-/Session-basierten Login-Prozess, der sich ja durchaus von BASIC-AUTH unterscheiden kann, …

                                Das macht ein Browser dann wie? …

                                Ich glaube du (Martin auch?) verstehst mich vollkommen falsch. Nein, er soll nicht die Eingaben aus dem HTML-Formular in den Request setzen. Das HTML-Formular wird per Post mit den Anmeldedaten an PHP geschickt, dieses setzt bei richtiger Eingabe für diese Session-ID den Angemeldet-Status und liefert dann, statt wie bisher den 401-Header und die Eingabeaufforderung, einen 200-Header und den Content.

                                Was hat das dann aber mit den 40x-hHeadern zu tun?

                                Ich rede die ganze Zeit von einem selbstgeschriebenen Anmeldesystem (PHP-/sessionbasiert), das ohne jegliche spezielle Browserunterstützung auskommt, aber trotzdem in der Lage sein sollte, aussagekräftige Statuscodes zu verwenden. Ohne, dass dabei ein Anmeldefenster für BASIC-AUTH aufpoppen soll...

                                Das geht aber nicht, wenn du die 40x-er verwendest. Wenn 401 kommt, wird der Browser eine Auth-Eingabeaufforderung welchen Levels auch immer, muss ja nicht Basic-Auth sein, anzeigen.

                                Tschö, Auge

                                --
                                Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                                Terry Pratchett, "Wachen! Wachen!"
                                ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
                                Veranstaltungsdatenbank Vdb 0.3
                                1. Aloha ;)

                                  Ich rede die ganze Zeit von einem selbstgeschriebenen Anmeldesystem (PHP-/sessionbasiert), das ohne jegliche spezielle Browserunterstützung auskommt, aber trotzdem in der Lage sein sollte, aussagekräftige Statuscodes zu verwenden. Ohne, dass dabei ein Anmeldefenster für BASIC-AUTH aufpoppen soll...

                                  Das geht aber nicht, wenn du die 40x-er verwendest. Wenn 401 kommt, wird der Browser eine Auth-Eingabeaufforderung welchen Levels auch immer, muss ja nicht Basic-Auth sein, anzeigen.

                                  :D So langsam hab ich das Gefühl ich rede gegen eine Wand. Meinetwegen nicht Basic-Auth. Die von mir verlinkte Methode zielt aber ganz genau darauf ab, dass _überhaupt kein_ Eingabefenster aufpoppt, das ist ja genau der Sinn und Zweck der Sache...

                                  Grüße,

                                  RIDER

                                  --
                                  Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                                  ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
                                  1. Hallo

                                    Ich rede die ganze Zeit von einem selbstgeschriebenen Anmeldesystem (PHP-/sessionbasiert), das ohne jegliche spezielle Browserunterstützung auskommt, aber trotzdem in der Lage sein sollte, aussagekräftige Statuscodes zu verwenden. Ohne, dass dabei ein Anmeldefenster für BASIC-AUTH aufpoppen soll...

                                    Das geht aber nicht, wenn du die 40x-er verwendest. Wenn 401 kommt, wird der Browser eine Auth-Eingabeaufforderung welchen Levels auch immer, muss ja nicht Basic-Auth sein, anzeigen.

                                    :D So langsam hab ich das Gefühl ich rede gegen eine Wand. Meinetwegen nicht Basic-Auth. Die von mir verlinkte Methode zielt aber ganz genau darauf ab, dass _überhaupt kein_ Eingabefenster aufpoppt, das ist ja genau der Sinn und Zweck der Sache...

                                    Bitteschön, aber dann lass halt die 40x-er weg.

                                    Tschö, Auge

                                    --
                                    Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                                    Terry Pratchett, "Wachen! Wachen!"
                                    ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
                                    Veranstaltungsdatenbank Vdb 0.3
                                    1. Aloha ;)

                                      :D So langsam hab ich das Gefühl ich rede gegen eine Wand. Meinetwegen nicht Basic-Auth. Die von mir verlinkte Methode zielt aber ganz genau darauf ab, dass _überhaupt kein_ Eingabefenster aufpoppt, das ist ja genau der Sinn und Zweck der Sache...

                                      Bitteschön, aber dann lass halt die 40x-er weg.

                                      ?!? Warum sollte ich? Warum sollte ich eine selbstgeschriebene Loginaufforderung mit HTTP-Statuscode 200 rausschicken? Wozu habe ich denn Statuscodes?

                                      Naja, egal... Ich hab den Eindruck das führt zu nichts mehr, zumindest ich für meinen Teil habe alles, was zu sagen wäre, schon gefühlte dreimal durchgekaut...

                                      Grüße,

                                      RIDER

                                      --
                                      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                                      ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
                                  2. Liebe Mitdenker,
                                    liebe Wissende,
                                    liebe Neugierige,

                                    ja!

                                    :D So langsam hab ich das Gefühl ich rede gegen eine Wand. Meinetwegen nicht Basic-Auth. Die von mir verlinkte Methode zielt aber ganz genau darauf ab, dass _überhaupt kein_ Eingabefenster aufpoppt, das ist ja genau der Sinn und Zweck der Sache...

                                    Na, dann zeig doch einfach mal ein Beispiel, bei dem ein anderer Status, als 2xx oder 3xx gesendet wird, also eben einer aus der 4xxer Reihe, bei dem der Client/die Suchmaschine darüber in Kenntnis gesetzt wird, dass hier nix ohne Authentifizierung geht, die aber NICHT AN DIESER STELLE durchgeführt werden soll. Es fehlen also ein gültiges Zertifikat (Token) oder gültige Credentials.

                                    Im Spezialfall ging es um eine Bildergalerie, bei der (die|einige) Bilder nicht ohne gültiges Token angezeigt werden dürfen, oder um Detail-Datensätze in einer Verwaltungssoftware, die die Detail-Datensätze keinesfalls ohne gültiges Token rausrücken darf oder oder oder.

                                    Spirituelle Grüße
                                    Euer Robert

                                    --
                                    Möge der Forumsgeist wiederbelebt werden!
                                2. Das geht aber nicht, wenn du die 40x-er verwendest. Wenn 401 kommt, wird der Browser eine Auth-Eingabeaufforderung welchen Levels auch immer, muss ja nicht Basic-Auth sein, anzeigen.

                                  Das ist falsch. Solange Du WWW-Authenticate weglässt(vermutlich auch, wenn man es mit Schrott füllt), kommt da bei den mir bekannten Clients nix. Das widerspricht allerdings der Spec, daher würde ich es auch nicht so machen wollen. Ich finde 403 samt Body Hinweis / Login absolut ok.

            2. Aloha ;)

              Mich würde jetzt noch interessieren, wie ich das mit 401 machen muss, damit der Browser NICHT das Fenster für die Credentials aufklappt. Meine Authentifizierung findet cookies.only statt :-)

              Wenn also kein Auth-Cookie mitkommt, bekommt der Client demnächst die Antwort 401 - mit Angabe, wie bzw. wo er sich ein Token holen kann - vorausgesetzt, ich krieg das hin ohne das Fenster!

              Hast du meinen Hinweis bzgl. unbekannter Auth-Methode schon abgearbeitet? Imho müsste das nämlich wie gewünscht funktionieren...

              Grüße,

              RIDER

              --
              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
              ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
      2. Mahlzeit,

        403 Forbidden -> erscheint mir noch am sinnvollsten. Aber was machen die Suchmaschinen dann mit einer solchen Antwort?

        Ohne die anderen Beiträge gelesen zu haben: Wenn du solche Seiten nicht per robots.txt aus dem Index ausschliesst, hast du was falsch gemacht.

        Das ist Unfug - ob eine Ressource von Robots/Crawlern indiziert werden soll, hängt nicht davon ab, ob sie öffentlich einsehbar ist oder nicht.

        Du willst ein 403 Forbidden einer Suchmaschine vorsetzen? Dann haben wir unterschiedliche Ansichten von sinnvoll ;)

        --
        eigentlich ist mir bewusst, dass ich hin und wieder einfach mal die Klappe halten sollte. Doch genau in den unpassendsten Momenten erwische ich mich dabei, wie ich dennoch etwas sage ...
        1. Aloha ;)

          Du willst ein 403 Forbidden einer Suchmaschine vorsetzen? Dann haben wir unterschiedliche Ansichten von sinnvoll ;)

          Imho nicht 403... Aber wenn wir über 401 reden, ja, das würde ich schon. Das von suit genannte Beispiel ist auch ein 1a-401-Beispiel, wo der Seiteninhalt (abstract) trotzdem von Bedeutung ist, evtl. auch für Suchmaschinen.

          Bei 403 Forbidden muss ich zustimmen, da mag mir kein so rechtes Szenario einfallen. (Denn 403 impliziert ja ausdrücklich, dass auch ein Anmelden am Zustand nichts ändern würde.) Allenfalls für nicht-öffentliche Working Drafts oder so, von denen nur eine Zusammenfassung mit dem 403er geliefert werden.

          Imho kann man nicht sagen, dass der HTTP-Statuscode von vornherein mit der robots.txt kausal zusammenhängt. Sie sind vielmehr imho voneinander unabhängig, wenn es auch in vielen Fällen sinnvoll ist, dass beides auftritt...

          Grüße,

          RIDER

          --
          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
          ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
          1. Mahlzeit,

            Imho nicht 403...

            Um den ging es aber konkret bei meiner Antwort, deshalb hab ich das auch ins Zitat aufgenommen.

            Aber wenn wir über 401 reden, ja, das würde ich schon. Das von suit genannte Beispiel ist auch ein 1a-401-Beispiel, wo der Seiteninhalt (abstract) trotzdem von Bedeutung ist, evtl. auch für Suchmaschinen.

            Das ist eine völlig andere Situation und dadurch auch nicht von meinem Post abgedeckt.

            Bei 403 Forbidden muss ich zustimmen, da mag mir kein so rechtes Szenario einfallen. (Denn 403 impliziert ja ausdrücklich, dass auch ein Anmelden am Zustand nichts ändern würde.) Allenfalls für nicht-öffentliche Working Drafts oder so, von denen nur eine Zusammenfassung mit dem 403er geliefert werden.

            Mir impliziert das nichts. Für mich heisst ein 403, das genau zum aktuellen Zeitpunkt die Ressource nicht verfügbar ist, weil ich nicht die nötigen Rechte habe. Das kann sich nach einem Login durchaus ändern, ebenfalls durch eine Freischaltung o.ä.

            Imho kann man nicht sagen, dass der HTTP-Statuscode von vornherein mit der robots.txt kausal zusammenhängt. Sie sind vielmehr imho voneinander unabhängig, wenn es auch in vielen Fällen sinnvoll ist, dass beides auftritt...

            Für mich hat ein 403 nicht in einer SuMa aufzutauchen. Und exakt das habe ich in dem Post ausgesagt, den suit kommentiert hat.

            --
            eigentlich ist mir bewusst, dass ich hin und wieder einfach mal die Klappe halten sollte. Doch genau in den unpassendsten Momenten erwische ich mich dabei, wie ich dennoch etwas sage ...
            1. Aloha ;)

              Imho nicht 403...

              Um den ging es aber konkret bei meiner Antwort, deshalb hab ich das auch ins Zitat aufgenommen.

              ACK. Mein Posting versteht sich in dem Sinne auch mehr als Ergänzung denn als Gegenrede.

              Mir impliziert das nichts. Für mich heisst ein 403, das genau zum aktuellen Zeitpunkt die Ressource nicht verfügbar ist, weil ich nicht die nötigen Rechte habe. Das kann sich nach einem Login durchaus ändern, ebenfalls durch eine Freischaltung o.ä.

              Ich hab mir die offizielle Definition des 403 noch einmal angeschaut.

              Da steht:

              The 403 (Forbidden) status code indicates that the server understood
                 the request but refuses to authorize it.  A server that wishes to
                 make public why the request has been forbidden can describe that
                 reason in the response payload (if any).

              If authentication credentials were provided in the request, the
                 server considers them insufficient to grant access.  The client
                 SHOULD NOT automatically repeat the request with the same
                 credentials.  The client MAY repeat the request with new or different
                 credentials.  However, a request might be forbidden for reasons
                 unrelated to the credentials.

              An origin server that wishes to "hide" the current existence of a
                 forbidden target resource MAY instead respond with a status code of
                 404 (Not Found).

              Tatsächlich hatte ich nicht ganz Recht damit, zu sagen, 403 sei von Anmeldung oder nicht unabhängig. Es ist eher so:

              Fall 1) Eine Ressource ist nie freigegeben (unabhängig von der Berechtigungsstufe), ihr Aufenthaltsort / ihre Existenz darf aber bekannt sein. Dann sollte von Anfang an 403 kommen und eventuell ein Text, der den Grund des Versteckens erklärt.

              Fall 2) Eine Ressource ist nie freigegeben, ihre Existenz soll nicht bekannt sein. Dann sollte von Anfang an 404 erscheinen.

              Fall 3) Eine Ressource ist ab einer bestimmten Berechtigungsstufe freigegeben. Für unangemeldete Besucher sollte 401 kommen, für angemeldete Nutzer mit nicht-ausreichender Berechtigungsstufe sollte 403 kommen (eventuell mit Möglichkeit, durch andere Anmeldedaten Zugriffsberechtigung zu erhalten).

              Für mich hat ein 403 nicht in einer SuMa aufzutauchen. Und exakt das habe ich in dem Post ausgesagt, den suit kommentiert hat.

              In den Fällen 2 und 3 bekommt eine Suchmaschine als public user bei korrektem Einsatz nie eine 403 zu Gesicht, sondern eine 401 oder eine 404.

              Bleibt noch Fall 1. Ich gebe dir Recht - es macht keinen rechten Sinn, Suchmaschinen in diesem Fall zuzulassen. Denn da steht ja dann maximal der Grund, warum die Ressource für niemanden zur Verfügung steht. Es ist tatsächlich unsinnig, so etwas per Suchmaschine listen zu lassen.

              Grüße,

              RIDER

              --
              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
              ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
            2. Hallo,

              Für mich hat ein 403 nicht in einer SuMa aufzutauchen.

              die Aussage ist ungenau, und mir ist nicht klar, was du genau meinst.

              Selbstverständlich soll ein Server auch einem Bot, wenn er ihn denn als solchen erkennt, den Status 403 signalisieren, wenn die Ressource nicht ohne weiteres zugänglich ist.

              Andererseits sollte eine Suchmaschine Ressourcen, die beim Indizieren mit 403 beantwortet wurden, auch nicht in die Suchergebnisliste aufnehmen. Denn kaum etwas ist ärgerlicher als wenn man beispielsweise per Google etwas sucht, die Liste der Treffer sieht, ein Ergebnis anklickt und dann mit einem 403er (oder auch 404er) abgewiesen wird,

              Der Status 403 sagt aus, dass eine Ressource existiert, aber nur unter ganz bestimmten Voraussetzungen zugänglich ist, die momentan nicht gegeben sind. Von einer Suchmaschine erwarte ich aber, dass sie mir nur Ergebnisse listet, auf die ich auch zugreifen kann. Alles andere wäre ein Ärgernis.

              So long,
               Martin

              --
              Wenn ein Räuber eine deutsche Amtsstube überfällt, welchen Satz kann er sich dann sparen?
              "Keine Bewegung!"
              Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
              1. Mahlzeit,

                Der Status 403 sagt aus, dass eine Ressource existiert, aber nur unter ganz bestimmten Voraussetzungen zugänglich ist, die momentan nicht gegeben sind. Von einer Suchmaschine erwarte ich aber, dass sie mir nur Ergebnisse listet, auf die ich auch zugreifen kann. Alles andere wäre ein Ärgernis.

                Da ich mich nicht drauf verlassen, dass eine SuMa das macht, was ich erwarte, zeige ich ihr nur das, was ich will.
                Ein 403 kann für einen Hacker ein Hinweis sein, da ist was interessantes, da probieren wir doch mal. Evtl. suchen die sogar gezielt nach 403 oder ähnlichem.
                Ausserdem sieht es blöd aus, wenn jemand eine meiner Seiten bei Google sucht und bekommt dann irgendwo ein "Forbidden" um die Ohren gehauen. Sieht einfach nicht einladend aus ;)

                Ich hoffe ich konnte deine Verwirrung vergrössern ;)

                --
                eigentlich ist mir bewusst, dass ich hin und wieder einfach mal die Klappe halten sollte. Doch genau in den unpassendsten Momenten erwische ich mich dabei, wie ich dennoch etwas sage ...
                1. Aloha ;)

                  Ein 403 kann für einen Hacker ein Hinweis sein, da ist was interessantes, da probieren wir doch mal. Evtl. suchen die sogar gezielt nach 403 oder ähnlichem.

                  Deshalb hatte ich ja in meinem Posting das schon so eingeschränkt, dass der 403er eigentlich nur kommen sollte, wenn jemand eingeloggt ist. Ansonsten (uneingeloggt, Ressource für manche verfügbar) 401 oder (wenn Ressource für niemanden verfügbar) 404. Der von mir genannte Fall 1 ist ziemlich hinfällig, denn - da gebe ich dir Recht - das ist wirklich eine Einladung für Hacker.

                  Im übrigen: Natürlich kann man sich drauf verlassen, dass Suchmaschinen Seiten mit 403 (übrigens imho ebenso mit 401 und 404) nicht anzeigen. Wäre auch dämlich. Die Suchmaschine kann nicht davon ausgehen, dass ich mich verbiege und alle 404er per robots.txt ausschließe.

                  Wenn eine Suchmaschine Ergebnisse listet, die einen 4xx-Fehler tragen (Client-Fehler), dann macht die Suchmaschine was falsch. Kein Grund die Seite zu ändern, sondern eher ein Grund a) die Suchmaschine zu ändern oder b) die Suchmaschine zu wechseln.

                  Ich bin kein Freund von SEO als Selbstzweck (das formuliere ich deshalb so, weil die meisten SEO-Regeln auch anders, z.B. durch semantisches Arbeiten abgedeckt werden). Ich vergleiche das etwas überspitzt gerne so: Suchmaschinen sind die Suchsklaven der Anwender. Wir als Webentwickler sind anbietende Dienstleister. Wir sind aber ganz sicher nicht die Sklaven der Suchsklaven. Ein solches Gebahren würde gegen meine Ehre verstoßen. ;)

                  Grüße,

                  RIDER

                  --
                  Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                  ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
                  1. Hallo

                    Im übrigen: Natürlich kann man sich drauf verlassen, dass Suchmaschinen Seiten mit 403 (übrigens imho ebenso mit 401 und 404) nicht anzeigen. Wäre auch dämlich. Die Suchmaschine kann nicht davon ausgehen, dass ich mich verbiege und alle 404er per robots.txt ausschließe.

                    Wenn eine Suchmaschine Ergebnisse listet, die einen 4xx-Fehler tragen (Client-Fehler), dann macht die Suchmaschine was falsch. Kein Grund die Seite zu ändern, sondern eher ein Grund a) die Suchmaschine zu ändern oder b) die Suchmaschine zu wechseln.

                    Du vermischst gerade die Perspektiven. Als Anwender wechsle ich bei Bedarf die Suchmaschine, als Entwickler kann ich das aber nicht. Bestenfalls kann ich die konkrete Suchmaschine per robots.txt ausschließen. Schlimmstenfalls muss ich darüber nachdenken, ob ich mir das leisten kann.

                    Tschö, Auge

                    --
                    Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                    Terry Pratchett, "Wachen! Wachen!"
                    ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
                    Veranstaltungsdatenbank Vdb 0.3
                    1. Aloha ;)

                      Hallo

                      Im übrigen: Natürlich kann man sich drauf verlassen, dass Suchmaschinen Seiten mit 403 (übrigens imho ebenso mit 401 und 404) nicht anzeigen. Wäre auch dämlich. Die Suchmaschine kann nicht davon ausgehen, dass ich mich verbiege und alle 404er per robots.txt ausschließe.

                      Wenn eine Suchmaschine Ergebnisse listet, die einen 4xx-Fehler tragen (Client-Fehler), dann macht die Suchmaschine was falsch. Kein Grund die Seite zu ändern, sondern eher ein Grund a) die Suchmaschine zu ändern oder b) die Suchmaschine zu wechseln.

                      Du vermischst gerade die Perspektiven. Als Anwender wechsle ich bei Bedarf die Suchmaschine, als Entwickler kann ich das aber nicht. Bestenfalls kann ich die konkrete Suchmaschine per robots.txt ausschließen. Schlimmstenfalls muss ich darüber nachdenken, ob ich mir das leisten kann.

                      Bleibt aber die Frage, ob ich mich als Entwickler zum Sklaven von Suchmaschinen machen will. Ich meine: Worüber reden wir hier. Wir reden nicht darüber, eine Seite (lies: eine Domain, ein Projekt...) gänzlich unauffindbar zu machen, sondern nur darüber, ob bestimmte Seiten mit 4xx-Fehlern extra vom Indizieren ausgeschlossen werden sollten oder eben nicht.

                      Ich bin grundsätzlich als Webentwickler eigentlich nicht bereit, Features, die eine Suchmaschine zumindest in meinem Verständnis selbstverständlich haben sollte, auf meinem eigenen Mist nachzubilden (d.h. der Suchmaschine zu sagen: Nein, diese Seite hat einen 4xx-Statuscode, bitte nicht indizieren)...

                      Und nein, ich vermische nicht unbedingt die Perspektiven. Ich halte mir lediglich das Recht vor, meine Seite nicht für jeden abstrusen Anwendungsfall zu verbiegen. Genauso wie ich keine Fallbacks für den IE 6 mehr einbaue, muss ich auch Suchmaschinen, die nicht ordentlich arbeiten, nicht durch Zusatzarbeit besonders unterstützen. (Und auch bei IE-6-Usern würde ich auf die selbe Art und Weise die Perspektiven verbiegen und ihm sagen: Wenn du das ordentlich ansehen willst, dann besorg dir einen aktuellen Browser)

                      Und wer sagt, es sei Zweck einer Suchmaschine auch Seiten mit 403er Statuscode ("Forbidden") anzeigen, der sollte nochmal drüber nachdenken. Mit gleichem Recht müssten dann von dieser Suchmaschine auch alle 404er ("Not Found") gelistet werden...

                      Grüße,

                      RIDER

                      --
                      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                      ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
                      1. Hallo

                        Wenn eine Suchmaschine Ergebnisse listet, die einen 4xx-Fehler tragen (Client-Fehler), dann macht die Suchmaschine was falsch. Kein Grund die Seite zu ändern, sondern eher ein Grund a) die Suchmaschine zu ändern oder b) die Suchmaschine zu wechseln.

                        Du vermischst gerade die Perspektiven. Als Anwender wechsle ich bei Bedarf die Suchmaschine, als Entwickler kann ich das aber nicht. Bestenfalls kann ich die konkrete Suchmaschine per robots.txt ausschließen. Schlimmstenfalls muss ich darüber nachdenken, ob ich mir das leisten kann.

                        Bleibt aber die Frage, ob ich mich als Entwickler zum Sklaven von Suchmaschinen machen will. Ich meine: Worüber reden wir hier. Wir reden nicht darüber, eine Seite (lies: eine Domain, ein Projekt...) gänzlich unauffindbar zu machen, sondern nur darüber, ob bestimmte Seiten mit 4xx-Fehlern extra vom Indizieren ausgeschlossen werden sollten oder eben nicht.

                        Ja, aber wenn du sagst, eine fehlerhafte Implementierung einer Suchmaschine „sei ein Grund a) die Suchmaschine zu ändern oder b) die Suchmaschine zu wechseln“, dann sollte dazugesagt werden, dass diese Aktionen vom suchenden Benutzer der Suchmaschine ausgeführt werden können, aber ohne den von dir negierten Mehraufwand nicht vom Entwickler einer Seite. Als Entwickler hast du keinen Einfluss auf Änderungen an der Schmaschine, du kannst sie bloß draußen halten (Entsprechung des Wechselns).

                        Du kannst die kaputte Suchmaschine ignorieren, du kannst sie alternativ von der Indizierung ausschließen, aber das ist dann „der Mehraufwand“.

                        Ich bin grundsätzlich als Webentwickler eigentlich nicht bereit, Features, die eine Suchmaschine zumindest in meinem Verständnis selbstverständlich haben sollte, auf meinem eigenen Mist nachzubilden (d.h. der Suchmaschine zu sagen: Nein, diese Seite hat einen 4xx-Statuscode, bitte nicht indizieren)...

                        ACK

                        Ich halte mir lediglich das Recht vor, meine Seite nicht für jeden abstrusen Anwendungsfall zu verbiegen.

                        Dann, also wenn du darauf keine Rücksicht nimmst, musst du eben mit den Fehlern einzelner Suchmaschinen leben.

                        Genauso wie ich keine Fallbacks für den IE 6 mehr einbaue, muss ich auch Suchmaschinen, die nicht ordentlich arbeiten, nicht durch Zusatzarbeit besonders unterstützen.

                        Wenn du, wie ich übrigens auch, keine *bewussten* Optimierungen für Suchmaschinen durchführst, unterstützt du auch keine spezielle Suchmaschine durch Zusatzarbeit. ;-)

                        Und, um dich zu zitieren „Worüber reden wir hier“? In den meisten Szenarien, die ich mir vorstellen kann, packt man alles, was nicht jedem zugänglich sein soll, in ein Verzeichnis eventuell samt Unterverzeichnissen. Typischerweise ist dort auch nichts drin, was damit nichts zu tun hat. Dann ist es aber auch kein nennenswerter Mehraufwand, in der robots.txt dieses Verzeichnis von der Indizierung auszuschließen. Ist das schon „verbiegen“?

                        Und wer sagt, es sei Zweck einer Suchmaschine auch Seiten mit 403er Statuscode ("Forbidden") anzeigen, der sollte nochmal drüber nachdenken. Mit gleichem Recht müssten dann von dieser Suchmaschine auch alle 404er ("Not Found") gelistet werden...

                        Dass das so sein soll, habe ich nicht behauptet.

                        Tschö, Auge

                        --
                        Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                        Terry Pratchett, "Wachen! Wachen!"
                        ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
                        Veranstaltungsdatenbank Vdb 0.3
                        1. Aloha ;)

                          ACK. Ich sehe, wir sind im Großen und Ganzen einer Meinung ;)

                          Grüße,

                          RIDER

                          --
                          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                          ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
  5. Authentifizierung

    -> Du wirst erkannt -> wenn du nicht erkannt wirst 403

    401 Unauthorized

    -> Du wirst erkannt hast aber nicht die nötigen Rechte

    So versteh ich das zumindest ... Meistens wird ja nur über Login gesprochen, was aber eigentlich Authenizizierung und Rechteverwaltung beinhaltet.

    MfG
    bubble

    --
    If "god" had intended us to drink beer, he would have given us stomachs. - David Daye