Remote Bypass API – A wordpress API plugin

I was in need of a remote API to access my WordPress blog for writing, updating, deleting etc. of my posts driven by MySQL statements.

I tried to make head or tails out of the official Rest API plugin but got annoyed by too much overhead and stuff to learn. I needed a solution NOW!

So I decided to program my own server API to suite my needs.

It’s pretty easy to handle. You can use every build in WordPress function as you are used to.

The server is secured by apache’s basic authentication (.htpasswd/.htaccess). Communication is encrypted by SSL (if installed). There is also a checksum to make sure that no bit of the command is lost during sending.

All you have to do is download the automatically generated small client code which includes the function „call_server„. This function will send your command to the API server and wait for the result(s) coded in a handy json generated string.

Example:

This will call the server. Parameters are name of function („get_users„) and an argument’s array as defined in https://codex.wordpress.org/Function_Reference/get_users.

This is the result in the brower’s source code view:

See, this plugin bypasses the WordPress function, hence the name.

DOWNLOAD

Use at your own responsibility. No guarantee, no support.

remote-bypass-api

Changelog

  • 0.4. (2017-02-15) (API Version 4)
    • hiding and randomizing basefolder
    • now accepting all kind of parameter arrays
  • 0.3 (2017-02-15) (API Version 3)
    • now handles pure strings as arguments as well
  • 0.2 (2017-02-11) (API Version 2)
    • checksumm check
    • Communication between client and server is crypted when ssl
  • 0.1 (2017-02-11) (API Version 1)
    • first version.

Eine simple API für WordPress, Teil 4

Wir wissen jetzt, wie wir mit Hilfe unserer kleinen API einen Artikel anlegen und wie wir ihn mit einem Bild versorgen. Nun fügen wir einige Metadaten hinzu. Dazu benötigen wird die Funktion „add_post_meta„. Diese verlangt folgende Parameter:

  • post_id – Die eindeutige Artikel-ID aus Teil 2
  • meta_key – Der Name des Metadaten-Feldes
  • meta_value – Der Wert des Metadaten-Feldes

Wir packen also wieder einen Befehlsaufruf für unseren Server zusammen:

Und natürlich müssen wir auch unseren Server wieder ein wenig ergänzen.

Diese 3 Zeilen erweitern unseren Server um die Fähigkeit, mit Hilfe der Funktion „add_post_meta“ Artikel mit beliebigen Metadaten zu versorgen.

Und so sieht dann das neue benutzerdefinierte Feld aus.

Zusammenfassung

Server

Client

 

Eine simple API für WordPress, Teil 3

Kommen wir nun zum wichtigen Thema: Wie füge ich dem Artikel ein Bild bei?

Auch das wird in vielen Beiträgen im Internet gerne angerissen, aber mal ein paar schnelle, praktikable Lösungen werden selten präsentiert. Dabei ist es nicht so schwer, wenn man weiß, was zu tun ist.

Der Ablauf

Im Grunde müssen folgende Schritte abgearbeitet werden:

  1. Wir erzeugen einen Artikel und merken uns die ID (siehe Teil 2)
  2. Wir laden ein Bild per FTP auf den WordPress-Server
  3. Wir verbinden Artikel und Bild mit Hilfe der Funktionen: wp_generate_attachment_metadatawp_insert_attachment und set_post_thumbnail

Damit das funktioniert, müssen wir unseren Server gleich zweimal bemühen: Beim Erzeugen des Artikels und beim Verbinden des Bildes mit ersterem.

Der Upload per FTP

Keine Angst, das ist per PHP einfacher, als man denkt.

Zunächst benötigen wir auf dem WordPress-Blog einen Zielordner. Den kann man per Konsole oder FTP anlegen:

Auf diesen Server werden die Bilder (oder was immer man später mit den Artikeln verknüpfen möchte: ZIP-File, E-Book, PDF etc.) zwischengespeichert. Man sollte darauf achten, dass die Dateinamen dabei immer einzigartig sind, denn sonst werden sie gnadenlos überschrieben. Erreichen kann man das z.B. durch eine Ergänzung mit einer Time-id und einer laufenden Nummer.

Wir erweitern den Client um einige Zeilen:

Damit wird die Datei „bild.jpg“ vom lokalen Verzeichnis „/var/upload/bilder/“ auf das entfernte Verzeichnis „/var/www/domain.tld/wp-content/uploads/maschine/“ des Servers „domain.tld“ kopiert. Wenn Sie nicht wissen, wie das entfernte Verzeichnis lautet, fragen Sie ihren Provider.

Bevor wir nun an den Client gehen, packen wir dessen Kernaufgabe in eine Funktion, damit wir sie mehrfach benützen können.

Diese Funktion sendet ein Array an unseren Server und gibt dessen Antwort wieder zurück.

Die Aufgaben des Servers werden jetzt erweitert. Er kann nicht nur Artikel anlegen, sondern auch Bilder verarbeiten. Das geschieht durch folgende Zeilen:

Zeile 1 ermittelt den Mime-Type der Datei (hier: „image/jpeg“), das Array mit den Meta-Daten (Titel, eindeutiger Bezeichner etc.) wird automatisch gefüllt. Natürlich können Sie den Titel des Bildes auch aus den eigenen Daten erzeugen.

Zeile 10 fügt dann das eben hochgeladene Bild der Mediendatenbank des Blogs hinzu. Von nun an finden Sie das Bild dort, aber es ist noch nicht mit einem Artikel verbunden. Das erledigen wir gleich.

Zeile 12 versorgt das Bild in der Mediendatenbank mit den soeben festgelegten Metadaten und legt die einzelnen Vorschaubilder in den verschiedenen Größen an, die in den Medien-Einstellungen von WordPress festgelegt sind.

Zeile 14 macht die Magie: Das Bild wird mit dem Artikel verbunden.

Zusammengefasst

Der Server

Der Client

Das war ja nicht so schwer, wenn man weiß, wie es geht – aber das gilt wohl für alles im Leben. Im nächsten Schritt lernen wir, unseren Artikel nachträglich mit Daten anzureichern.

Eine simple API für WordPress, Teil 2

Wir kommen nun dazu, mit Hilfe unserer kleinen API einen WordPress-Artikel anzulegen.

Dazu müssen wir uns kurz mit den internen Funktionen beschäftigen, die WordPress für dieses Unterfangen zur Verfügung stellt.

Es ist zunächst die Funktion „wp_insert_post„.

Mit ihrer Hilfe kann man Artikel (oder auch Seiten) anlegen und bearbeiten.

Es gibt viele Parameter. Wir betrachten zunächst die wichtigsten:

  • post_content – der Inhalt des Artikels
  • post_title – die Überschrift des Artikels
  • post_status – der Status des Artikels und

Stellen wir uns ein simples Array zusammen:

Die Werte sollten sich von selbst erklären. Ich empfehle, wenn immer möglich beim Testen Umlaute zu nutzen, um später keine bösen Überraschungen zu erleben.

Ich setze „post_status“ auf „publish„, da ich die Artikel sofort veröffentliche. Wer aber noch händisch nachkontrollieren oder erstmal sichergehen möchte, der setzt „post_status“ auf „draft„.

Der neue Client

Der Client muss entsprechend angepasst werden.

Der Aufbau hat sich nicht sehr gegenüber Teil 1 verändert.

Der neue Server

Beim Server hat sich ein wenig mehr getan.

Wir müssen nun die Verbindung unseres Servers zu WordPress herstellen. Das passiert ganz einfach durch die Zeile:

Die Datei „wp-load.php“ die sich im Hauptverzeichnis des Blogs befindet, stellt automatisch alle Daten und Komponenten zur Verfügung, die wir für den Umgang mit WordPress benötigen.

Die Zeile:

Sorgt noch dafür, dass wir keine Komponenten laden, die lediglich für das Frontend des Blogs benötigt werden.

Der Rest dürfte sich von selbst erklären. Interessant ist Zeile 10, in der der eigentliche Befehl zum Anlegen ausgeführt wird und als Ergebnis die ID des neuen Artikels (WordPress-Jargon: Post) an den Client zurückgegeben wird. Diese ID ist wichtig und sollte irgendwo auf Seiten des Clients gespeichert werden, denn später werden wir sie benötigen, um Artikel zu korrigieren, zu löschen oder mit anderen Daten anzureichern. Die ID ist immer eindeutig und wird niemals doppelt vergeben.

Rufen wir den Client auf:

Das Ergebnis gibt uns die ID 4025 zurück.

Und schauen wir mal ins Backend des Blogs.

Voilà – Das ist unser Artikel.

Bis dahin war es noch nicht ganz so schwer. Bisher hatten wir nur die Pflicht, jetzt folgt die Kür. Im nächsten Teil werde ich zeigen, wie man dem Artikel auch ein Bild zuordnet.

Eine simple API für WordPress, Teil 1

Ich benötig(t)e eine Methode, um von ferne (remote) meine verschiedenen WordPress-Blogs betreiben zu können. Artikel, Posts etc. sollen von einer Datenbank gefüttert werden.

Dazu hat es früher einmal im Kern von WordPress eine REST-API gegeben, die aber abgeschaltet wurde. Demnächst (ab WP 4.7) soll sie wieder implementiert werden. Ich habe mir die Dokumentation des Beta-Plugins durchgelesen und finde sie wie immer viel zu lang. Es dauert ewig, bis jemand auf den Punkt kommt. Typisch doppelter Overhead der OOP-verliebten Informatiker was Code und Dokumentation betrifft.

Auch wollte ich mich nicht auf eine Beta-API verlassen, deren Schnittstellen offen vorlegen. Da kann ich die Zeit stoppen, bis die ersten Hacker sich drauf einstellen. Dann eine Lücke und zack! ist mein Blog gekapert.

Also muss eine eigene Lösung her. WordPress liefert intern alle möglichen, bequemen Methoden, um Artikel anzulegen, zu bearbeiten oder zu löschen. Mehr brauchen wir erstmal nicht. Die Kunst besteht nur darin, diese Methoden anzusprechen.

Also bauen wir uns unsere eigene API. Wir benötigen:

  1. einen Server im WordPress-Blog, der auf Kommandos wartet, diese verarbeitet und Ergebnisse zurückmeldet.
  2. einen Client, der Befehle sendet, wartet und die Antworten des Servers auswertet.
  3. und natürlich sollte der Server geschützt sein, damit er nicht gehackt wird.

Der Server

Zunächst legen wir im Hauptverzeichnis des WordPress-Webservers einen Unterverzeichnis an. Ich nenne diese Verzeichnis „maschine“ – aber ihr könnt auch jeden anderen eindeutigen Namen nehmen.

(Natürlich kann man das Verzeichnis auch per FTP anlegen, wenn ihr keine Kommandozeile öffnen könnt.)

Nun heißt es erst einmal, das Verzeichnis gegen Unbefugte abzusichern. Das geht am einfachsten mit einer .htpasswd-Datei. Diese kann man online generieren. Dann einfach nur ins Verzeichnis „maschine“ kopieren.

Mit der User/Passwort-Kombination mueller/geheim sieht die Datei folgendermaßen aus:

Aufpassen: vor dem htpasswd steht ein Punkt, das macht die Datei normalerweise unsichtbar, daher muss man das Anzeigen von versteckten Dateien im FTP-Programm aktivieren.

Nun braucht es noch eine .htaccess-Datei mit folgenden Einträgen:

Der Eintrag in AuthUserFile kann bei euch natürlich ein anderer sein. Wichtig ist, dass er den absoluten Pfad (vom root des Servers aus) zur eben angelegten .htasswd-Datei beinhaltet. Diesen Pfad könnt ihr bei eurem Provider erfragen oder in den FAQ nachlesen. Meist liefern die Provider auch bequeme Funktionen (Stichwort: Verzeichnisschutz) gleich mit, um alles online zu generieren.

Nun ein kleiner Test. Wir rufen im Browser auf:

Ab jetzt steht „domain.tld“ natürlich für eure eigene Domain. Jetzt müsste sofort die Abfrage nach User und Passwort erfolgen. Wenn nicht, habt ihr etwas falsch gemacht. Dann nochmal von vorn, denn Sicherheit, besonders im produktiven Bereich ist wichtig.

In Zukunft erfolgt der Aufruf natürlich automatisiert, da ist eine Passwort-Eingabe nicht möglich. Zu diesem Punkt kommen wir gleich.

Jetzt programmieren wir den einfachsten Server. Dazu legen wir eine Datei „index.php“ im Verzeichnis „maschine“ an, die demnächst unsere Befehle verarbeitet.

Wir nutzen die multibyte-fähigen Funktionen, die man am Präfix „mb_“ erkennt, damit wir später keine Probleme mit Umlauten haben. Unseren kleinen Server kann man schon per Get-Parameter in der URL oder per Post (bspw. bei Formulareingaben) bedienen. Zurückgegeben wir ein einfacher utf8-kodierter Text. Das ist für unsere Belange absolut ausreichend und bietet bessere Debug-Möglichkeiten.

Was macht der Server? Er nimmt einen Parameter (Hier „befehl“) auf und wandelt den String in Großbuchstaben um. Das ist natürlich ein wenig sinnfrei, aber wir wollen ja erstmal testen.

Wir rufen also im Browser auf:

Mit den Angaben vor dem „@“ kann man User und Passwort gleich in der URL übergeben und muss diese nicht immer extra eingeben. Und wenn alles geklappt hat, müsste im Browser der Text „HALLO“ erscheinen.

Der Client

Jetzt geht es an einen kleinen, ersten Client. Wir legen eine Datei an, der Name ist egal, ich nenne sie „client.php“. Diese Datei kann irgendwo angelegt sein, sinnvollerweise nicht auf dem selben Server, auf dem unser API-Server läuft, denn sonst wäre die Arbeit ja sinnlos.

Das sieht schon etwas komplizierter aus. Im Grunde simulieren wir das, was wir vorhin im Browser händisch gemacht haben: Wir packen Daten zusammen (hier nur $befehl), authentifizieren uns am Server und geben die Rückgabe wieder aus.

Zeile 2+3 sind selbsterklärend. WICHTIG: Ohne das abschließende Slash in Zeile 4 wird es nicht funktionieren – also nicht vergessen.

Zeile 5 beinhaltet den „Befehl“, den wir absenden, wieder erstmal nichts besonderes.

Der Rest der Zeilen dient dazu, einen Stream zu generieren und damit das PHP-Skript zu einem kleinen Browser zu machen.

Zeile 21 legt einen Timeout in Millisekunden fest. Da die meisten Hoster nur 30 Sekunden an Ausführungszeit für ihre Skripte zulassen, lohnen sich Werte über 30 Sekunden gar nicht erst, denn der Server wird bereits vorher abbrechen.

Wir machen den Test und rufen den Client im Browser auf:

Etwas smarter, bitte!

Nun ist es auf Dauer etwas unbefriedigend, immer nur $befehl=blabla an den Server zu senden, daher machen wir jetzt die Datenübermittlung etwas smarter. Und zwar so, dass im Prinzip alles gesendet und empfangen werden kann, solang wir es in Variablen verpacken können.

Dazu passen wir zunächst den Client an:

Zeile 5 wird zu:

und Zeile 9 zu:

Und der Server wird auch angepasst.

Die Zeilen 3, 4 und 5 werden zu:

Welchen Sinn hat das? Wir packen alle Variablen, die wir übertragen wissen wollen, in ein Array, serialisieren es mit serialize und packen es auf der anderen Seite wir mit unserialize wieder aus. Der Name des zu transportierenden Arrays spielt dabei keine Rolle; array_shift ermittel automatisch das richtige Array.

Später werden wir serialize auch nutzen, um mehr als nur ein simples „Hallo Welt“ an den Client zurückzuliefern. Aber fürs erste sollte das genügen.

Wir fassen zusammen

Server

Client

Wenn wir jetzt den Client wieder aufrufen:

erhalten wir:

Und mehr benötigen wir für heute nicht. Der Server hat also das Array richtig empfangen.

Im nächsten Teil werden wir dann unseren kleinen Server dazu nutzen, um einen WordPress-Artikel anzulegen.

Microsoft Word 2016 schluckt die letzte Zeile – mal wieder

Ich ärgere mich gerade maßlos, dass Microsoft es 2016 immer noch schafft, auf dem eigenen Betriebssystem und mit der eigenen Software hundertprozentig zuverlässig Textkopien zu erstellen.

Word 2016 schneidet den letzten Satz ab.

Sebastian Brück, ein befreundeter Journalist, mit dem ich zusammen das Projekt Krimischätze  ins Leben gerufen habe, hat mir einen längeren Text, genauer gesagt eine Abschrift eines Roman von 1926 geschickt. Meine Aufgabe ist, daraus ein E-Book zu gestalten.

Der letzte Satz im Text müsste lauten:

Selig sind die Heimatlosen. Denn ich glaube, sie werden nach Hause kommen.

Zufällig bemerke ich, dass die allerletzte Zeile, bzw. der allerletzte Satz im Dokument abgeschnitten ist. Offensichtlich kann „mein“ Word 2016, das ich im Zuge des Office 2016 Pakets für 10 Euro Monatsgebühr abonniert habe nicht das Word-Dokument meines Freundes öffnen.

fehler

Speichern als RTF und alles ist wieder gut.

Wenn ich die selbe Datei nun als RTF speichere und mit bzw. Libre Office Writer öffne, ist die Zeile auf einmal wieder da.

alles_ok

Woher das letzte kleine „s“ auf einmal herkommt, kann ich auch nicht sagen – wieso auch? – ich weiß ja nicht einmal, wieso Word nach Gusto einfach was abschneidet.

Warum kann Word nicht fehlerfrei Word-Dokumente öffnen und anzeigen?

Jetzt wird es noch bunter und es fehlt immer noch die Conclusio: Wenn ich den Text komplett mit STRG+A markiere und mit STRG+C kopiere, dann in einem reinen Texteditor meiner Wahl (hier natürlich Notepadd++) einfüge, ist der Satz wieder da… zumindest die Hälfte davon

immer_noch_nichts

Was fehlt noch?

Was fehlt noch? Was ist mir in den letzten Monaten und Jahren noch durch die Finger geschlüpft? Ich weiß, dass ich dieses Problem vor einigen Monaten schon einmal hatte, damals mit einem mit Open Office erzeugten Word-Dokument; dasselbe Problem: der letzte Satz war abgeschnitten. Damals habe ich das dem exotischen Format „.doc“ zugerechnet und einer fehlerhaften Exportfunktion von Open Office Writer. Aber nun, was ist nun der Grund?

Ich werde diesen Text mitsamt der Datei an den Microsoft-Support schicken, mal schauen, was denen so dazu einfällt.

Und es gibt Ingenieure, die wollen tatsächlich selbstfahrende Autos zu Millionen auf die Menschheit loslassen!

ssdeep Funktionen für PHP installieren

Wer folgende ssdeep-PHP-Funktionen

  • ssdeep_fuzzy_compare
  • ssdeep_fuzzy_hash_filename
  • ssdeep_fuzzy_hash

nutzen möchte, der muss sie zunächst für PHP installieren. Dazu werden verschiedene Pakete und Bibliotheken benötigt. Ich skizziere hier einmal den Schnelldurchgang.

Die Funktionen selbst sind hier beschrieben: http://php.net/manual/en/ref.ssdeep.php

Search and replace inside zip with PHP

Ever wanted to search and replace inside a zip container with PHP?

Linux: Skript ausführen beim Ausschalten

Ich bin ein fauler Hund und noch dazu vergesslich. Also, was passiert, sobald ich meine virtuelle Linux-Maschine ausschalte? Ich denke, verdammt, schon wieder das Backup vergessen!

Also habe ich nach einer Methode gesucht, ein (oder mehrere) Backup-Skripte auszuführen, sobald ich den Rechner ausschalte. Bei einer virtuellen Maschine wird das natürlich durch einen ACPI-Event simuliert. Aber Linux bemerkt da keinen Unterschied.

Hier also meine schnelle: „Klicken-und-vergessen“-Methode für

  • Oracle VM VirtualBox Manager
  • Host: Windows 7 64 Bit
  • Gast: Ubuntu Linux 14.04.1 – 64 Bit
  • Netzwerk: AVM FRITZ!Box 7390, Host über WLAN verbunden

Wir installieren (falls noch nicht geschehen) ACPI, das Advanced Configuration and Power Interface.

Alles wichtige findet sich unter etc/acpi/:

Werfen wir einen Blick in die auszuführende Datei powerbtn-acpi-support.sh:

Zum Glück ist die Datei nicht sehr lang und erklärt sich sogar einem Laien wie mir einigermaßen. Wir suchen die Zeile weiter unten mit dem Kommentar: # Normal handling.

Und direkt vor dem /sbin/shutdown -h -P now platzieren wir den Aufruf zu unserem Skript. Das könnte dann etwa so aussehen:

In backup_files.sh rufe ich meine verschiedenen Backup-Befehle auf, die sonst auch bei reboot oder shutdown aufgerufen werden. Wie das funktioniert, habe ich schon hier: Und es geht doch: Linux, Skript ausführen beim Herunterfahren beschrieben.

Das war’s. Beim nächsten Ausschalten gibt es vorher erst einmal – wie es sich gehört – ein Backup.

Und es geht doch: Linux, Skript ausführen beim Herunterfahren

Geradezu abenteuerlich sind die Aussagen einiger selbsternannter „Spezialisten“ beim Thema „Skripte ausführen beim Herunterfahren“. Von „Linux fährt man nicht herunter“ bis zu „ist überhaupt nicht möglich“ habe ich alles schon lesen dürfen.

Dabei ist es ganz einfach. Ich benutze diese Methode auf meiner virtuellen Entwicklunsgmaschine, um Dateien und Datenbanken nach einem Arbeitstag auf dem Host zu sichern.

Hier also meine schnelle: „Klicken-und-vergessen“-Methode für

  • Oracle VM VirtualBox Manager
  • Host: Windows 7 64 Bit
  • Gast: Ubuntu Linux 14.04.1 – 64 Bit (Hostname: minlux)
  • Netzwerk: AVM FRITZ!Box 7390, Host über WLAN verbunden

Die auszuführenden Dateien befinden sich in /etc/init.d/.

Wir legen ein Skript an, das nichts anderes macht, als eine leere Datei namens goodbye.txt ins Home-Verzeichnis des Users zu schreiben. Das Skript, das das erledigen soll, erhält den Namen custom-shutdown.sh.

Wir machen die Datei ausführbar:

Prüfen, ob alles geklappt hat:

Nun legen wir in /etc/rc0.d/ einen Link zum Skript. Beachte: das Präfix K04 vor dem Dateinamen, ohne dem geht es nicht.

Fertig. Nun starten wir die Maschine neu

Test, ob goodbye.txt auch wirklich angelegt wurde:

Man beachte, dass die Datei für den Nutzer root angelegt worden ist, falls man noch irgendetwas damit plant.

Skript beim Hochfahren ausführen

Wer möchte, kann Skripte auch ausführen lassen beim Hochfahren des Rechners. Dann muss der Link aber nicht in rc0.d sondern in rc6.d platziert werden.

WICHTIG: Server neu starten

Wenn man Datenbanksicherungen beim Herunterfahren anlegen möchte, so muss man natürlich beachten, dass die Datenbank schon längst selbst heruntergefahren ist. Also muss man diese kurz wieder starten:

Mein Dank geht an http://ubuntu.flowconsult.at/linux/ubuntu-14-10-shutdown-script-with-rc0-d-rc6-rcd/ und https://unix.stackexchange.com/questions/34963/running-script-before-shutdown-seemingly-not-working. Mehr Informationen zum Runlevel: https://en.wikipedia.org/wiki/Runlevel#Ubuntu