Kategorie-Archiv: PHP

Magento2 Entwicklungsumgebung einrichten – PhpStorm + MAMP

So langsam kommt Magento 2 ja an den Start – auch wir haben mittlerweile den ersten Magento 2 Shop online und so kommt es natürlich, dass immer mehr und mehr Entwickler in den Prozess einbezogen werden und von anderen Entwicklern lernen. Jetzt ist es natürlich so, dass wir ganz am Anfang stehen und genau jetzt noch die Chance haben, von Anfang an alles richtig zu machen. Das ist natürlich nicht so einfach, aber besser jetzt, als am Ende wieder alle abzuholen.

Die Problematik ist, auf allen Systemen den gleichen Stand des Projektes herzustellen. Alle sollen mit dem gleichen Workflow, den gleichen Tools und mit dem gleichen Code-Style arbeiten. Im Idealfall laufen bei jedem Commit dann noch Tools wie phpcs, phpmd oder jshint über den Code und finden „Fehler“ der Entwickler bevor der Stand total kaputt geht und wieder jeder in seinem eigenen Code-Style programmiert. Ich mag das z.B. überhaupt nicht aber Magento liefert einiges schon von Anfang an mit – man muss es nur nutzen! Weiterlesen…

Google Analytics API – Aktuelle Besucherzahlen auf dem Raspberry PI

Heute hat mich Jörg von meintechblog.de gefragt, wie er denn am besten einige Daten über die Google Analytics API abrufen könnte. Gewünscht sind

  • aktuelle Besucherzahl (live)
  • Seitenzugriffe des aktuellen und des letzten Monats

Dem nehme ich mich doch gerne an und mache direkt einmal einen Blog-Post daraus.

Grundlage für den Zugriff auf eine GA-Property per API ist ein sogenannter Service-Account. Dieser bekommt dann Zugriff auf die einzelnen Properties und kann von dort dann auch Daten über die API abrufen. Klingt erstmal einfach, oder? Weiterlesen…

Ruck-Zuck eine Rest-API mit Slim auf die Beine stellen

Unser CRM in der Company ist selbst geschrieben – auf einer etwas spannenden Code-Basis, welche man als Einsteiger in das Projekt nicht unbedingt sofort versteht. Vieles wird global geregelt, Klassen sind eher dekorativ und wenig flexibel und eine Template-Engine oder Design-Patterns sucht man vergeblich. Es gibt kein Framework wie Zend oder Symfony drumherum – wirklich jede Zeile stammt aus eigener Hand.

Heute würde man das natürlich nicht mehr so machen – aber es ist, wie man so schön sagt, „historisch gewachsen“ und würde einen enormen Aufwand mit sich ziehen, den Code aufzuräumen oder gar komplett neu zu schreiben.

Ich wollte jedenfalls eine API für Alfred 2 schreiben, welche nach außen sicher ist und mir Kundendaten, SSH-Zugänge und allen nützlichen Kram rausgibt. Sodass ich am Ende das CRM gar nicht mehr öffnen muss. Hat im ersten Anlauf auch geklappt, sah nur nicht besonders schön aus. Wenigstens bei der API wollte ich ein richtiges Framework aufsetzen und das Ganze „2016-Style“ aufbauen. Mir schien es wie ein geeigneter Zeitpunkt, endlich mal etwas mit dem Slim-Framwork umzusetzen. Weiterlesen…

Hmac SHA256: Die Alternative zu HTTP Basic-Auth

Das klingt jetzt erstmal kompliziert, aber es ist notwendig. Das Problem ist, dass die HTTP-Basic-Auth immer nur über HTTPS Sinn macht, da ansonsten die HTTP-Header im Klartext zu lesen wären. Mit „Hmac SHA256“ könnte man sogar per HTTP relativ sicher Daten austauschen. Natürlich könnten die Daten selbst dann mitgelesen werden, aber niemand könnte die Daten abändern um sich z.B. selbst einen User anzulegen.

Wie funktioniert das?

Relativ simpel. Hier setzt die PHP-Funktion hash_hmac an. Diesen Methode nutzen zum Beispiel Facebook, Instagram oder Amazon S3 in den REST-Services. Hierzu wird einfach ein Secret-Key erstellt, der von beiden Parteien bekannt ist. Dieser wird dann genutzt, um Nachrichten zu Hashen. Dieser Hash wird dann gemeinsam mit der Nachricht übermittelt.

Die Gegenseite prüft dann mit dem Secret wieder, ob die Hashes übereinstimmen und führt die gewünschte Aktion aus. Der schlaue Leser stellt nun fest, dass man doch einfach eine Nachricht abfangen könnte, und später erneut senden. Das ist soweit auch richtig – vor Replay-Attacken schützt diese Methode nicht! Außerdem sollten die übermittelten Daten nicht sensibel sein – andernfalls muss man doch wieder auf HTTPS zurückgreifen!

Um sich vor Replay-Attacken zu schützen, muss man der Nachricht einfach nur einen Zeitstempel oder eine Message-Id mitgeben. Diese speichert man dann auf der Gegenseite ab, und erlaubt das erneute Ausführen von ein und der selben Message-Id oder älteren Nachrichten nicht mehr.

Kann man aus technischen Gründen nicht auf HTTPS zurückgreifen, könnte man den Body selbst natürlich auch noch verschlüsseln. Hier bietet es sich an, das Ganze über entsprechende RSA-Zertifikate zu lösen. Außerdem hätte man dann sogar die Chance, die Daten zu signieren. So wäre es möglich, alles mögliche zu Übermitteln, ohne dass jemand mit den Daten etwas anfangen kann. Geht man aber so weit, kann man die HMAC-Lösung auch direkt weglassen.

Technik

In PHP ist das Ganze schnell implementiert. Spricht man hier mit bestehenden REST-APIs, muss man sich vorher schlau machen, wie der Hash an die Nachricht gehängt werden soll. Hier gibt es ganz verschiedene Lösungen: Als Zusätzlicher Parameter im JSON, als GET-Parameter, als zusätzlicher HTTP-Header, oder sonst wie.

Ich würde empfehlen, den Hash im Header zu übergeben. So trennt man etwas intelligenter die Daten, und muss sich auf der Gegenseite nicht so viele Gedanken machen, wie man die Nachricht denn nun auseinander nehmen muss, bevor man den Hash kontrolliert.

Recht einfach, oder?

MAMP: Lokal mit SSL-Zertifikaten / https arbeiten

Nun habe ich in der Vergangenheit ja schon einige Beiträge über die lokale Entwicklungsumgebung geschrieben – insbesondere mit MAMP. Ein wichtiges Thema fehlt allerdings noch: SSL / HTTPS lokal nutzen.

Als erstes muss man dazu ein Key-File erstellen.

Wenn man nach einem Passwort gefragt wird, muss man dieses hier vergeben. Die Mindestlänge beträgt 4 Zeichen. In meinem Fall habe ich einfach einmal 1234 gewählt. Das kann man sich wenigstens gut merken – ist ja nur für die lokalen Verbindungen und somit unkritisch.

Bei der Erstellung des Zertifikates muss man dieses Passwort dann direkt wieder eingeben. Außerdem muss man ein paar Fragen beantworten.

Hier meine Beispielantworten:

Als nächstes erstellen wir das eigentliche Zertifikat:

Mit einem Trick entfernen wir das Passwort vom Server-Key:

So weit, so gut. Nun etwas aufräumen, und die Dateien in das MAMP-Verzeichnis schieben (geht natürlich auch per Finder):

Als nächstes müssen wir MAMP beibringen, dass wir dieses Zertifikat nutzen möchten.

Ich für meinen Teil, habe bereits eine vhosts.conf im apache-Verzeichnis angelegt. Diese enthält Domains für die lokale Entwicklung (local.dev, magento.localhost, …), da man unter localhost sonst keine Cookies ablegen kann. Weiterlesen…

PHP: SoapClient Request modifizieren

Vor ein paar Tagen stand ich vor dem Problem, dass ich an einen Service mehrere XML-Nodes mit dem gleichen Element-Namen übergeben musste. Im XML ja auch kein Problem, nur leider etwas blöd, wenn man ein Array an den Soap-Client übergibt. In diesem Fall steht man etwas doof dar, weil man Array-Keys ja schlecht doppelt und dreifach vergeben kann.

Also dachte ich mir: Einfach den XML-Request des Clients modifizieren. Das ist aber leichter gesagt als getan. Ich habe zumindest keine Funktion gefunden, welche man überschreiben könnte um sich in den Serialisierungsprozess zu hängen. Also musste ich am Ende

  • doRequest überschreiben,
  • das Ganze Zeug wieder in ein Objekt wandeln,
  • mit xPath die XML-Node rausziehen,
  • die neuen Elemente einfügen
  • und alles wieder zusammenpacken.

Weiterlesen…

phpcs: Code-Sniffer für PHP

Gerade wenn man in größeren Projekten arbeitet, müssen sich Menschen an Standards halten, da ansonsten Chaos entsteht. Ein Standard wäre hier zum Beispiel PSR (ich berichtete). Aber wie stellt man nun sicher, dass man sich auch immer daran hält? Die Antwort lautet hier: phpcs.

Sofern man seine Entwicklungsumgebung korrekt eingerichtet hat, geht die Installation recht einfach von der Hand:

Falls man seine Path-Variable nun richtig konfiguriert hat, steht einem der Befehl nun überall zur Verfügung. Soweit, so gut.

phpcs und phpStorm

Jetzt könnte man natürlich immer alle Befehlt per Hand ausführen. Da das aber nervt, nutzt man seine geliebte IDE dafür. Dazu öffnet man die Projekt-Settings eines beliebigen Projektes. Hier findet man in den Projekteinstellungen unter PHP den Punkt „Code-Sniffer“ (oder einfach die Suche bemühen). Dort gibt man nun einfach den absoluten Pfad zu phpcs an und klickt „validate“ um die Einstellungen zu prüfen. Sieht man die Ausgabe der Versionsnummer, läuft alles.

Das macht das Ganze nun aber noch nicht sonderlich spektakulär. Als nächstes öffnet man in den Projekteinstellungen den Punkt „Inspections“ und sucht ebenfalls nach „Code Sniffer“. Hier hakt man den entsprechenden Menu-Punkt an.

phpStorm-phpcs-Inspections

Danach wählt man, etwas weiter unten, den Coding-Standard aus. Falls hier nur „Custom“ angeboten wird, muss man einmal den Aktualisieren-Button betätigen. Danach kann man sich zwischen vielen Standards entscheiden. Meine Wahl fällt hier auf PSR2. Danach bekommt man (je nach eingestelltem Error-Level), die Probleme farbig in den Dateien präsentiert. Das sieht dann z.B. so aus:

phpStorm-phpcs

Weitere Einstellungen

Damit man sich das Leben etwas leichter macht, kann man natürlich noch in den Projekt-Einstellungen den entsprechenden Code-Style für PHP pflegen. Mit einem „Reformat Code“ ist man dann auf Wunsch schon PSR-Konform. Um das Ganze dann immer auszuführen, kann man noch im Commit-Dialog den Haken bei „Reformat Code“ setzen. Dann kann man unterwegs soviel vergessen wie man möchte – vorm Commit wird alles in PSR2 gerückt.

phpStorm-reformatCode

Herzlichen Glückwunsch – ab jetzt wird immer alles korrekt abgeliefert. Ohne Ausnahmen!