11 Sep 2011

Eigene Kurz-URLs

Submitted by ebertus

Mal wieder dem (beruflich zurückliegenden) IT-Umfeld Referenz erweisen, etwas Entwicklungsarbeit leisten, Neues lernen, Vorhandenes vertiefen. Nicht dass man (meine Wenigkeit) besser wäre als die externen Dienste, aber der volle Zugriff, der offene Sourcecode, die Datenhaltung unter eigener Regie und Kontrolle, das ist schon ein Wert an sich.

Die Zeiten, in denen man überwiegend kurze Adressen direkt in den Browser eingeben konnte, sein Ziel relativ direkt erreichte, diese Zeiten sind lange vorbei. Das Internet lebt von den Verlinkungen, von sog. "deep links" in der Regel auf tief in der Seitenstruktur enthaltene Inhalte, kaum über die Menüstruktur, bestenfalls via der entsprechenden Suchfunktionen zu erreichen. Derartige lange, komplexe Links zu handhaben, sie weiter zu geben ist oft nicht mehr vollkommen trivial. Der folgende Beitrag adressiert einen Teilaspekt dieser Problematik.

Lange Links im vollen Klartext "irgendwo" als Teil eines Kommentars unterzubringen ist nicht wirklich so toll, weder von der Optik her noch (möglicherweise) aus Sicht der Funktionalität als anklickbarer Link. Manche Zeichen im Link werden nicht von jeder Plattform richtig interpretiert und die Einbindung in HTML ist ebenfalls nicht immer möglich, gar zulässig. Eine Lösung, wie im Netz nicht unüblich, bieten verschiedene Dienstleister an. TinyUrl oder bitly sind bekannt, selbst ohne Anmeldung kann man sich für den dort einzukopierenden, langen Link einen Kurzlink generieren lassen, bei Tinyurl gar wahlweise mit Vorschau auf den originalen Link. Das vertrauensvolle Anklicken eines Link - und ohne zu wissen, was dahinter steckt - ist möglicherweise nicht immer zu empfehlen.

Soweit so gut und die zwei noch offenen Fragen adressieren 1. den bestenfalls temporären Altruismus des Bereitstellers eines derartigen Dienstes und 2. die Frage der Nachhaltigkeit bzw. bleibend gegebener Verfügbarkeit der Kurzlinks. Zum ersten Punkt darf man neben direkter und indirekter Werbung zur Finanzierung des Angebots davon ausgehen, dass die Menge der beim Nutzen eines derartigen Dienstes entstehenden Daten ein gewisses, zu monetarisierendes Auswertungspotential enthält. Abhängig von eben dieser Frage wird der Dienst weiter existieren; oder eben nicht. Rein praktisch und bei entsprechend vielfacher Nutzung müssten außerdem die Kurzlinks naturgemäß immer länger werden, es sei denn, ihre Lebensdauer wird begrenzt.

Eigene Webspace ist nicht mehr teuer, eine gängige Domain kostenseitig ebenfalls kaum der Rede wert. Manchmal bietet gar Bestehendes mehr als ausreichend die Möglichkeit beispielsweise so einen, oben beschriebenen Dienst selbst zu unterhalten, selbst oder bestenfalls im kleinen Kreis zu nutzen. Dieser existiert dann zumindest solange, wie die eigene Webpräsenz besteht, eine gewisse "Marke" über den Domainnamen, ein Status mag inclusive sein. Derartig kurze Namen wie das oben erwähnte bitly in der nutzbaren Form "http://bit.ly/xyz" sind für den .de-Raum nicht mehr zu bekommen aber in meinem Falle gibt es die lediglich als Reserve gehaltene Domain "notina.net". Während "http://www.notina.net" weiter auf die entsprechende ".com"-Domain umgeleitet wird bietet sich die damit einhergehende Form - und soweit der eigene Provider eine Unterscheidung nach Basisverzeichnissen zuläßt, dieses "http://notina.net/xyz" als Kurzlink an,  werden xyz  (in der Regel automatisch) hochgezählt.

Ein entsprechendes Tool, man ahnt es, steht mit YOURLS ebenfalls bereit. Die Installation ist im Grunde einfach, auch wenn dies relativ zu verstehen sein mag. Rudimentäre Kenntnisse bezüglich dem, was da auf der eigenen Webspace hinter den Kulissen so passiert, dieses KnowHow sollte man schon haben. Die FAQs von yourls geben einen ersten Einblick, was an Voraussetzungen, an Hinwendungen erwartet wird. Im Root des Webspace legt man ein neues Verzeichnis für yourls an und entpackt dorthin das heruntergeladene, gezippte yourls. Via dem providerseitigen Confixx (in meinem Falle) wird das Basisverzeichnis der zu nutzenden Domain genau dorthin umgelenkt. Die "config-sample.php" aus dem Verzeichnis "/includes" wird in "config.php" umbenannt und nach "/users" verschoben. Dann ist für die Webspace eine neue SQL-Datenbank zu erstellen sowie (unter Anderem) mit den dabei entstehenden Daten die "config.php" zu ergänzen, weitere Konfigurationsparameter dort einzutragen. Nun kann aus dem Verzeichnis "/admin" die "install.php" gestartet werden. Wenn der Vorgang erfolgreich war, die ".htaccess" angelegt ist, so erfolgt eine entsprechende Bestätigung.

Die im neu angelegten YOURLS-Basisverzeichnis enthaltene "sample-public-front-page.php.txt" kann jetzt um das ".txt" reduziert, also umbenannt werden und der Dienst ist darüber startbar, d.h.nutzbar.  Natürlich, im produktiven Betrieb wird man diese Datei umbenennen, verschieben oder gar löschen, da sie ja (als Default-Name und eben genau dort) öffenlich aufrufbar ist, jeder Andere seine Links shorten könnte, gar das System spamen. Ich habe mich daher und vorerst für das Umbenennen entschieden.

Für den gesicherten Zugang zum Admin-Bereich sind in der "config.php" entsprechende Daten zu hinterlegen. Mittelfristig scheint mir eine andere Lösung noch sinnvoller, optimaler beinahe. Es handelt sich um die Integration der Yourls-Funktionalität via einem Firefox-Plugin. Das gibt es bereits, nur die Stabilität muss noch verbessert werden. Der Vorteil liegt zum einen darin, die jeweils aktuelle Browseradresse direkt shorten zu können und zum anderen in der gesicherten Funktion via einem vom Yourls-API der eigenen Installation bereitgestellten Auth-Key, den das installierte Plugin referenzieren muss. Es beginnt nun also die produktive Testphase und die eingestellten Daten (Links) sollten in jedem Falle erhalten bleiben; lediglich das Handling ist noch zu optimieren.