i-netlab: Tipps und Tricks

hi,

da hab ich mir eine halbe Stunde lang die Mühe gemacht in das Eingabeformular zu *Tipps&Tricks* einen kleinen Beitrag einzugeben...

Nach dem Abschicken gab es eine Fehlermeldung dass ein Link fehle...

ok, ich klicke den Backbutton und:

ALLE meine Eingaben sind weg!

Nö Leute, das könnt ich nicht machen - lasst euch bitte was anderes einfallen.

Ich schreib meine Artikel schon immer für das i-netlab

http://i-netlab.de/downloads/notfound.html

Rolf

  1. Hallo Rofl,

    da hab ich mir eine halbe Stunde lang die Mühe gemacht in das Eingabeformular zu *Tipps&Tricks* einen kleinen Beitrag einzugeben...
    Nach dem Abschicken gab es eine Fehlermeldung dass ein Link fehle...
    ok, ich klicke den Backbutton und:
    ALLE meine Eingaben sind weg!

    Verwende einen Browser, der sich gemäß der Spezifikation verhält und Eingaben mit der History speichert, oder stelle das richtig in Deinem Browser ein, sofern das falsch eingestellt war. Ich hatte keine Probleme bei diesem Formular. (Konqueror 3.0.3)

    Oder noch besser: Schreibe den Beitrag in einem Texteditor und kopiere die einzelnen Teile dann in das Formular rein, so dass so etwas nicht passieren kann.

    Grüße,

    Christian

    --
    Sollen sich alle schämen, die gedankenlos sich der Wunder der Wissenschaft und Technik bedienen und nicht mehr davon erfasst haben als eine Kuh von der Botanik der Pflanzen, die sie mit Wohlbehagen frisst.
                          -- Albert Einstein
    1. Hi Christian,

      auf die Minute genau gleichzeitig! Anscheinend interessieren wir uns momentan für die gleichen Threads quer durchs inzwischen ganz schön lange Forum !? Schönen Sonntag noch!

      Mathias Bigge

      --
      http://www.selfaktuell.teamone.de/tippstricks/index.htm
      Beitrag verfassen - das history-Konzept verstehen
      1. Hallo Mathias,

        Anscheinend interessieren wir uns momentan für die gleichen Threads quer durchs inzwischen ganz schön lange Forum !?

        CK sei dank... Das neue Forum ist einfach genial, wenn man den Überblick behalten will.

        Schönen Sonntag noch!

        Ebenso. :)

        Grüße,

        Christian

        --
        Sollen sich alle schämen, die gedankenlos sich der Wunder der Wissenschaft und Technik bedienen und nicht mehr davon erfasst haben als eine Kuh von der Botanik der Pflanzen, die sie mit Wohlbehagen frisst.
                              -- Albert Einstein
    2. hi,

      Hallo Rofl,

      da hab ich mir eine halbe Stunde lang die Mühe gemacht in das Eingabeformular zu *Tipps&Tricks* einen kleinen Beitrag einzugeben...
      Nach dem Abschicken gab es eine Fehlermeldung dass ein Link fehle...
      ok, ich klicke den Backbutton und:
      ALLE meine Eingaben sind weg!

      Verwende einen Browser, der sich gemäß der Spezifikation verhält und Eingaben mit der History speichert, oder stelle das richtig in Deinem Browser ein, sofern das falsch eingestellt war. Ich hatte keine Probleme bei diesem Formular. (Konqueror 3.0.3)

      Jow! Poste mal ne Liste mit den Browsern welche für dieses Formular getestet wurden und ich sage dir dann ob meiner dabei ist.

      Oder noch besser: Schreibe den Beitrag in einem Texteditor und kopiere die einzelnen Teile dann in das Formular rein, so dass so etwas nicht passieren kann.

      Falsch verstanden! Das To Do liegt nicht auf der Seite des Benutzers (wie ich schon sagte).

      Schönen Sonntag, Rolf

      1. Die Leute hier sind da, um dir zu helfen wenn du ein
        Problem hast, nicht, daß du ihre Programmierarbeit
        schlechtmachst. Und dann schreiben wieder andere was
        über "gereizte Stimmung im Forum"!

        1. Hi AB,
          Recht hast Du, ich bin aber nicht sauer, der gute fühlte sich vielleicht ein bisschen auf den Arm genommen. Solche Sachen passieren aber auch Profis, dann ärgert man sich halt ein bisschen. Kommt schon wieder ins Lot!
          Viele Grüße
          Mathias Bigge

          --
          http://www.selfaktuell.teamone.de/tippstricks/index.htm
          Beitrag verfassen - die innere Mitte wiederfinden!
        2. hi AB,

          Die Leute hier sind da, um dir zu helfen wenn du ein
          Problem hast, nicht, daß du ihre Programmierarbeit

          Du hast überhaupt nichts verstanden. Nicht ich hab ein Problem.

          schlechtmachst. Und dann schreiben wieder andere was

          Mach ich nicht. Ganz im Gegenteil: Ich weise lediglich darauf hin dass das Formular für die Erfassung von *Tipps&Tricks* schlecht gemacht ist. Das ist ganz einfach eine konstruktive Kritik, nicht mehr und nicht weniger.

          Schönen Sonntag, Rolf

          über "gereizte Stimmung im Forum"!

          nicht mein problem.

    3. Verwende einen Browser, der sich gemäß der Spezifikation verhält und Eingaben mit der History speichert

      Welche Spezifikation soll denn das sein?

      H.

      1. Hallo Henner,

        Welche Spezifikation soll denn das sein?

        Ich dachte, das wäre die HTTP-Spezifikation (RFC 2616), aber da steht das tatsächlich nicht drinnen, unter Punkt 13.13 steht nur etwas, das dieses Verhalten durchaus zulässt, jedoch nicht impliziert.

        Tja, dann habe ich mich wohl nicht geirrt.

        Grüße,

        Christian

        --
        Sollen sich alle schämen, die gedankenlos sich der Wunder der Wissenschaft und Technik bedienen und nicht mehr davon erfasst haben als eine Kuh von der Botanik der Pflanzen, die sie mit Wohlbehagen frisst.
                              -- Albert Einstein
  2. Hi i-netlab, sorry,

    eigentlich sollte das natürlich nicht passieren, aber "shit happens", wie die Amerikaner sagen. In Kürze wird es ein Template, das Orlando bereits fertiggestellt hat, und eine e-mail-Redaktionsanschrift geben, so dass Du eine Alternative zu der Arbeit mit dem Formular hast, das aber normalerweise zuverlässig funktioniert. Hattest Du vielleicht zu schnelle Finger?

    1. Was wird das denn für ein Beitrag?
    2. Ich bau das Template und die e-mail in den nächsten Tagen ein. (Als Experte weißt Du, dass Du Dir mit dem Formular auch sehr leicht selbst ein Template basteln kannst?)

    Viele Grüße
    Mathias Bigge
    Redaktion Tipps&Tricks

    --
    http://www.selfaktuell.teamone.de/tippstricks/index.htm
    Beitrag verfassen - volle Zeigerfingerklickkontrolle erreichen *g*
  3. Hallo Rolf,

    »

    http://i-netlab.de/downloads/notfound.html

    Im Script steht:
    require 'html-lib.pl';

    Der wird aber nicht erklärt, für jemanden der sich auskennt ist das wohl kein Problem, aber der braucht den Script wohl auch nicht.
    Für jemanden der davon nicht so viel versteht - like me - heisst es, der Script funktioniert u.u. nicht und dann weiss man nicht warum.

    Noch eine Frage: ist der Script sicher von Missbrauch? D.H. kann dieser Script dazu missbraucht werden, spam mails zu versenden?

    Grüße
    Thomas

    1. hi Thomas,

      Im Script steht:
      require 'html-lib.pl';

      Der wird aber nicht erklärt, für jemanden der sich auskennt ist

      auf der Indexseite meines Script-Bereiches habe ich einen Hinweis, dass die 'html-lib.pl' in fast allen meiner Scripts verwendet wird, die 'html-lib.pl' selbst ist auch im Index:

      http://i-netlab.de/downloads/

      Noch eine Frage: ist der Script sicher von Missbrauch? D.H. kann dieser Script dazu missbraucht werden, spam mails zu versenden?

      Das von mir geschriebene Script *404.cgi* hat die folgende Aufgabe:
      1. Einen Request auf eine nicht vorhandene Seite umleiten auf eine eigens definierte *Sorry-Seite*,
      2. Einen Request nach *regulären Ausdrücken* zu handlen,
      3. Einen Request auf *bekannte CGI Scripts welche Sicherheitslücken haben* zu handlen...

      Die Definition der entsprechenden Kontrollstruktur steht jedem Nutzer frei der dieses Script einsetzt.

      Rolf

      =Beispiel 404.cgi Kontrollstruktur

      Ersteinmal die Reqs. auf alte URLs umleiten:

      if( $rq =~ /nslookup/ or $rq =~ /lchk/ or $rq =~ /whichserver/){ redir("/webtools") }
      elsif( $rq =~ /show_script/ or $rq =~ /mailform/ or $rq =~ /download/ ){ redir("/downloads") }
      elsif( $rq =~ /tungus/ ){ redir("/private/tunguska")}
      elsif( $rq =~ /hobby/ ){ redir("/private") }
      elsif( $rq =~ /404.cgi/){ redir("/404.html")}
      elsif( $rq =~ /trech/ ){ redir("/article")}
      elsif( $rq =~ /guestbook/ ){ redir("/about.html")}
      elsif( $rq =~ /board/ ){ redir("/index.shtml")}
      elsif( $rq =~ /cgi-bin/(.*)/i){ # hier alle anderen Reqs. auf cgi-bin/
       print "Content-type: text/html\n\n";
       a_html "I-NetLab Verwarnung","/nv.css";
       verwarnung $1;
       $zeit = strftime("%d.%m.%Y %X", localtime);

      # Mesg. zusammenbauen (fuer die Mail)
       my $host = revlookup($ENV{'REMOTE_ADDR'});
       $msg .= qq(
      REQUEST_URI: $ENV{'REQUEST_URI'}
      REMOTE_ADDR: $ENV{'REMOTE_ADDR'}
      REDIRECT_ERROR_NOTES: $ENV{'REDIRECT_ERROR_NOTES'}
      HTTP_REFERER $ENV{'HTTP_REFERER'}
      DIALINHOSTNAME: $host
      EreignisZeit: $zeit
       );

      mail($smtp_host, $rcpt, $subject, $msg, $abs_email) and print qq(<p><b>Mail an Webmaster...</b>);
       z_html;
      }
      else{redir("/404.html");} # Alles was nicht gefunden wurde

      =cut

      1. Hallo Rolf,

        auf der Indexseite meines Script-Bereiches habe ich einen Hinweis, dass die 'html-lib.pl' in fast allen meiner Scripts verwendet wird, die 'html-lib.pl' selbst ist auch im Index:

        Ok, da steht es in der Tat.

        Noch eine Frage: ist der Script sicher von Missbrauch? D.H. kann dieser Script dazu missbraucht werden, spam mails zu versenden?

        Das von mir geschriebene Script *404.cgi* hat die folgende Aufgabe:

        1. Einen Request auf eine nicht vorhandene Seite umleiten auf eine eigens definierte *Sorry-Seite*,

        Verstehe ich nicht. Die .htaccess im document-root macht ja das selbe. ErrorDocument 404 http://i-netlab.de/404.html wozu ein umleitung über ein Script auf die 404 Datei?

        1. Einen Request nach *regulären Ausdrücken* zu handlen,

        Wie meinst du das?

        1. Einen Request auf *bekannte CGI Scripts welche Sicherheitslücken haben* zu handlen...

        Ok, ich habe jetzt bei dir nach http://i-netlab.de/cgi-bin/adsflkaksdhfljfdsfgg.cgi gesucht und die Warnung gesehen.
        Aber was bringt mir dieses Feature? Ich kann im cgi-bin selbst ein .htaccess Datei anlegen und dort bestimmen woher Zugriffe erfolgen können und wenn jemand nach einem nichtexistenten script sucht, gilt eh 404 im root.
        Außerdem wie soll dieser Script eventuelle Sicherheitslücken in anderen Scripten verhindern?

        Die Definition der entsprechenden Kontrollstruktur steht jedem Nutzer frei der dieses Script einsetzt.

        Rolf

        =Beispiel 404.cgi Kontrollstruktur

        das ist aber nicht das was du vorher verlink hast:
        http://i-netlab.de/cgi-bin/split.cgi?404
        und mir sagt das sowieso so gut wie nichts.

        Grüße
        Thomas

        1. Moin,

          das von mir vorgestellte Konstrukt .htaccess + 404.cgi erlaubt es bei bestimmten Requests auch eine Mail zu versenden was mit einer .htaccess alleine nicht geht. Damit werden für mich die fehlerhaften Zugriffe transparenter und ich kann gezielt umleiten. Das ist eine Ergänzung zur Auswertung der Statistiken und dem Blick ins Logfile.

          Schönen Tag, Rolf

  4. Moin!

    Nö Leute, das könnt ich nicht machen - lasst euch bitte was anderes einfallen.

    Ich hab volles Verständnis für deinen Unmut - entweder es funktioniert wie gewünscht, oder es rettet zumindest die Daten. Naja, das Formular ist halt schnell mal entstanden und so gesehen noch Beta. Schade, dass du auf diese Weise Fehler findest.

    Wie schon erwähnt: Ein Browser, der eine standard-gemäße History-Funktion realisiert, hätte geholfen. Opera ist so ein Browser. Vom IE und Mozilla/Netscape (egal welche Version) kann man das leider nicht sagen - die rufen beim "Zurück" in der Regel die Seite neu vom Server ab, und in dieser Seite fehlen natürlich deine Eingaben.

    Ich schreib meine Artikel schon immer für das i-netlab

    http://i-netlab.de/downloads/notfound.html

    Zum Artikel noch eine wichtige Anmerkung:
    Mit dem ersten Beispiel:
    ErrorDocument 404 http://domain.tld/pfad/404seite.html
    leitest du den Benutzer _per Redirect_ auf die Fehlerseite. D.h. der User-Agent erhält einen Redirect (301 oder 302) und ruft dann ganz offiziell die 404-Seite ab - mit dem Statuscode 200. Es erfolgt _keinerlei_ Ausgabe eines Statuscodes 404.

    Diese Verhaltensweise ist wahrscheinlich aber nicht erwünscht. Erstens: Die URL der Fehlerseite erscheint im Browser. Das macht es bei Tippfehlern in der ursprünglichen URL schwer, diese mal eben schnell zu korrigieren.

    Zweitens: Clients, die den Statuscode 404 auswerten (wie zum Beispiel Suchmaschinen, Linkchecker etc), kriegen bei dieser Konfiguration keinen Status 404 vorgesetzt, sondern einen Redirect auf eine real existierende Seite (dass diese von "URL nicht gefunden" quatscht, versteht ein Computer in der Regel nicht). Wenn du Pech hast, aktualisiert z.B. eine Suchmaschinen den falschen Link so, dass er zukünftig auf deine Fehlerseite zeigt. Und auch dein Logfile enthält keinerlei 404-Codes, so dass du auch Verlinkungsfehler auf deiner eigenen Site nicht findest, wenn du nach 404-Codes suchst.

    Deshalb: Lieber wie im zweiten Beispiel mit der CGI-Seite einfach einen absoluten Pfad _ohne_ Domainangabe machen. Das sorgt dafür, dass statt der Standardfehlerseite die eigene Alternative gezeigt wird - und dass der Statuscode 404 ausgeliefert und in die Logfiles geschrieben wird.

    Die Variante mit Redirect ist wirklich nur dann sinnvoll, wenn fehlerhafte URLs wirklich _umgeleitet_ werden sollen, beispielsweise auf eine Suchmaschine auf einem anderen Server, welcher unter einer anderen Domain erreichbar ist. Es ist aber ohne Probleme möglich, auf der normalen Fehlerseite ein Suchformular einzubauen, so dass der Benutzer nicht kommentarlos auf die Suchmaschine gelangt, sondern über den URL-Fehler informiert wird und ggf.

    - Sven Rautenberg

    --
    Diese Signatur gilt nur am Freitag.
    1. Hallo Sven,

      Vom IE und Mozilla/Netscape (egal welche Version) kann man das leider nicht sagen - die rufen beim "Zurück" in der Regel die Seite neu vom Server ab, und in dieser Seite fehlen natürlich deine Eingaben.

      Ich habe, wie ich vor einiger Zeit schon mal gepostet habe, die gegenteilige Erfahrung mit dem Mozilla gemacht. Denn beim Posten hier im Forum kann ich einen Text eingeben und sogar die Seite neu laden, ohne dass der Text verschwindet. Es können sogar Antworten zum Thread dazukommen, ohne dass die Eingaben verloren gehen. Ich hab' am Caching bzw. der History nichts verändert in den Einstellungen, außer dass ich den Plattencache abgeschaltet und den RAM-Cache vergrößtert habe... (und das wirds wohl nicht gewesen sein) Ich hab's gerade noch mal getestet. Auch mit dem Zurück-Knopf hatte ich in der Richtung noch keine Probleme. (wie gesagt: Mozilla, den IE spreche ich jetzt mal lieber nicht an)

      Grüße,

      Christian

      P.S.: Mein Posting beruht nur auf subjektiven Erfahrungen von mir und ist nicht als "die absolute Wahrheit"[tm] zu nehmen...

      --
      Sollen sich alle schämen, die gedankenlos sich der Wunder der Wissenschaft und Technik bedienen und nicht mehr davon erfasst haben als eine Kuh von der Botanik der Pflanzen, die sie mit Wohlbehagen frisst.
                            -- Albert Einstein
    2. Hallo Sven,

      Nö Leute, das könnt ich nicht machen - lasst euch bitte was anderes einfallen.

      Ich hab volles Verständnis für deinen Unmut - entweder es funktioniert wie gewünscht, oder es rettet zumindest die Daten. Naja, das Formular ist halt schnell mal entstanden und so gesehen noch Beta. Schade, dass du auf diese Weise Fehler findest.

      Wie schon erwähnt: Ein Browser, der eine standard-gemäße History-Funktion realisiert, hätte geholfen. Opera ist so ein Browser. Vom

      bloooß nicht! Der Opera ist nicht nur buggy sondern
      total verlaust ;-)

      IE und Mozilla/Netscape (egal welche Version) kann man das leider nicht sagen - die rufen beim "Zurück" in der Regel die Seite neu vom Server ab, und in dieser Seite fehlen natürlich deine Eingaben.

      Auf jeden Fall ist das für mich auch ein ToDo weil ich ab und zu mal meinen Kollegen ein Formular vor die Nase setze und damit solche Situationen kenne (psst...).

      Ich schreib meine Artikel schon immer für das i-netlab

      http://i-netlab.de/downloads/notfound.html

      Zum Artikel noch eine wichtige Anmerkung:
      Mit dem ersten Beispiel:
      ErrorDocument 404 http://domain.tld/pfad/404seite.html
      leitest du den Benutzer _per Redirect_ auf die Fehlerseite. D.h. der User-Agent erhält einen Redirect (301 oder 302) und ruft dann ganz offiziell die 404-Seite ab - mit dem Statuscode 200. Es erfolgt _keinerlei_ Ausgabe eines Statuscodes 404.

      Diese Verhaltensweise ist wahrscheinlich aber nicht erwünscht. Erstens: Die URL der Fehlerseite erscheint im Browser. Das macht es bei Tippfehlern in der ursprünglichen URL schwer, diese mal eben schnell zu korrigieren.

      Zweitens: Clients, die den Statuscode 404 auswerten (wie zum Beispiel Suchmaschinen, Linkchecker etc), kriegen bei dieser Konfiguration keinen Status 404 vorgesetzt, sondern einen Redirect auf eine real existierende Seite (dass diese von "URL nicht gefunden" quatscht, versteht ein Computer in der Regel nicht). Wenn du Pech hast, aktualisiert z.B. eine Suchmaschinen den falschen Link so, dass er zukünftig auf deine Fehlerseite zeigt. Und auch dein Logfile enthält keinerlei 404-Codes, so dass du auch Verlinkungsfehler auf deiner eigenen Site nicht findest, wenn du nach 404-Codes suchst.

      Deshalb: Lieber wie im zweiten Beispiel mit der CGI-Seite einfach einen absoluten Pfad _ohne_ Domainangabe machen. Das sorgt dafür, dass statt der Standardfehlerseite die eigene Alternative gezeigt wird - und dass der Statuscode 404 ausgeliefert und in die Logfiles geschrieben wird.

      Die Variante mit Redirect ist wirklich nur dann sinnvoll, wenn fehlerhafte URLs wirklich _umgeleitet_ werden sollen, beispielsweise auf eine Suchmaschine auf einem anderen Server, welcher unter einer anderen Domain erreichbar ist. Es ist aber ohne Probleme möglich, auf der normalen Fehlerseite ein Suchformular einzubauen, so dass der Benutzer nicht kommentarlos auf die Suchmaschine gelangt, sondern über den URL-Fehler informiert wird und ggf.

      Hmm, das ist wirklich mal was mit dem ich was anfangen kann. Denn: Ich hab nunmal das Problem dass einige meiner Seiten wech sind und Suchmaschinen diese Teile immer noch indizieren. Meine Frage vor einiger Zeit dazu *wie gebe ich einen 404 zurück und zeige meinem Besucher _gleichzeitig_ eine nette Seite ggf. mit Alternativen* ist hier in diesem Forum ohne Antwort geblieben...

      Wie auch immer, für meine Begriffe ist's ersteinmal wichtig dem Besucher einen entsprechenden Hinweis zu geben!

      Diesem grundlegenen Gedanken dient letztendlich auch das Script
      404.cgi, try this: http://i-netlab.de/scr or this:
      http://i-netlab.de/down - stets landet der Besucher im meinem Downlaodbereich. Wehe dem jedoch der
      http://i-netlab.de/cgi-bin/formmail.pl versucht! Das ist ein Request auf ein Script was *offiziell* dafür bekannt ist dass Sicherheitslücken aufweist (siehe xwolf - Liste) und einem solchen Request begegnet das Script 404.cgi entsprechend (Hinweis auf rechtliche Schritte, Mail an Webmaster...).

      Gerne stellte ich diesen Artikel auch SELF*:TIPPS&TRICKS zur Verfügung. Aber nicht unter den Bedingungen die ich bisher vorfand.

      In der Hoffnung dass sich das ändert ;-)
      Rolf

      1. Moin!

        Hmm, das ist wirklich mal was mit dem ich was anfangen kann. Denn: Ich hab nunmal das Problem dass einige meiner Seiten wech sind und Suchmaschinen diese Teile immer noch indizieren. Meine Frage vor einiger Zeit dazu *wie gebe ich einen 404 zurück und zeige meinem Besucher _gleichzeitig_ eine nette Seite ggf. mit Alternativen* ist hier in diesem Forum ohne Antwort geblieben...

        Muss ich wohl übersehen haben.

        Allerdings verweise ich in diesem Zusammenhang mal auf die Möglichkeiten der .htaccess-Datei und deren Möglichkeiten.

        Mit der Direktive "Redirect" bzw. "RedirectMatch" hast du die Möglichkeit, Zugriffe auf gewisse URLs umzuleiten. RedirectMatch ist dabei recht mächtig, weil es mit regulären Ausdrücken arbeitet.

        Ansonsten hast du natürlich auch immer die Möglichkeit, mit URL-Rewriting zu arbeiten.

        Das W3C sagt übrigens dazu: "Cool URIs don't change". Soll heißen: Überlege dir ein _vernünftiges_ [1] URL-Schema, welches auch in 2, 20 oder 200 Jahren noch sinnvollen Zugriff auf alle deine Informationen bietet. Wie du dahinter deine Informationen organisierst, ist für den Benutzer vollkommen uninteressant. Das W3C hat sich in dieser Hinsicht eigentlich eine sehr vernünftiges Schema ausgedacht: www.w3.org/thema/unterthema/jahreszahl/dateiname. Gute Beispiele sind in [1] erwähnt.

        Beachte auch, dass in einer guten URI _keine_ Hinweise auf die verwendeten Techniken vorkommen. ".html" ist fehl am Platze (was ist, wenn du auf XHTML wechselst? Alles umbenennen?). "cgi-bin" ist fehl am Platze (die CGI-Schnittstelle kann ja irgendwann mal durch etwas viel besseres ersetzt werden).

        [1] http://www.w3.org/Provider/Style/URI.html

        Wie auch immer, für meine Begriffe ist's ersteinmal wichtig dem Besucher einen entsprechenden Hinweis zu geben!

        Diesem grundlegenen Gedanken dient letztendlich auch das Script
        404.cgi, try this: http://i-netlab.de/scr or this:
        http://i-netlab.de/down - stets landet der Besucher im meinem Downlaodbereich.

        Naja, das ist nichts, was nicht per Redirect auch ginge. Warum du allerdings deine URLs geändert hast, ist die größere und interessantere Frage. Ohne Änderung würde die Notwendigkeit des CGI-Skriptes entfallen. Und außerdem mußt du natürlich dafür sorgen, die richtigen Status-Codes auszugeben. Wenn du Zugriffe auf /down umlenken willst, mußt du ein Redirect ausgeben (301 bzw. 302 - je nachdem. Ein permanenter Redirect ist sinnvoll - dann stellen auch Suchmaschinen ihren Index mal um). Wenn du hingegen nichts passendes findest, mußt du Status 404 ausgeben. Das gilt auch für deine Angriffsseite.

        Wehe dem jedoch der
        http://i-netlab.de/cgi-bin/formmail.pl versucht! Das ist ein Request auf ein Script was *offiziell* dafür bekannt ist dass Sicherheitslücken aufweist (siehe xwolf - Liste) und einem solchen Request begegnet das Script 404.cgi entsprechend (Hinweis auf rechtliche Schritte, Mail an Webmaster...).

        Naja, da schießt du doch etwas mit Kanonen auf Spatzen. Nicht jeder, der /cgi-bin/formmail.pl auf deinem Server erreichen will, ist dafür auch selbst verantwortlich, und nicht jedes Programm, was formmail.pl heißt, muß von Matt Wright kommen und Sicherheitslücken aufweisen. Ein schlichter 404-Status "Nicht gefunden" und ein aufmerksames Lesen der Logfiles sollten doch ausreichen. Wenn nämlich kein formmail.pl existiert, dann kann man es nicht hacken. Wo ist das Problem? Auch ein Portscan ist kein Angriff. Ich würde es mit "Angucken eines Hauses, ob es Türen oder Fenster hat" vergleichen. Wenn du nicht willst, dass dein Haus gesehen wird, sorge für dauerhafte Dunkelheit, oder tarne Türen und Fenster als Mauer.

        Gerne stellte ich diesen Artikel auch SELF*:TIPPS&TRICKS zur Verfügung. Aber nicht unter den Bedingungen die ich bisher vorfand.

        Nimm eine der bestehenden Tipps&Tricks-Seiten, lösche den alten Inhalt, füge den neuen Inhalt ein, und maile diese Seite an Mathias Bigge (der hat die zentrale Verwaltung für T&T-Artikel). Das ist das, was mir als Lösungsmöglichkeit dazu einfällt.

        In der Hoffnung dass sich das ändert ;-)

        Wenn wir dir Opera zwangsinstalliert hätten, würdest du doch sicherlich auch meckern, oder? :)

        - Sven Rautenberg

        --
        Diese Signatur gilt nur am Freitag.
        1. Hallo Sven,

          vielen Dank für Deine Hinweise. Mein Script werde ich heute abend noch einmal überarbeiten, es ermöglicht mir genau das was ich haben will: Status 404 zurückgeben und _gleichzeitig_ dem Benutzer eine entsprechende Seite (je nachdem...) anzeigen - ohne dass in der Serverkonfiguration was geändert werden muss ;-)

          Gruss aus KA, Rolf

        2. Hi Sven Rautenberg, liebe Kollegen,

          es gibt in Kürze ein Template, für Leute, die Probleme mit dem Formular haben.

          Nimm eine der bestehenden Tipps&Tricks-Seiten, lösche den alten Inhalt, füge den neuen Inhalt ein, und maile diese Seite an Mathias Bigge (der hat die zentrale Verwaltung für T&T-Artikel). Das ist das, was mir als Lösungsmöglichkeit dazu einfällt.

          Ist eine Lösungsmöglichkeit. Adresse: siehe oben. Man kann sich auch mit Hilfe des Forumlars ein Template bauen. Zitat aus dem Formularkopf:

          "Wenn Sie für sich eine Rohvorlage erstellen wollen, geben Sie einfach alles ein und senden Sie das Formular ab. Solange Sie keine E-Mail-Adresse eingeben, wird nichts gespeichert. Ein Preview wird aber erstellt. Dann können Sie den Beitrag auch später als Datei mit den zugehörigen Beispielen an die Redaktion schicken."

          Wenn man nur ein paar Dummys eingibt, gibt's ein (fast) leeres Template.

          Vielleicht doch mal ganz kurz zu der interessanten, zum Teil recht abstrakten Debatte, die ja ganz richtig in die allgemeine Richtung gehen musste, da das Formular von Antje eben ein ganz normales Standardformular ist, bei dem weder im IE noch im Mozilla in den Standardeinstellungen die Daten durch simples Bewegung in der history überschrieben werden, was immer auch die Normen sagen (übrigens überstehen die Daten im Formular sowohl im IE 5.5 als auch im Mozilla selbst einen Reload ohne Löschen; weil ich so langsam nachdenklich wurde, habe ich diese triviale Behauptung überprüft - man gönnt sich ja sonst nichts..... *g*)

          Zur Verbesserung des Formulars: Vielleicht müssten wir die Preview-Funktion nochmal überarbeiten, so dass auch mit eingegebener e-mail-Adresse keine Daten verloren gehen, wenn was fehlt. Ist ja einfach zu ärgerlich. Ich mail nochmal die gute Antje an, die hier anscheinend wegen Arbeitsstress momentan nicht mitliest, sonst hätte sie sich sicher schon eingemischt.

          Viele Grüße
          Mathias Bigge

    3. Hallo Sven,

      Vom IE und Mozilla/Netscape (egal welche Version) kann man
      das leider nicht sagen - die rufen beim "Zurück" in der
      Regel die Seite neu vom Server ab, und in dieser Seite
      fehlen natürlich deine Eingaben.

      Das ist inkorrekt. Mozilla nimmt, wenn ein Cache-Header
      geschickt wurde, die Seiten solange aus dem Cache, wie er
      darf. Wurde keiner geschickt, schickt er ein conditional get.

      Gruesse,
       CK

      1. Moin!

        Hallo Sven,

        Vom IE und Mozilla/Netscape (egal welche Version) kann man
        das leider nicht sagen - die rufen beim "Zurück" in der
        Regel die Seite neu vom Server ab, und in dieser Seite
        fehlen natürlich deine Eingaben.

        Das ist inkorrekt. Mozilla nimmt, wenn ein Cache-Header
        geschickt wurde, die Seiten solange aus dem Cache, wie er
        darf. Wurde keiner geschickt, schickt er ein conditional get.

        Ja, aber das ist das Problem: Er nimmt sie aus dem _Cache_, wenn er darf, ansonsten fordert er sie neu an. So schlau ist der IE sicher auch. Der History-Mechanismus erlaubt aber keinen Zugriff auf den Cache oder Neuanforderung, sofern der User das nicht konfiguriert hat:

        "User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session. By default, the Expires field does not apply to history mechanisms. If the entity is still in storage, a history mechanism should display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents."
        (Quelle: RFC 1945, Abschnitt 10.7 "Expires")

        Das bedeutet ganz schlicht und einfach, dass der User-Agent beim Navigieren mit Back- und Forward-Funktionen die Seite nicht neu zu laden hat - egal ob sie mittlerweile ungültig geworden ist oder nicht.

        "An expiration time cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource is initiated. See section 13.13 for explanation of the difference between caches and history mechanisms."
        (Quelle: RFC 2068, Abschnitt 13.2.1. "Server-Specified Expiration")
        sowie
        "History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved."
        (Quelle: RFC 2068, Abschnitt 13.13. "History Lists")
        sind in dieser Hinsicht absolut unmißverständlich.

        Wo der Browser den mit History-Funktion angeforderten letztgesehenen Zustand wieder herholt, ist den Browserprogrammierern überlassen - das darf auch der Cache sein, wenn sichergestellt ist, dass die History-Funktion ordnungsgemäß funktioniert. Denn ein mögliches Szenario wäre ja, dass in einem Browserfenster eine alte Version der Ressource mittels History angesteuert wird, während in einem anderen Fenster zuvor die aktuelle Version der Ressource vom Server geladen wurde. Und da sich Ressourcen durchaus bei zwei Requests unterschiedlich darstellen können (auch hier im Forum ist das so: Wenn z.B. ein Beitrag archiviert ist, kriegt man eine Fehlermeldung - mit History muß man ihn aber immer noch erreichen können, wenn man ihn in dieser Browsersession schon mal gesehen hat und er mit "Back" und/oder "Forward" noch erreichbar ist), kann man den Cache eigentlich nicht als Datenquelle für die History verwenden.

        - Sven Rautenberg

        --
        Diese Signatur gilt nur am Freitag.
        1. Moin!

          "History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved."
          (Quelle: RFC 2068, Abschnitt 13.13. "History Lists")

          Die RFC 2068 ist mittlerweile obsolet, aber die an ihre Stelle getretene RFC 2616 enthält das Zitat (und den restlichen Text zu diesem Thema) immer noch.

          - Sven Rautenberg

          --
          Diese Signatur gilt nur am Freitag.
        2. Hallo Sven,

          Ja, aber das ist das Problem: Er nimmt sie aus dem
          _Cache_, wenn er darf, ansonsten fordert er sie neu an.
          So schlau ist der IE sicher auch. Der History-Mechanismus
          erlaubt aber keinen Zugriff auf den Cache oder
          Neuanforderung, sofern der User das nicht konfiguriert hat:

          "User agents often have history mechanisms, such as "Back"
          buttons and history lists, which can be used to redisplay
          an entity retrieved earlier in a session. By default, the
          Expires field does not apply to history mechanisms. If the
          entity is still in storage, a history mechanism should
          display it even if the entity has expired, unless the user
          has specifically configured the agent to refresh expired
          history documents."
          (Quelle: RFC 1945, Abschnitt 10.7 "Expires")

          Das bedeutet ganz schlicht und einfach, dass der
          User-Agent beim Navigieren mit Back- und
          Forward-Funktionen die Seite nicht neu zu laden hat - egal
          ob sie mittlerweile ungültig geworden ist oder nicht.

          Nein, das bedeutet, dass er es handhaben kann, wie er will.
          Da steht: 'If the entity is still in storage'. Damit ist
          alles, was die RFC sonst darueber sagt, hinfaellig und
          lediglich eine Empfehlung. Denn was der Browser wie speichert
          bleibt ihm ueberlassen, denn:

          "An expiration time cannot be used to force a user agent
          to refresh its display or reload a resource; its semantics
          apply only to caching mechanisms, and such mechanisms need
          only check a resource's expiration status when a new
          request for that resource is initiated. See section 13.13
          for explanation of the difference between caches and
          history mechanisms."

          Damit wird klar, dass User-Agents das lediglich als eine
          Empfehlung zu sehen brauchen.

          sowie
          "History mechanisms and caches are different. In
          particular history mechanisms SHOULD NOT try to show a
          semantically transparent view of the current state of a
          resource. Rather, a history mechanism is meant to show
          exactly what the user saw at the time when the resource
          was retrieved."

          Wird hier sogar nochmal ganz deutlich: das ist ein SHOULD.

          sind in dieser Hinsicht absolut unmißverständlich.

          Ganz im Gegenteil. Dieser Standard, wie viele andere
          Standards leider auch, laesst viel Platz fuer
          Interpretationen.

          Davon ganz abgesehen sind die Formular-Elemente im Mozilla
          solange weiterhin mit den Daten befuellt, wie man nicht
          explizit einen absoluten Refresh anfordert.

          Gruesse,
           CK

          1. Hi Christian,

            Wird hier sogar nochmal ganz deutlich: das ist ein SHOULD.
            ...
            Ganz im Gegenteil. Dieser Standard, wie viele andere
            Standards leider auch, laesst viel Platz fuer Interpretationen.

            RFC2616 definiert allerdings, daß derjenige, der in seiner Implementierung auch nur _ein_ SHOULD nicht unterstützt, damit zum Standard nur noch "conditionally compliant" ist und nicht mehr "unconditionally compliant":

            http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.2

            Viele Grüße
                  Michael

            --
            T'Pol: I meant no insult.
            V'Lar: Of course not. You're simply speaking your mind ... as you always have.