Der Unterschied zwischen „||“ und „or“ bzw. „&&“ und „and“
Wenn man eine if-Anweisung in PHP schreiben möchte, und dabei 2 Bedingungen mit einem „und“ verknüpfen möchte, kann man entweder „&&“ nutzen oder „and“ schreiben. Richtig?
if ($a > 0 && $b < 100) {
if ($a > 0 and $b < 100) {
Das ist das selbe, oder? Ja, ist es. Beides funktioniert, beides ist syntaktisch korrekt, und beides ist äquivalent.
Kopieren wir nun die Bedingungen in eine temporäre Variable $c: Weiterlesen »
igphp – Interessengemeinschaft PHP e.V.
Ich mag PHP. Ich möchte es auch in Zukunft nutzen, denn man kann sehr effektiv Software schreiben, große wie kleine Projekte umsetzen, und einfach alles machen was man will: Webseiten, Daemons, Cronjobs, Chatbots, IoT-Steuerungen, neuronale Netze, einfach alles. Dazu tragen kontinuierliche Verbesserungen und Erweiterungen der Sprache selbst, aber auch das Ökosystem (Frameworks, Tools, Bibliotheken…) bei. Seit PHP 7 ist PHP mit an der Spitze der performantesten Scriptsprachen. Es gibt eine Menge PHP-User-Groups weltweit, Dutzende Konferenzen jedes Jahr, Foren, eine Menge Möglichkeiten sich auszutauschen. Aber es fehlte noch etwas…
Anfang 2017 wurde die Interessengemeinschaft PHP e.V. (igphp) gegründet, eine gemeinnützige Organisation, ein Verein, dessen Aufgabe und Arbeit sich darum dreht, PHP weiter zu stärken, weiterzuentwickeln, die Akzeptanz zu steigern, und es in Forschung, Ausbildung und Wissenschaft zu verbreiten. Es sollen quelloffene Projekte unterstützt werden, die Vernetzung soll vorangetrieben werden in Forschung, Lehre, und Industrie. Hohe Ziele, für die es Mitstreiter braucht, Unterstüzung, Geld.
Seit Ende Juli 2018 ist igphp öffentlich, und nimmt Mitglieder auf. Seit dem 30.07.2018 bin ich Mitglied #000014, möchte helfen bei dem, was PHP weiter voran bringt, denn PHP ist zu großen Teilen mein Hobby und Beruf, und das soll auch gern so bleiben.
Da hier viele sind, die wie ich mit PHP ihre Brötchen verdienen, möchte ich dafür werben, sich die igphp anzuschauen, und sie im Idealfall tatkräftig zu unterstützen. Eine (Förder)Mitgliedschaft ist sowohl für Privatleute als auch Firmen möglich.
Ich würde mich sehr freuen, mit euch im Verein zusammenzuarbeiten.
Weitere Infos findet ihr hier:
https://twitter.com/igphp
PHP, curl und TLS 1.2 als Minimum
TLS 1.2 ist im Payment-Bereich weiter auf dem Vormarsch, immer mehr Zahlungsanbieter setzen TLS 1.2 als Minimumversion fest. Das Payment Card Industry Security Standards Council (PCI SSC) hat die Frist von 2016 auf 2018 verschoben. PayPal wird am 30. Juni 2018 TLS 1.0 und 1.1 abschalten. Paysafecard wird selbiges bereits im Februar 2018 tun.
Wer einen Zahlungsanbieter eingebunden hat, und deren API nutzt, sollte baldmöglichst prüfen ob seine Systeme TLS 1.2 beherrschen. Für halbwegs aktuelle Systeme sollte das gelten, Ubuntu 14.04 geht so gerade noch. Doch seht selbst.
Folgendes Script testet die TLS-Einstellungen von PHP (curl) mit Hilfe der Webseite https://www.howsmyssl.com:
<?php $ch = curl_init('https://www.howsmyssl.com/a/check'); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $data = curl_exec($ch); curl_close($ch); $json = json_decode($data); var_dump($json);
Die Ergebnisse:
HTTP Range-Request Header in PHP parsen
Hört sich eigentlich nach einer einfachen Aufgabe an: HTTP-Clients können beim Download nur Teile einer Datei anfragen, beispielsweise die ersten 500 Bytes eines Videos. Der Server announced die Unterstützung dieses Partial-Downloads mit dem Response-Header:
Accept-Ranges: bytes
Ein HTTP-Client, der partielle Downloads unterstützt kann nun mit dem folgenden Header die ersten 500 Bytes anfordern:
Range: bytes=0-500
Ein Webserver, der direkt die Datei ausliefert, tut wie ihm befohlen. Wird die angefragte Datei jedoch von einem PHP-Script ausgeliefert, muss im PHP-Script dieser Header geparst werden, damit man in PHP weiß wie viele Bytes man ausliefern soll.
Durchsucht man das Internet nach einer Antwort, findet man sehr häufig folgende Lösungen. Achtung, nicht dem RFC https://tools.ietf.org/html/draft-ietf-http-range-retrieval-00 entsprechend, nicht unbedingt nutzen:
Blog mittels Let’s Encrypt dauerhaft via SSL erreichbar
Nach einer viel zu langen Pause habe ich wieder etwas Luft für meinen Blog. Endlich…
Ein Kommentar von YamYamL hat mich daran erinnert, die HTTPS-Umstellung meiner Domain endlich abzuschliessen, und noch einen Endspurt einzulegen, die Domain verschlüsselt erreichbar zu machen.
Wäre hier nur ein einfaches WordPress-Blog gehostet, wäre es vermutlich eine Sache von einer Stunde gewesen. Ein Zertifikat besorgen, WordPress umkonfigurieren (Einstellungen -> Allgemein), und alle selbst gehosteten Bilder in den Posts in der Datenbank ändern von http://www.phpgangsta.de auf https://www.phpgangsta.de (ich habe das WordPress-Plugin Better Search & Replace genutzt). Aber…
Leider ist unter phpgangsta.de nicht nur dieser Blog erreichbar, sondern auch zig andere Projekte, selbst geschriebenes Zeug, teils 10 Jahre alt, und nicht HTTPS-fähig. Es ist also doch etwas mehr Arbeit gewesen, als „nur“ den Blog auf HTTPS umzustellen.
Der Port 443 war bereits seit langem offen, aber mit einem selbst signierten Zertifikat versehen. Da ich gern Let’s Encrypt (LE) verwende, LE aber keine Wildcards erlaubt (dann wäre es verhältnismäßig einfach gewesen, einfach für alle Subdomains ein zentrales Zertifikat zu hinterlegen), musste ich mein Domain-Verwaltungs-Reseller-Tool froxlor, das ich hier laufen habe, erstmal updaten auf eine Version, die LE unterstützt, so dass ich nun für einzelne Subdomains SSL aktivieren kann, und die Zertifikate auch via Cronjob immer brav erneuert werden.
Nicht vergessen darf man: In den Google Webmaster-Tools eine neue Property anlegen, den WordPress-Cache zu leeren falls man ein Cache-Plugin verwendet, Analytics umzustellen falls man es verwendet, und alle WordPress-Plugins prüfen dass sie HTTPS-fähig sind (bei mir waren sie das anscheinend dankenswerterweise).
Ich hoffe ich habe die meisten Mixed-Content-Probleme gelöst, könnte sein dass es noch irgendwo externen Content gibt (Bilder), der noch via HTTP eingebunden ist. Meldet ihn gern bei mir, sollte das Bild via HTTPS erreichbar sein, fixe ich das schnell, oder lade es auf meinen Space.
All in All durchaus einiges an Aufwand in den letzten Tagen und Wochen, aber seit heute ist der Blog nun via HTTPS verfügbar, incl. Let’s Encrypt Zertifikat, HTTP->HTTPS Weiterleitung und HSTS Header. Diverse Subdomains und andere (kleinere) Domains muss ich in den nächsten Wochen nach und nach umstellen, das kann noch etwas dauern.