PHPGangsta - Der praktische PHP Blog

Wetterdaten können eine kleine nette Information sein für die Nutzer einer Webseite, entweder sie sind auf den jeweiligen Nutzer zugeschnitten und personalisiert, oder für alle Besucher der Webseite des Fussballclubs wird das Wetter der Stadt angezeigt.

Es gibt da draußen einige Dienste, die solche Widgets, sprich kleine HTML-Codefragmente zur Verfügung stellen, man muss allerdings bei der Generierung des entsprechenden Codes die Postleitzahl bzw. den Ort angeben, sowie teils einschränkende Geschäftsbedingungen akzeptieren. Außerdem ist man dann häufig auf das entsprechende Design des Anbieters angewiesen, das ganze ist also ziemlich unflexibel.

Also bauen wir uns das schnell selbst zusammen, dabei benutzen wir die Weather-API von Google. Yahoo hat auch eine Weather-API, genauso wie wetter.com. Hier zeige ich es am Beispiel von Google, die beiden anderen kommen in den nächsten Tagen dazu.

Falls jemand von euch noch andere APIs kennt die ähnlich einfach zu benutzen ist, auch kleinere Städte kennen und auch nicht nur ein Land abdecken (mindestens Europe wäre toll), immer her damit!

Google bietet eine API, an die wir einfach nur entweder die Postleitzahl oder einen Suchbegriff senden, und wir erhalten als Ergebnis das aktuelle Wetter sowie die Vorhersagen für die nächsten 4 Tage. Wir können zusätzlich noch die Sprache ändern in der wir die Ergebnisse erhalten möchten („teils sonnig“/“partly sunny“).

So sieht das XML aus wenn man das Wetter von 59302 abfragt:
Weiterlesen »

PHP ist mächtig, man kann nahezu alles umsetzen, zur Not auch mit Zugriff auf die Kommandozeile. Doch die Macht hat auch immer eine böse Seite, sie kann missbraucht werden. Nicht nur auf shared Webservern sollte man aus Sicherheitsgründen einige Funktionen ausschalten, auch auf einem einzelnen Server, auf der nur die eigene Webseite liegt, sollten die gefährlichsten Funktionen im Normalfall abgeschaltet werden (können). Falls ein Eindringling es schafft, eigenen PHP-Code hochzuladen, wäre er sehr eingeschränkt in seinen Möglichkeiten, viel kaputt zu machen, Daten auszuspähen oder sonstige böse Sachen auf unserem Server zu veranstalten.

Natürlich gibt es noch viele weitere Sicherheitsmaßnahmen, die man ergreifen sollte. Der Safe-Mode wird ja bald abgeschafft, kann und sollte also nicht mehr genutzt werden. Stattdessen sollten open_basedir, disable_classes und disable_functions genutzt werden.

Natürlich ist es auch ein guter Rat, immer eine aktuelle Version von PHP zu verwenden, seine Scripte abzusichern (Directory-Traversal, Code-Injection, Dateiuploads auf PHP-Code zu überprüfen, Remote-File-Inclusion etc. etc.), um einen Eindringlich erst gar nicht reinzulassen, aber das soll hier heute nicht das Thema sein.

Hier geht es also um disable_functions. Wir können in der php.ini PHP-Funktionen abschalten, die wir nicht benötigen und evtl. einem Eindringlich helfen, Schaden anzurichten. Welche Funktionen sollten deaktiviert werden? Ich habe hier mal eine Liste, über die wir diskutieren können:

disable_functions = „apache_child_terminate, apache_get_modules, apache_get_version, apache_getenv, apache_note, apache_setenv, curl_exec, curl_multi_exec, define_syslog_variables, disk_free_space, diskfreespace, dl, error_log, escapeshellarg, escapeshellcmd, exec, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, ini_alter, ini_get_all, ini_restore, link, mysql_pconnect, openlog, passthru, pfsockopen, php_uname, phpinfo, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, set_time_limit, shell_exec, symlink, syslog, system, tmpfile, virtual“

shell_exec verbietet auch gleich das Ausführen von Systembefehlen via Backticks (´).

Einige davon sind sicherlich gefährlicher als andere, und einige werden sogar vielleicht im ein oder anderen Projekt dringend gebraucht, sodass sie aus der Liste rausgenommen werden müssen. Als ich diese Liste erstellt habe musste ich feststellen dass ich mehr als ein Dutzend der Funktionen nicht kannte, es ist also sehr zu empfehlen sich mal ein paar davon anzuschauen.

Welche Funktionen verbietet ihr in der php.ini?

Was eine Subdomain ist brauche ich ja wahrscheinlich nicht zu erzählen, dass es manchmal mehr Sinn machen kann lieber eine neue Subdomain als einen Unterordner anzulegen und wie das geht möchte ich hier zeigen.

Die Länge der folgenden Domains ist gleich, es ist also egal ob ich

http://domain.de/forum

oder

http://forum.domain.de

anlege. Es gibt jedoch einige technische Unterschiede. Sollte ich beispielsweise später das Forum auf einen eigenen Server umziehen wollen ist das mit der zweiten Möglichkeit einfacher. Des weiteren sind die Sessions durch die Subdomain getrennt, ich kann also im Forum nicht auf die Session-Daten der Hauptdomain zugreifen und andersrum. Sollte ich das doch wollen müßte ich

ini_set("session.cookie_domain", ".domain.de");

die Einstellung ändern, dann teilen sich alle Subdomains die Session-Daten.
Weiterlesen »

Auch 2010 gab es wieder einen PHP Advent, mit einem Artikel pro Tag:

http://phpadvent.org/2010

Ein schöner Zend View Helper, der den Link zu statischen Dateien auf CDNs zusammenbaut:

http://antwerpes.it/cdn-view-helper-fur-zend-framework/2010/11/

Kleines Bookmarklet, mit dem man auf beliebigen Webseiten malen kann und dann einen Link dazu weitergeben kann:

http://markup.io/

V8 Javascript Engine innerhalb von PHP:

http://pecl.php.net/package/v8js

PHP erhält eine Möglichkeit, den Upload Progress eines Formular Uploads abzufragen:

http://schlueters.de/blog/archives/151-Upload-Progress-in-PHP-trunk.html

Was man bei HTML Emails alles beachten muss:

http://antwerpes.it/erstellung-html-newsletter-best-practices/2010/11/

Wie einfach es ist, den JMStV Filter zu umgehen (falls er doch noch kommt):

http://blog.odem.org/2010/12/jmstv-filter-umgehen.html

Tausende potentiell unsichere PHP Projekte:

http://www.google.com/codesearch?as_q=lang:php+echo\s%2B\$_%28GET|POST|REQUEST|COOKIE%29&btnG

Ein Gastbeitrag von Timo Puschkasch
Student aus Stuttgart, seit längerem als Webentwickler mit PHP und Ruby tätig. Seit kurzem auch in der UG Stuttgart anzutreffen.

PHP ist eine der ältesten serverseitigen Web-Sprachen und fast die einzige, die speziell zu diesem Zweck geschrieben wurde. Leider verleitet dies viele Entwickler dazu, den Gedanken, die PHP-Gemeinde könnte über den eigenen Tellerrand hinaus blicken und sich mit anderen austauschen, höchstens mit einem Lächeln abzutun. Dabei ist dieser Gedanke garnicht so abwegig. Es gibt viele Beispiele dafür, dass sich gerade Entwickler alt eingesessener Sprachen in alten Paradigmen verlieren und nicht dazu neigen, etwas Neues auszuprobieren. Deshalb möchte ich im Folgenden aufzuzeigen, an welchen Stellen die PHP-Entwicklergemeinde durchaus von anderen Gemeinden lernen kann. Dies betrachte ich am Beispiel der Ruby-Gemeinde, in der ich selbst seit einiger Zeit aktiv bin.
Weiterlesen »