Ich habe mich dieses Jahr dazu entschieden, mich in meiner Firma umzuorientieren – und zwar bin ich ab heute offiziell als Entwickler in Java tätig. Ich bin sehr gespannt und voller Freude, die neuen Herausforderungen zu meistern.
…zumindest mit PHP5 bei Strato.
Nachdem ich jetzt schon ewig bei Strato nach einer Antwort auf mein vermeidliches Sicherheitsrisiko gehofft habe, wurde mir von einem wirklich sehr netten Mitarbeiter die Sachlage so erklärt, dass ich mir einen „Workaround“ schaffen konnte.
Und zwar hatte ich festgestellt, dass man bei Verwendung von PHP5 auf dem Strato-Webangebot die in der PHP-Dokumentation beschriebene Schwachstelle (unter dem Punkt: „Zugriff auf beliebige Web-Dokumente auf dem Server“) bei der Nutzung von PHP als CGI ausnutzen konnte. Diese konnte ich bei Verwendung von PHP4 nicht nachstellen.
Nachdem ich also nun das x-te Mal dieses Verhalten gemeldet hatte, war gestern ein Mitarbeiter von Strato auf der anderen Seite des Telefones, der mir wirklich weiter helfen konnte. Und zwar tritt das Problem nur auf, wenn man „mod_gzip_on“ für seine Webseite nutzt. Also wenn man die Seite an den Browser „gezipt“ übertragen lässt. Nachdem ich diesen Parameter wieder deaktiviert hatte und auf PHP5 umstellte, war alles wie gewünscht: kein „Sicherheitsloch“ mehr, kein komischer Seiteneffekt bei der Nutzung von WordPress.
Die detaillierte Erklärung dieses Mitarbeiters half mir auch zu verstehen, wieso Strato sich auf den, von mir als schwerwiegend empfundenen, Fehler noch nicht gerührt hatte. Die Konfiguration wird wohl in einem der späteren Updates angepasst, aber das „Loch“ ist eben doch nicht so groß wie es mir (ohne das jetzt erworbene Hintergrundwissen) schien.
Mit dieser Lösung kann ich erstmal leben. Und ich finde es sollte mehr von den Supportern wie Herrn T.H. bei der Hotline geben. Es war der erste wo ich mich auch ernst genommen fühlte bei der gemeldeten Störung zu meinem „Sicherheitsproblem“.
von Simon Tatham, Berufsprogrammierer und Programmierer freier Software
Quelle: http://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html
Jeder, der Software für die Allgemeinheit geschrieben hat, wird wahrscheinlich schon einmal einen schlechten Fehlerbericht erhalten haben. Nichts sagende Berichte („Es geht nicht!“), Berichte, die keinen Sinn ergeben, Berichte, die einem nicht genug Informationen geben, Berichte, die einem falsche Informationen geben. Berichte von Problemen, die sich schließlich als Fehlbedienung durch den Benutzer herausstellen, oder bei denen das Problem bei einem anderen Programm liegt oder die auf Netzwerkfehler zurückzuführen sind.
Es gibt einen Grund, warum die Arbeit für eine Anwenderhotline als Horror angesehen wird und dieser Grund sind schlechte Fehlerberichte. Andererseits sind nicht alle Fehlerberichte unangenehm. Wenn ich nicht gerade meinen Lebensunterhalt verdiene, so entwickle und pflege ich freie Software und manchmal erhalte ich wunderbar klare, hilfreiche, informative Fehlerberichte.
In dieser Anleitung werde ich versuchen, Ihnen klarzumachen, was einen guten Fehlerbericht ausmacht. Meine Idealvorstellung wäre es, dass jeder diese Anleitung liest, bevor er irgendwem irgendwelche Fehlerberichte schickt. Auf alle Fälle hätte ich es gerne, dass Leute, die mir Fehlerberichte senden, das hier lesen.
Kurz gefasst ist das Ziel eines Fehlerberichts, es dem Programmierer zu ermöglichen, zu sehen, wie das Programm Fehler macht. Entweder können Sie es ihm persönlich zeigen oder ihm sorgfältige und genaue Informationen geben, wie er es dazu bringt, den Fehler zu machen. Wenn er das schafft, so wird er versuchen weitere Informationen zu sammeln, bis er die Ursache kennt. Wenn er das nicht schafft, so muss er sie bitten die Informationen für ihn zu sammeln.
Versuchen Sie genau auseinander zu halten, was die tatsächlichen Vorkommnisse waren („Ich war am Rechner und dies und das passierte.“) und was Ihre Interpretationen und Spekulationen sind („Ich denke es könnte an Folgendem liegen …“). Wenn Sie es nicht wünschen, so brauchen Sie Ihre Spekulationen nicht mitzuteilen, aber bitte beschreiben Sie alle tatsächlichen Vorkommnisse.
Wenn Sie einen Fehler melden, dann weil Sie ihn repariert haben wollen. Es macht keinen Sinn, den Programmierer zu verfluchen oder absichtlich möglichst wenig hilfreich zu sein: Es mag der Fehler des Programmierers sein, dass Sie ein Problem haben und Sie ärgern sich möglicherweise vollkommen zu Recht über ihn, aber der Fehler wird schneller behoben werden, indem Sie ihm dadurch helfen, dass Sie ihm alle Informationen geben, die er braucht. Übrigens: Wenn es sich um freie Software handelt, haben Sie sie diese aufgrund der Nettigkeit des Autors bekommen. Wenn zu viele Leute sich ihm gegenüber ungehobelt aufführen, lässt diese Nettigkeit vielleicht nach.
Auf http://www.php-security.org/ wurde Anfang März das Month of PHP Bugs-Projekt gestartet. Hoffen wir das sie nicht zu viele Fehler finden ;-)
Tja, so kann es kommen: Ich habe mich schon seit Wochen (Monaten?) darüber gewundert, dass Eclipse beim Debuggen auf meinem Arbeitsrechner sehr langsam ist, wenn man zusätzlich die Variables-View dargestellt hat. Auf den Rechnern meiner Kollegen und bei mir zu Hause war alles bestens.
Das Debuggen war so behäbig, dass bei „schnellem“ Gebrauch von F6 (Step foward) oder dergleichen Eclipse den „Focus verloren“ hat und man explizit wieder auf den aktuellen StackFrame in der Debug-View klicken musste, um weiter steppen zu können….. very annoying!
Ich hatte die Eclipse-Plugins ausgedünnt und sogar meine JDKs neu installiert. Nichts half. Nach jedem Step, der ein Neudarstellen der Werte der Variablen in der Variables-View notwendig machte oder beim Browsen in den Tiefen der Objekte selber ging die CPU-Zeit meines java.exe-Prozesses auf ca. 50% und blieb dort für 1 bis 2 Sekunden… jenachdem, wie komplex der Aufbau des Objekts ist.
Nun, gestern hatte ich ein Aha-Erlebnis: Auf meinem Arbeitsrechner wird mir der Inhalt der der Objekte so dargestellt, wie es die toString()-Methode liefert. Das fehlte mir auf meinem Privatrechner. Mal eben fix eingestellt und alles war schön. Wirklich alles? Nein! Plötzlich war das Debugging ebenso langsam wie auf meinem Arbeitsrechner.
So, nun habe ich diese Option bei mir auf Arbeit wieder abgeschaltet… und, siehe da, Debugging macht wieder Spaß!
Im nachhinein ist es ja auch klar: So ein Aufruf von toString() für jedes Objekt ist natürlich sehr zeitaufwendig. Jetzt muss ich mich eben wieder an das normale Aussehen meiner Variablen beim Debuggen gewöhnen.
Ach ja, für alle, die wissen wollen, wo man diese verheerende Option einstellen kann, habe ich zwei Screenshots angehängt:
Und last, but not least: Alex, alles gute zu Deinem Geburtstag! Soll all das in Erfüllung gehen, was Du Dir selber wünscht.
Willkommen in dieser Kategorie. Hier werden in unregelmäßigen Abständen kleine Meinungen und Erkenntnisse zu Programmier-Problmenen veröffentlicht. Mal sehen, ob sich interessenten finden.