Post-ID unter WordPress ermitteln

Manchmal wird die Post-ID einer Seite unter WordPress benötigt. Dann stellt sich die Frage, wie diese ID ermittelt werden kann? Wenn die ID Teil des Permalinks ist, so kann sie einfach anhand der URL ermittelt werden.

Die Post-ID spiegelt sich im Permalink wieder

Bei Beiträgen funktioniert diese Variante in vielen Fällen, bei Seiten wird dies schwieriger. Um die Post-ID einer beliebigen Seite oder eines Beitrages zu ermitteln, muss diese im WordPress-Backend bearbeitet werden. Dort findet sich in der Adressleiste eine URL nach folgendem Schema:

https://seeseekey.net/wp-admin/post.php?post=125008&action=edit

Der Wert hinter dem Parameter post spezifiziert die Post-ID, welche somit ermittelt wurde.

Kalenderdateien mit webcal-Schema herunterladen

Manche Dienste und Webseiten bieten Kalenderdateien über das inoffizielle URL-Schema webcal:// an. Wird nun versucht eine solche URL herunterzuladen:

wget webcal://example.org

erhält der Nutzer in den meisten Fällen die Meldung:

Nicht unterstütztes Schema »webcal«

Abhilfe schafft es in diesem Fall das Schema webcal durch http bzw. https zu ersetzen. Anschließend kann die Datei mit den Kalendereinträgen problemlos heruntergeladen werden.

Maximale URL-Länge bei HTTP

Der Uniform Resource Locator, oder in der Kurzform die URL, wird sicherlich jedem schon begegnet sein. Die URL setzt sich aus einem Schema und einem für das Schema spezifischen Part zusammen. Getrennt werden die beiden Bestandteile durch einen Doppelpunkt. Bei HTTP wäre die Angabe des Schemas (http) und dem anschließenden spezifischen Teil mit dem Host, eventuellen Informationen über den Port, Kennwörter und ähnliches und anschließend der Pfad zur gewünschten Ressource. Interessant ist allerdings die Frage, wie lang darf eine solche URL sein? Kurze URLs wie:

http://api.example.com

machen keinerlei Probleme. In der RFC 2616 finden sich erste Anhaltspunkte dazu. Die RFC trägt den Namen Hypertext Transfer Protocol — HTTP/1.1 und definiert eben dieses Protokoll. Im Abschnitt 3.2, der sich um Uniform Resource Identifiers dreht, findet sich im Unterpunkt 3.2.1 folgender Abschnitt:

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Aus diesem Abschnitt ergibt sich das URLs so lang wie benötigt sein dürfen und das HTTP-Protokoll keinerlei Beschränkung vornimmt. Sollte der Server eine lange URL nicht verarbeiten können, so soll dieser mit dem Statuscode 414 (URI Too Long) antworten. Gleich danach finden sich ein weiterer Hinweis in der RFC:

Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

Dort wird darauf hingewiesen das es Probleme geben kann, wenn die URL länger als 255 Byte ist. Je nach Kodierung und Sprache (wie z.B. Deutsch oder Japanisch), lassen sich eine unterschiedliche Menge an Informationen in diesen 255 Byte kodieren. Allerdings wurde die RFC 2616 durch die RFC 7230 für obsolet erklärt. In dieser RFC findet sich folgender Absatz:

Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.

Mit diesem Absatz wird definiert das HTTP-Clients und Server eine Mindestlänge von 8000 Byte unterstützen sollen. In der Praxis stellt sich nun die Frage was wirklich funktioniert. Es existieren durchaus längere URLs, z.B. sogenannte Data-URLs, allerdings sind dies keine HTTP-URLs, sondern definierten ein eigenes Schema. Daneben existieren alte Untersuchungen zu dem Thema. Unabhängig von der theoretischen Machbarkeit existieren weitere Kriterien, wie die maximale Länge die von Suchmaschinen indiziert werden. Hier schwanken die Zahlen zwischen knapp 1800 Byte bis zu 2048 Byte.

Damit lässt sich die Frage nach der maximalen URL-Länge nicht pauschal beantworten. Mit aktueller Software auf Server- und Client-Seite, sollten 1024 Byte für die URL kein Problem sein. Längere URLs sollten mit Vorsicht genossen werden und ihre Sinnhaftigkeit noch einmal hinterfragt werden.

curl zur Abfrage von REST-APIs benutzen

Die Aufgabe des freien Kommandozeilentools curl ist einfach beschrieben: Datentransfer. So unterstützt curl unterschiedlichste Protokolle wie FTP, HTTP, HTTPS, IMAP, SCP, SMB und viele mehr. Ein einfacher Download einer Datei über HTTP bzw. HTTPS würde mit curl wie folgt aussehen:

curl -O https://example.com/file.zip

Auch ein Transfer z.B. per FTP ist kein Problem:

ftp://example.com/file.zip

Allerdings beherrscht curl wesentlich mehr Operationen als nur das Herunterladen von Dateien. So kann curl genutzt werden, um REST-APIs zu benutzen. Diese APIs arbeiten nicht nur mit dem HTTP-Verb GET, sondern auch mit anderen Verben wie POST und PUT. Ein einfacher GET-Request wurde mittels curl wie folgt aussehen:

curl -X GET https://example.com/

Ein POST-Request wird auf die gleiche Art durchgeführt:

curl -X POST https://example.com/

Sollen zusätzlich Daten übertragen werden, so geschieht dies mit dem Parameter -d:

curl -X POST https://example.com/  -d '{
	field: "data",
	field2: "data",
	field3: "data"
}'

Damit werden die Daten im Body des Requests mitgesendet. Auch die Übergabe von Headern ist mittels curl möglich:

curl -X POST https://example.com/ 
 -H 'HeaderField: headerValue'
 -d '{
	field: "data",
	field2: "data",
	field3: "data"
}'

Manche APIs und andere Services blockieren Abrufe über curl manchmal. Dabei wird der Useragent von curl ausgesperrt. Allerdings kann dieser einfach geändert werden:

curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0" -X GET https://example.com/

Damit können solche fragwürdigen Maßnahmen, welche zum Ausschluss von curl führen, umgangen werden. Daneben verfügt curl über viele weitere Operationen bzw. Optionen. So kann z.B. mittels des Parameters -I nur der Header des Response bezogen werden:

curl -I -X GET https://example.com

Somit bietet curl die entsprechende Funktionalität um REST-APIs für Tests und ähnliches flexibel abzufragen.

Probleme mit der Synchronisation unter Enpass 6

Vor knapp einem halben Jahr bin ich vom Passwort-Manager 1Passwort in Richtung Enpass umgestiegen. Vor ein paar Tagen ist die neue Version Enpass 6 erschienen, welche eine neue Oberfläche, die Unterstützung für mehrere Tresore und einige andere Dinge mitbringt. Bedingt durch die Änderungen funktioniert die Synchronisation leider nicht mehr; so das diese neu konfiguriert werden muss.

Einige Neuerungen führen zu Problemen bei der Synchronisation

Hintergrund hierfür ist das Zurücksetzen der Einstellungen nach dem Upgrade auf Enpass 6. Unter Enpass nutzte ich WebDAV (in diesem Fall eine Nextcloud-Instanz) zur Synchronisation mit einer URL nach dem Schema:

https://example.com/remote.php/webdav/Apps/Enpass

Wird die bestehende URL genutzt führt dies zu einem Fehler in der Synchronisation. Bedingt ist durch die Änderung des Formates, welches von Enpass im WebDAV-Ordner abgelegt wird. Dieser muss vor einer erneuten Synchronisation gelöscht werden. Daneben muss die URL angepasst werden:

https://example.com/remote.php/webdav/Apps

Der Ordner Enpass muss nicht mehr explizit angegeben werden, da dieser unter Enpass 6 automatisch angelegt wird. Mit diesen Änderungen synchronisiert Enpass wieder ohne Probleme mit einem WebDAV-Ziel.