Auch wieder ein simple Sache, die sich ohne weiteres im SVN Handbuch oder der manpage nachlesen lässt. In schicken SVN Tools bereits integriert - auf der Shell muss das Feature manuell gewusst werden.
Wer eine ausgecheckte Version mit einer Revisionierten vergleichen möchte, kann das mit
svn diff -r {rev_nr} lokale_datei.php
tun. {rev_nr} muss die Nummer einer Revision sein, in der die Datei verändert wurde, sonst wird schlicht nichts ausgegeben.
Haach, wie herrlich kann bloggen sein! Grad läuft’s mal wieder: Ein Kommentar zum letzten Artikel bringt mich auf eine Idee zum Nächsten. Ihr habt’s bestimmt schon bemerkt - ich versuche mich immer mal wieder in schönen unsachlichen Ausdrucksweisen, die trotzdem die Sache auf den Punkt bringen. Oder auch nicht. Naja. Aber weiter im Text:
Was könnte man nur mit Port-Fetischismus meinen? Ich liebe Code-Usability. Ein super Thema, über das ich ja schon öfter referiert habe. Es ist so schön wie zeitlos… Was dabei bis lang unter den Tisch gefallen ist, sind lesbare URLs (Vielleicht mal in einem anderen Artikel) und Portangaben. Also schöne Portangaben.
Nur so zur Erinnerung: http://www.phpblogger.net:80/ ist eine Möglichkeit, einen Port zu erzwingen. Klar, das Du das schon wusstest. Welcher Port macht denn im Browser noch Sinn? Naja 443 für SSL zum Beispiel. Aber statt das zu erzwingen, wird einfach das Protokoll auf HTTPS geändert, was implizit auf Port 443 verweist.
Um das klar zustellen: Schöne Portangaben, sind nicht vorhandene Portangaben. Aber wie ein aufmerksamer Leser im Artikel zu HTTPS und SSL richtig angemerkt hat, kann man über verschiedene Ports unter ein und derselben IP mehrere SSL-Zertifikate betreiben. Und jetzt geht es mit den dreckigen Spielchen weiter, die man mit Portangaben in der URL machen kann:
*gäääääääääähn* Was für ein langweiliges Thema. Ich schlafe ja selbst beim Schreiben des Titels ein ;) Aber genau das Richtige für einen Freitag mittag, verregnet, düster und langweilig.
Immer wieder passiert es, das ich mit Kollegen diskutieren muss, wie nun SSL funktioniert und was man darüber wissen sollte, wenn man es konfiguriert. Selbst eingefleischte Entwicker und Adminprofis tun sich manchmal bei eigentlich trivialen Dingen schwer.
Herzlich Willkommen also zur Nachhilfestunde zum Thema SSL und HTTPS. (Du musst ja keinem davon erzählen, das Du diesen Artikel gelesen hast ;). Und man weiss ja nie, vielleicht erfährt man ja doch was Neues.
Zur Zeit beschäftigt mich ja das Rootserver-Setup. Da nutze ich natürlich die Gelegenheit und poste ein paar Server-Essentials. Mit PHP hat das ganze natürlich nur am Rande zu tun, aber ein sauber aufgesetzter Webserver, auf dem aktuelle Sicherheitspackages installiert sind, ist die halbe Miete für eine ordentlich laufende PHP-Applikation.
Für so ziemlich alle Betriebssysteme (gerade die mit Enduser-GUI) gibt es zahlreiche Tools, die den Benutzer oder Admin erinnern, das neue Update-Pakete bereitstehen. Denn das ist tatsächlich die größte Schwachstelle, wenn es um Patches geht: Der Admin, der daran denken muss, sie auch einzuspielen.
Das A und O beim Package einspielen ist die Geschwindigkeit. Lange Wartezeiten sind ein K.O. Kriterium, denn Sicherheitslücken werden oft in kürzester Zeit von Script-Kiddies oder anderen Bösewichten und Halunken (Cool das wollte ich schon immer mal schreiben ;) ausgenutzt. Schnell reagieren ist also alles. Nichts ist ärgerlicher als ein infiltrierter Server auf Grund einer Sicherheitslücke, die schon längst gepatcht sein könnte.
Böse Buben und Hacker gibts leider überall. Da darf man schon mal ein bisschen paranoid sein. Als Angehöriger der deutschen Sprache erst recht - schliesslich sind wir als Schwarzmaler und Pessimisten bekannt. Naja. Noch schlimmer sollen in dieser traditionellen Hinsicht die Schweizer sein, aber so wirklich verifizieren kann ich das nicht. Hat man halt mal irgendwo gehört.
Wo Iren, Spanier und Franzosen Sonnenkinder und Optimisten sind, dürfen sich Deutsche, Österreicher und Schweizer in Missmut üben - aber ich will diesen Kampf der Nationalitäten nicht weiter entfachen. Schließlich gehts hier ja nur um eine Einleitung zum Thema. Irgendwie muss ich ja zur Sache kommen. Jetzt leider etwas verkrampfter als sonst.
So. Kurze Rede, gar kein Sinn: Ich musste diese Woche mal wieder einen Rootserver aufsetzen und nichts ist schöner, als from the scratch quasi auf der grünen Wiese oder mit einem nackten Arsch anzufangen. Puh. Irgendwie schreib ich heute nur Blödsinn. Naja, mal weiter im Text.
So schnell können Wünsche in Erfüllung gehen Julius ;) Das mit dem Artikelwunsch ist eine prima Sache für Autoren. Ich gebe zu, in letzter Zeit bin ich wenig fantasievoll, was Artikelthemen angeht. Dann schreibt man halt über ein Thema, das einen selbst gerade beschäftigt und natürlich nutze ich meinen Blog auch dazu, Lösungswege für mich (und die Öffentlichkeit) festzuhalten.
Performance als Thema ist immer so eine Geschichte. Bei den meisten kleinen Projekten eher präventiv zu sehen, ist es bei Business-Projekten mit hohen Zugriffszahlen und/oder gigantischen Datenbankgrößen ein nicht unwesentlicher Aspekt bei der Webentwicklung.
Aber aus Spiel und Spass kann schnell ein großes Projekt werden, weil es das mehr oder minder breite Publikum begeistert und die Zugriffszahlen in die Höhe schießen lassen und die Entwicklung mit dem Tuning nicht mehr nachkommt. In diesem Fall (und allen anderen) rechnet sich dann eben eine sorgfältige leicht paranoide Planung der Entwicklung nach dem Motto, was wäre wenn…
Seit einiger Zeit verstaubt ein weiterer Bookmark in meiner Sammlung und schreit förmlich danach, ausprobiert zu werden: SQL Buddy. Der Name ist so eingängig, ich habe noch nicht einmal den Bookmark-Dienst meines Vertrauens bemühen müssen - schnell mal gegoogelt, wird schon oben stehen.
Was direkt oben steht ist das gleichnamige Open Source Projekt, das bei Sourceforge gehostet wird - Ein Datenbankmanager für Windows, der SQL Server bedient. Das Projekt scheint allerdings schon ein paar Jahre eingemottet zu sein - wenn man das nach der Website beurteilt.
Ich plädiere dafür, das blöde Sourceforge-Projekt vom Sockel zu werfen! Her mit den Backlinks, hier und hier und hier. Lift it up, Google - dann wird die Welt wieder etwas eindeutiger… Ich hoffe, das das jetzt nicht als URL-Spamming gewertet wird (Und wenn, dann nur als liebes URL Spamming)… Huch, jetzt ist ja fast eine Träne die Backe runtergekullert. *lach*
Das faszinierende an meinem Job ist, das man immer wieder etwas dazulernt. Schön ist natürlich, wenn das so nebenbei passiert.
Nur so zum Hintergrund: Ich konfiguriere die DNS-Einträge aller meiner (Kunden)-Domains manuell über Bind, das seit etwa 3 Jahren. Ist vielleicht etwas mehr Arbeit, als eine Klickibunti-Oberfläche, aber man hat eben alle Möglichkeiten. Letzte Woche meinte ein Freund, dass man fremde Mailserver zum Versand über einen MX-Eintrag autorisieren kann. (Ich hab das mal wehement abgestritten ;) Und natürlich direkt gegoogelt, an jeder Behauptung ist ja meist was dran…
Das Zauberwort heisst SPF (”Sender Policy Framework“, früher mal “Sender Permitted From”). Und ist übrigens kein MX-Eintrag, sondern genaugenommen ein TXT-Vermerk. Kurzgefasst kann man mit diesem Eintrag bestimmte (fremde) Mailserver definieren, die im Namen der Domain Mails verschicken können, und andere Mailserver (u.A. per Wildcard) ausschließen.
Nur ganz kurz, weil ich es gerade erst erfahren habe und auch keine Ankündigung hatte und es vor einer Weile noch nicht ging. Bei 1und1 und bei Hetzner kann man auf allen Hosting-Paketen, die SSH Zugang haben auch SVN und CVS benutzen…
Awesome!
Joe Stagner postet seit Neustem ein bis zweimal die Woche in seinem “Secure Developer“-Blog, was man beim Entwickeln richtig machen sollte. Leider auf englisch, aber um diese Weltsprache kommt in unserem Business ohnehin niemand drumherum.
Die Themen sind zwar stark Microsoft lastig, richten sich trotzdem an Webentwickler. Vor Security Bugs ist niemand gefeit - egal ob Ruby, ASP oder PHP Entwickler. Also lasst uns seinen Worten lauschen ;)
Code is Combat!
Ein PHP Blog mit aktuellen PHP Informationen und Tricks für Entwickler.
