Nur leider fehlt mir jetzt ein wenig Software, die ich vorher installiert hatte: BTNX und der MySql Query Browser wurden deinstalliert und finden sich auch nicht mehr in den Repositories.. Weitere Software fällt mir dann vielleicht noch bei der Benutzung auf, im Moment scheint mir alles andere da zu sein.

MySQL Query Browser

Zuerst suchte ich nach einer neuen Quelle für das Tool, las dann aber, dass dieses aus guten Gründen aus Pangolin entfernt wurde. Es gibt allerdings einen würdigen Ersatz für diese Tools: Die MySQL Workbench, welche man im Software Center von Ubuntu findet. Dieses bietet enorm mehr Features als die alten Tools. Es hat einen ER Diagramm Browser, Server Administration inklusive Überwachung und natürlich ach einen Query Browser.

Leider hat es nicht diesen genialen SQL Editor des alten Query Browsers, der Queries sehr intelligent mittels Drag und Drop zusammen stellen konnte. Ich muss mal schauen, ob ich auch ohne das klar komme, zumindest unterstützt die Workbench auch ein wenig beim Zusammenstellen der Queries.

BTNX

Warum BTNX nicht mehr in den Repositories vorhanden ist, kann ich nicht sagen. Sehr schade eigentlich, es ist eines der nützlichsten Tools für mich auf Linux, das einfach im Hintergrund vor sich hin werkelt. Ich habe mich schon total daran gewöhnt, dass ich durch Kippen meines Mausrads zwischen den Desktops rechts/links hin und her schalten kann, und habe schon einige meiner Arbeitsabläufe darauf ausgerichtet.

Man kann es sich aber immerhin noch recht problemlos selbst installieren. Auf dieser Seite gibt es einen Download für Pangolin. man findet dort die DEB Datei sowie den Hinweis darauf, dass sie von btnx-config abhängt. Ein Klick auf diesen Link lässt einen dann auch diese DEB Datei herunter laden. Diese beiden habe ich installiert (per Doppelklick, geht aber auch einfach über apt-get vom Shell aus). Ein Blick in das Dash, "btnx" gesucht und gefunden. Ein Klick darauf öffnet wieder die btnx Oberfläche sogar mit den alten Konfigurationen von mir, die sofort funktionieren.

Übrigens sind die Dateien über ein launchpad zu beziehen. Ich habe immer noch nicht gelernt, wie ich aus solchen direkten Downloads vernünftige Einträge in den Software Quellen von Ubuntu erzeuge. Wer mir das mal beibringen will: Der Kommentarbereit ist offen!

Der SysTray und KeePassX

Das ewige Problem mit dem System Tray unter Unity.. Auch bei 12.04 kann man einstellen, dass alle Apps in den Tray wandern dürfen. Allerdings wurden das Ubuntu KeePassX Paket so geändert, dass diese Option unter Unitiy gar nicht mehr eingeschaltet werden kann. Was das soll, ist mir ein Rätsel.

Fazit

Ubuntu Precise Pangolin läuft jetzt erst mal wieder bei mir. Ich habe noch nicht genau herum geschaut (das Wetter lockt einfach vom Rechner weg ). Auf den ersten Blick hat sich nicht so viel zu 11.10 geändert. Ich sollte es mir mal im Detail dann ansehen. Stabiler ist es für mich erst mal nicht unbedingt, das Software Center ist mir schon mehrmals jetzt abgeschmiert. Aber ansonsten läuft's. Später vielleicht mehr dazu.

Update

Mir schmiert hier ständig was ab und löst einen Fehlerbericht aus..

Warum ich überhaupt wieder nach neuen Geräten schiele, ist die Display Größe. Ich will etwas größeres. Deutlich größeres! Deshalb habe ich bisher sehr mit dem Galaxy Note geliebäugelt. Ein unglaubliches Gerät, hat alles was ich mir so vorstelle und eben ein riesiges Display, dessen Qualität ein echter Hingucker ist!

Ich durfte es nun schon 2 Mal jeweils für's Wochenende mit nach hause nehmen und habe es dort "im Alltag" ausprobieren können. Leider muss ich sagen, dass ich nach beiden Wochenenden leichte Schmerzen in den Händen und in den Fingern hatte. Das liegt vor allem daran, dass man es nicht immer entspannt mit einer Hand halten kann, es aber trotzdem ständig versucht. Wenn ich es in entspannter Position benutze, muss ich ständig aufpassen, dass es mir nicht aus den Händen gleitet. Im Liegen (z.B. im Bett auf der Seite liegend lesen) war es nahezu unmöglich zu halten. Es ist eher ein Arbeits- als ein Couch-Gerät. Ich muss mir also leider eingestehen, dass es offenbar für meine "normale Benutzung" ein bisschenzu groß geraten ist. Schade, ansonsten wäre es genau mein Ding (Gerade wegen der Größe!).

Am Samstag hatte ich dann das HTC One S in den Händen und war bereits von dessen Wertigkeit beeindruckt. Heute konnte ich mir dann das HTC One X mal in echt ansehen: Das was ich darüber gelesen habe und das was ich da in Händen hielt, sagte mir: Das wird wohl mein nächstes Handy. Der Screen ist der Wahnsinn (super scharf, tolle Farben), die Kamera scheint wirklich so gut zu sein, wie beschrieben wird, und wie nicht anders zu erwarten, reagiert es sehr flüssig. Das Styling gefällt mir auch. Der Screen ist etwas (spürbar) kleiner als beim Note, dafür liegt es aber auch super in der Hand und lässt sich eben problemlos mit einer Hand halten.

Technisch ist es im Moment wohl das beste, was man so bekommen kann, allerdings hat es auch ein paar Nachteile, die leider von Apple abgeschaut zu sein scheinen: Einen fest verbauten Akku und keinen SD Slot (also keinen erweiterbaren Speicher). Beides finde ich zwar nicht so prickelnd, allerdings ist es auch kein KO Kriterium für mich:

1. Der Akku scheint laut Tests ausreichend für einen Tag zu sein (also übliche Smartphone Kost). Für z.B. Caching Touren, die erfahrungsgemäß ordentlich Saft kosten und für die ich mir für's Desire einen dicken Akku geholt habe, würde ich dann auf einen externen Akku zurück greifen. Dies wäre also eine Lösung für "Spezialfälle"
2. Das HTC One X hat 32 GB freien Speicher für Daten. Für mein Desire habe ich damals vor allem eine schnelle Speicherkarte gesucht. Die hatte dann 8GB. Für heutige Verhältnisse ist das lächerlich wenig, aber ich habe darauf meine Musik, die ich unterwegs so höre und dailyme. Ich habe trotzdem immer noch Platz und hatte da schon nie Platzprobleme. Somit werden mir die 32GB sicher reichen.

Tja. Ich muss sagen, ich bin begeistert von dem Teil. Auf Twitter war gerade eine interessante Diskussion dazu. Wie sieht das bei euch so aus? Sucht ihr auch gerade neues? Und was sind eure aktuellen Favoriten? Vielleicht kann ich mich davon ja noch inspirieren lassen..

Sie benutzen den Service Hockey App. Dieser deutsche Service ist in der Tat sehr genial mit unglaublich vielen Optionen (z.B. eingeschränkten Testgruppen oder öffentliche Tests, einfach zu bedienende Management Konsole usw). Wir setzen den selben Service schon seit einiger Zeit bei dailyme ein, um unsere Betatester zu versorgen, und haben auch da gute Erfahrungen mit dem Service gemacht. Da dieser Service aber mindestens 10 USD pro Monat kostet, kommt er für kostenlose Apps wie z.B. mein Superious einfach nicht in Frage. Ich halte den Service in der Tat, so gut er auch ist, für etwas überteuert. Deshalb habe ich mich nach Alternativen umgesehen.

Offenbar haben sich andere darüber auch schon Gedanken gemacht, so versucht der alternative Market AndroidPIT gerade mit "Beta Apps" zu punkten. Die Idee ist prima: Ein Market hat bereits alles, was es dafür benötigt (Distribution und Update, Commnity usw). Es bietet Vorteile für alle: Entwickler werden in den Market gezogen, weil sie diesen Distributionskanal interessant finden (= mehr Apps), Anwender ebenfalls, weil sie in Beta Versionen stöbern können und den Market Betreiber kostet das nicht viel mehr, er bekommt aber mehr Entwickler, Anwender und Apps. Perfekt also.

Leider ist der Beta Apps Bereich bei AndroidPIT selbst noch sehr Beta und hat außerdem noch den selben Namensraum, wie der normale Market. Das bedeutet, dass man keine Beta Versionen von Apps hochladen kann, die bereits im Market publiziert sind, man kann dementsprechend nur Beta Tests von neuen Apps fahren. Das ist leider nicht mein Usecase. Somit habe ich mir jetzt einfach etwas eigenes gebaut. In nur einem Tag ist so zu sagen eine "Poor Mans HockeyApp" dabei entstanden.

Die Voraussetzungen

So schön die ganzen Optionen von Hockey App auch sind, für einen "kleinen Betatest" benötige ich davon nur sehr wenige.

• Ich will einen Service haben, bei dem ich die Beta Apps hinterlegen kann. Ich benötige keine geschlossenen Benutzergruppen, wer sich traut, die Beta auszuprobieren, den will ich nicht in dem Wunsch beschränken.
• Mit den Beta Apps müssen Metainformationen zu der App hinterlegt und abgefragt werden können. Also so etwas wie Programmname, Version, "Was ist neu" usw.
• Ich benötige eine möglichst einfach einzubindende Bibliothek für Android, die automatisch nach neuen Versionen schaut und diese dann, falls gefunden, dem Beta Tester InApp mitteilt und einen Update vornehmen kann.

Das ist es eigentlich schon. All das habe ich mir gestern in einem Tag zusammen gebaut.

Carotine Server für Beta Distribution

Der Cartine Distributionsserver erfüllt bereits alle oben genannten Kriterien, allerdings ist er derzeit noch etwas "raw".. Er hat nur die notwendigste Oberfläche (oder anders ausgedrückt: Sieht ziemlich scheiße aus ), hat keinerlei Admin Interface oder Benutzerverwaltung. Somit wird alles über Dateien gesteuert: Wenn man an die Verzeichnisse auf dem Server heran kommt, dann kann man auch eine Beta Distribution einrichten. Das Einrichten ist allerdings auch nicht sehr schwer: Man legt im Store Verzeichnis ein weiteres Verzeichnis für die neue Beta Distribution an, hinterlegt dort die APK Datei und eine JSON Datei mit entsprechenden Metainformationen. Den Rest (Beschreibungsseite, Download Seite und programmatisch abfragbare Metainformation) erzeugt sich dann der Carotine Server aus beidem.

Carotine hat einen Vorteil zu Services wie HockeyApp: Im Gegensatz zu diesem kann Carotine auf jedem beliebigen Server eingerichtet werden, ist also völlig unabhängig von einem zentralen (bezahlten) Service. Wer einen Server und dort ein wenig Bandbreite zur Verfügung hat (normaler Weise benötigt es ja nicht viel, weil so viele Nutzer nun auch keine Beta App installieren und testen), dann kann man sich seinen eigenen Beta Service einrichten. Der Server muss nur PHP können und eine .htaccess akzeptieren. Eine Datenbank ist nicht erforderlich. Nach genau so was hatte ich gesucht.

Carotine Android Bibliothek

Zusätzlich zu diesem Server habe ich mir noch eine Bibliothek für Android gebaut, die alles ausführt, was man InApp für einen Beta Test benötigt:

• Sie schaut regelmäßig auf dem Carotine Server nach, ob es eine neue Version der Anwendung gibt.
• Wurde eine gefunden, so poppt ein Dialog hoch, der das meldet und ein "WhatsNew" darstellt, das vom Carotine Server abgeholt wurde.
• Per Knopfdruck kann man den Update ausführen.

Einen Eindruck von der Bibliothek in Aktion kann man sich auf obigen Bildschirm Foto machen.

Dabei ist das Einbinden der Lib in die eigene App denkbar einfach: Die Bibliothek ist eine Android Library, die man z.B. zusätzlich zu seiner App in den Eclipse Workspace ablegt und mit der App verbindet. Ein einfacher Aufruf in der Haupt-Activity der Applikation ist alles, was man dann noch einbinden muss:

Carotine.check(this, "carotine.meinserver.com", "meineapp");

Dabei wird der Host übergeben, auf dem der eigene Carotine Server installiert ist, sowie der Name der Beta App unter dem die App am Carotine Server hinterlegt wurde. That's it.

Fazit

Carotine habe ich komplett innerhalb eines regnerischen Nachmittags erstellt und funktionsfähig bekommen. Gerade der Server aber auch die Lib benötigen noch ein wenig Feinschliff. Ich denke, wenn ich mit der Stabilität und Funktion einigermaßen zufrieden bin, werde ich ein Projekt bei GitHub aufsetzen, um den Service OpenSource zu machen. Vielleicht sind auch andere Entwickler auf der Suche nach so einem kostengünstigen Service, die eigenen Beta Apps zu verteilen.

Open Source bei GitHub könnte auch für mich prima sein, evtl finden sich andere Entwickler, die weitere Ideen haben und Carotine erweitern. Der Carotine Server ist so aufgebaut, dass er im Prinzip Updates zu allem verteilen kann, er ist in keiner Weise auf Android Apps beschränkt. Die Meta Informationen können frei hinterlegt werden und eine (andere) Lib kann diese dann 1:1 abfragen.  Somit könnte man dort auch Updates für PHP Plugins, Desktop Anwendungen usw hinterlegen, man müsste sich dann nur die Lib bauen, die den Server abfragt und das Update darstellt und ausführt.

Der Name Carotine

Als Abschluß: Was soll eigentlich der Name? Nun.. Als Assoziation zu "Beta" fiel mir vor allem "Betakarotin" ein. Gibt man das Wort in Wikipedia ein, kommt man sofort auf dieses (deutsche) Wort. Englisch ausgesprochen klingt das doch recht cool, oder?

Somit ist das Icon für Carotine eine Karotte. Diese hier ist aus einer Public Domain Datenbank, wer eine schickere als Icon malen kann, ist herzlich willkommen, das zu tun!

Vorteile eines eigenen Servers

Ein eigener Server ist vor allem eines: Unabhängig von externen Services, auf die man sich (gerade wenn sie kostenlos sind) nicht unbedingt immer verlassen kann. Den eigenen Server kann man selbst verwalten, man kann ihn auf andere WebProvider umziehen lassen und so weiter.

Ein weiterer Vorteil: Es liegt in der Natur des OpenID Services, dass der Service Anbieter genau mitbekommt, auf welche Seite man sich wann einloggt. Es ist hier also eine perfekte Möglichkeit gegeben, Nutzerprofile zu sammeln. Deshalb benutzte ich z.B. nie Services als OpenID Provider, die für ihre Datensammlung bekannt sind (z.B. Google und Yahoo, obwohl man mit ihnen die einfachste OpenID hat). myOpenID war bisher mein Kompromiss: Der Service ist erst einmal nur auf OpenID spezialisiert. Aber natürlich gehört auch er einer Firma..

Im schlimmsten Fall könnte ein externer OpenID Anbieter den Server so manipulieren, dass sich der Besitzer mit der ID eines Nutzers bei Services einloggt. Das wird sicher bei keinem der bekannten Anbieter passieren, aber 100%ig sicher ist man auch hier nur, wenn man seinen eigenen Server hat.

Die Auswahl der Software

Auf openid.net gibt es eine Liste mit bekannten Implementierungen eines OpenID Servers. Diese Liste scheint schon recht alt zu sein, einige der Links zeigen ins Leere. Am viel versprechendsten erschien mir Prairie. Auf der Seite der Software findet man einen ebenfalls sehr alten Download für eine 0.2 Alpha, aber bereits im openid.net Wiki einen Hinweis darauf, dass jemand diese Alpha bereits erweitert und in GitHub abgelegt hat.

Also habe ich mir die Version aus GitHub gezogen, was ja ziemlich einfach auch ohne Git Kenntnisse geht, GitHub bietet einen prominenten Button ZIP, der einem den Inhalt des Repositories als ZIP herunter laden lässt. Also habe ich mir eine Subdomain id.brockha.us angelegt, den Inhalt des Archives dahin übertragen und die Install Routine aufgerufen.

Installation war (wenn man weiß, was OpenID ist) ziemlich selbst erklärend und einfach. Prairie bietet sogar an, den Server im Single- oder MultiUser Betrieb zu fahren. Für den MultiUser Betrieb muss der WebProvider Domain Wildcards akzeptieren (also in meinem Fall *.id.brockha.us nach id.brockha.us übergeben). Das ist bei meinem Provider AllInkl offenbar nicht einstellbar und außerdem werde wohl nur ich meinen OpenID Provider benutzen, so habe ich ihn als SingleUser installiert.

So weit so gut, danach gingen die Probleme los. Wenn ich mich einloggen wollte oder irgendeine andere Seite als die Hauptseite aufrufen wollte, bekam ich PHP Fehler angezeigt, nichts ging nach der Installation wirklich.

Anpassung von Prairie

Ich habe daraufhin relativ viel Zeit in der Auffindung der Probleme und deren Lösungen verbracht. Die meisten Probleme kamen durch Eigenheiten meines Providers AllInk zustande (die bei anderen Providern aber auch auftreten können). GitHub macht es extrem einfach, ein öffentliches Repository in den eigenen Account zu packen und zu bearbeiten: Ich drückte bei dem Prairie Repo auf "Fork", schon hatte ich eine eigene Version in meinem Account, die ich nun bearbeiten und öffentlich verfügbar machen konnte.

Ich will nicht auf die einzelnen Details hier eingehen, was ich verändert habe. Es war gar nicht mal so viel, wer an den Details interessiert ist, kann sich ja die Commit History meines Prairie Repositories ansehen.

Umstellung der OpenID

Wer so schlau war, seine OpenID URL per Delegation zu benutzen, der hat es nun einfach bei der Umstellung. Bei allen Services, bei denen ich OpenID als Login benutze, habe ich meinen Account mit der URL blog.brockha.us verbunden. Diese hatte ich über Delegation so eingestellt, dass meine eigentliche OpenID bei myOpenID benutzt wurde. Ich hatte in der Seite, die unter blog.brockha.us gefunden wird, folgendes im Header hinterlassen:

<link rel="openid.server openid2.provider" href="http://www.myopenid.com/server" />
<link rel="openid.delegate openid2.local_id" href="http://brockhaus.myopenid.com" />

Diesen Eintrag habe ich geändert, so dass auf meinen privaten OpenID Service delegiert wird:

<link rel="openid.server openid2.provider" href="http://id.brockha.us/login" />
<link rel="openid.delegate openid2.local_id" href="http://id.brockha.us/" />

Auf diese Weise kann ich mich weiterhin wie gewohnt mit der URL blog.brockha.us überall einloggen ohne eine Zuordnung bei all den Services ändern zu müssen. Durch die Änderung wird von meiner OpenID URL dann nicht mehr auf meine ID bei myOpenId delegiert, sondern auf meine private.

Update: Wenn ihr Prairie als Multiuser Server einrichtet, dann sollte die Delegation wie folgt lauten (nicht von mir getestet):

<link rel="openid.server openid2.provider" href="http://id.brockha.us/login" />
<link rel="openid.delegate openid2.local_id" href="http://[username].id.brockha.us/" />

[username] dann entsprechend ersetzen.

Fazit

Dadurch dass mein OpenID Server nur meine ID hosten muss, ist der Einloggvorgang nun wieder rasend schnell erledigt. Außerdem habe nur ich Zugriff auf mein Login Protokoll usw. Die Installation des Prairie Servers ist eigentlich super simpel. Da, wo es Probleme gab, habe ich entsprechende Änderungen eingebaut, von denen ihr profitieren könnt.

Meine Änderungen sind abwärts kompatibel. Dies bedeutet: Meine Version läuft auf allen Servern, auf denen Prairie auch vorher schon lief. Zusätzlich aber auch auf solchen, die Eigenarten wie AllInkl haben. Und auch bei mir gibt es den ZIP Button. Wer sich also auch einen eigenen OpenID Provider bauen will, kann dies gerne mit meinen Anpassungen tun. Es ist wirklich einfach!

Links:

• Download der von mir angepassten Version
• Mein Repository bei GitHub
• Ansicht der Version im Betrieb

Entsprechende Knöpfe gibt es dann auch bei den "Eigenen Einstellungen", die die korrekten URLs für die entsprechenden Service Benutzer bezogen auflösen und eintragen. Das funktioniert prima.

Auf dem Screenshot sieht man aber nun auch ein Problem: Es gibt ein bisschen zu viele Möglichkeiten sich einzuloggen und es sieht sogar so aus, als ob man sich mit seinem Google Account oder einer OpenID URL einloggen könnte. Das ist aber nicht der Fall: Alles sind OpenID Logins und man kann pro Benutzer nur eine OpenID URL hinterlegen, die ihn identifizieren kann.

Login mit nur einem Klick

Ich habe das nun noch ein wenig erweitert: Wenn bisher noch kein Benutzer eine OpenID konfiguriert hat, macht der Login über diesen Mechanismus keinen Sinn, da kein Benutzer mit irgendeiner ID identifiziert werden kann. In dem Fall zeigt das Login nur einen Infotext an, der über die Situation informiert.

Gibt es aber bereits Benutzer mit einer erfolgreich konfigurierten OpenID URL, so wird nun einfach eine Auswahlbox angezeigt, in der man einen Benutzer mit OpenID auswählen kann und dann einfach auf den Login Knopf daneben drücken kann. Das Plugin loggt dann genau mit der OpenID URL ein, die für den ausgewählten Benutzer konfiguriert wurde. (Siehe Screen nebenan).

Das ist eine sehr komfortable Art, sich einzuloggen, sogar komfortaber als die BrowserID. Gerade wenn es nur einen konfigurierten Benutzer gibt, kann man sich durch einen einfachen Klick auf einen Button einloggen (wenn man sich bereits beim OpenID Provider authentifiziert hat). Sehr schick, wie ich finde!

Die Version ist bereits in Spartacus. Das soll's dann aber auch erst einmal gewesen sein mit der OpenID und BrowserID.

Somit bietet sich BrowserID also perfekt für Services an, die eine eindeutige Zuordnung von Benutzer zu EMail haben. Bei diesen Services kann man sich mit einem einfachen Klick (und normaler Weise ohne jegliche weitere Angabe) beim Service einloggen.

Natürlich ist unser Liebligsblog Serendipity genau so ein Service. Jedem Autor im Blog ist normaler Weise bereits eine EMail Adresse zugeordnet, damit diesem z.B. Informationen über Kommentare im Blog zugestellt werden können. Folglich twitterte ich letzte Nacht:

Leider sind mir beim Erstellen ein paar blöde Copy&Paste Fehler unterlaufen, so dass das aktuelle BrowserID Plugin V1.0 nur zusammen mit einem installiertem OpenID Plugin funktioniert. Das habe ich inzwischen bereinigt, im Laufe des morgigen Montags liefert Spartacus dann die Version V1.1, die dann auch alleine funktionieren sollte.

Hier noch schnell ein Screencast, mit dem ihr einen ersten Eindruck vom OpenID und BrowserID Login in Serendipity bekommen könnt:

BrowserID ist ein noch relativ junger Service, der Mitte letzten Jahres entstanden ist, so ist es nicht verwunderlich, dass er mir bisher noch nicht aufgefallen ist. Da auch das ein Single Sign-On Service ist, ähnelt die BrowserID der OpenID, geht aber einen anderen Weg: Hier authentifiziert man sich nicht mit einer persönlichen URL sondern mit der eigenen EMail Adresse. Damit das funktioniert, kann BrowserID nicht so dezentral aufgebaut sein, wie es bei OpenID der Fall ist. Es gibt einen Service, bei dem man seine EMail registriert und verifiziert. Der Service wird allerdings von der Mozilla Foundation betrieben, somit ist hier wahrscheinlich leichter Vertrauen zu fassen, als z.B. zu Microsoft und ihrem Passport damals.

Dafür hat die BrowserID allerdings einen wichtigen Vorteil: Sie beruht auf EMails, von denen man sicher sein kann, dass sie zu einem Benutzer gehören, da sie von BrowserID verifiziert werden. Mit einer OpenID kann man auch EMails konfigurieren, jedoch sind diese nicht verifiziert, jeder kann eine beliebige EMail nennen, auch die eines anderen. Die EMail ist bei OpenID (im Gegensatz zu BrowserID) nicht Teil der Authentifizierung, sondern nur eine optionale Beschreibung der Person, die sich einloggen oder registrieren möchte.

Das ist ein recht entscheidender Unterschied, denn für OpenID muss man beim Consumer Service speziell einstellen, welche OpenID URL zu einem User gehört. Mit BrowserID muss man nur definieren, welche Email zu einem Account gehört, und das ist bei den meisten Services sowieso bereits konfiguriert.

Somit bietet sich BrowserID also perfekt für Services an, die eine eindeutige Zuordnung von Benutzer zu EMail haben. Bei diesen Services kann man sich mit einem einfachen Klick (und normaler Weise ohne jegliche weitere Angabe) beim Service einloggen.

Hier ist das Video, das Mozilla am Anfang ausgab, um BrowserID zu beschreiben. Der Service sieht inzwischen etwas anders aus, aber ihr bekommt die Idee, was BrowserID sein soll und wie einfach es funktioniert:

Dabei ist es ziemlich einfach, mit dem Plugin ein OpenID Login für sein Blog zu konfigurieren: Es benötigt erst einmal gar keine Konfiguration. Die drei Eingaben sind dafür da, um eine (optionale und zusätzliche) OpenID Delegation für sein Blog einzurichten.

Man muss hier nur eines konfigurieren: Die Zuordnung, welcher Blogautor mit welcher OpenID URL idenifiziert werden soll. Dies kann man für sich in den "Eigenen Einstellungen" ganz unten erledigen. Danach kann man sich mit dieser URL am Blog anmelden.

Dinge, die ich angepasst habe:

• Ich habe die  reichlich veraltete PHP OpenID Bibliothek, die das Plugin verwendet, auf den neuesten Stand gebracht.
• Ich musste einige Anpassungen vornehmen, damit das Plugin mit den recht rigiden Einstellungen der 1.7-alpha Version von Serendipity zu PHP Warnungen umgehen kann.
• .. und natürlich habe ich die Konfiguration des Plugins mit der oben aufgeführten Beschreibung zu dem Plugin angereichert.

Ich denke, so sollte das Plugin nun viel leichter benutzbar sein. Viel Erfolg mit dem OpenID Login für euer Blog, die neue Version ging letzte Nacht nach Spartacus und sollte im Laufe des Samstags verfügbar sein.

Update1: Ich habe gerade das OpenID Plugin aus Spartacus hier in mein produktives Blog installiert. Es scheinen nicht alle meine Änderungen ausgeliefert worden zu sein und es funktioniert hier nicht richtig. Ich schaue mal, was das ist. Also besser erst mal nicht updaten, bis ich das Problem identifiziert habe!

Update2: Vermutlich hatte ich meinen letzten Commit genau in der Zeit abgeliefert, als Spartacus gerade am einlesen war, somit wurde dieser nicht mehr mit ausgeliefert. Dieser Commit war aber nicht wichtig, er machte das Plugin nur "schöner". Allerdings gab es noch ein Problem in der neuen OpenID PHP Bibliothek, das verhinderte, dass das Plugin bei mir im produktiven Blog lief. Dafür habe ich noch einen Patch eingespielt, damit läuft es nun auch bei mir hier. Update ging nach Spartacus. Bitte erst updaten, wenn ihr die Version 0.6 in Spartacus findet, was morgen im Laufe des Tages der Fall sein sollte.

Um dieses Problem zu beheben, wurden so genannte Single Sign-On Services erfunden. Diese funktionieren so, dass man sich nur bei diesem einen Single Sign-On Service (dem so genannen Provider) einloggen muss, und weitere Services (die Consumer) sich dann das Login und die Beschreibung des Benutzers von dort abholen. Der Vorteil ist klar: Man muss sich nur ein einziges Name / Passwort Paar merken und sich auch nur einmal einloggen.

Einführung

Der erste Single Sign-On Service dieser Art, der mir bekannt wurde, war 1999 der Microsoft .NET Passport. Damals war das Misstrauen in einen Login Service recht hoch, der von einer einzigen kommerziellen Firma betreut wird. So entwickelte sich ab 2005 ein weiterer Quasi Standard, die OpenID. Das OpenID Protokoll kann von beliebigen Providern angeboten werden, es ist dezentral aufgebaut. Man kann z.B. seinen Google Account als OpenID Provider benutzen und inzwischen sogar seinen .NET Passport, so man einen angelegt hat.

Der Vorteil von OpenID ist, dass es nicht auf einen speziellen Anbieter festgelegt ist (so wie .NET Passport damals). Jeder Service, der ein Login unterstützt, könnte auch als OpenID Provider fungieren. Man hat hier also die freie Wahl, welchem Service man vertrauen möchte, und kann sogar so weit gehen, einen eigenen OpenID Service aufzusetzen.

Nebenbei dient OpenID auch nicht nur als schlichtes Login. Man kann alle möglichen Informationen für sich hinterlegen (EMail, Adresse usw), die OpenID Consumer abfragen können (nachdem man es ihnen erlaubt hat). Wenn man sich bei einem Service also gleich mit einer OpenID registriert, fällt dadurch das lästige Ausfüllen der Formulare flach oder wird zumindest minimiert.

Da OpenID dezentral ist, loggt man sich bei den Services mittels Angabe seiner persönlichen OpenID URL ein. Mit Hilfe dieser kann der Consumer dann die ID des Benutzers abfragen. Seine persönliche OpenID URL bekommt man von dem für sich gewählten OpenID Provider mitgeteilt, oft ist es der Link auf das eigene Profile.

Eine OpenID einrichten

Services, die OpenID als Login oder zum erzeugen eines neuen Accounts anbieten, haben eine Eingabe, die meist wie folgt aussieht:

Diese Eingabe erwartet die OpenID URL des Benutzers. Wie bekommt man nun eine solche? Nun, vermutlich hat man schon eine. Wenn man z.B. einen Google Account hat, kan man folgende URL öffen.

http://google.com/profiles/me

Über diese wird die eigene Profil Seite bei Google geöffnet. Bei mir ist das z.B.

https://plus.google.com/100089461645597573094/posts

Diese kann als OpenID URL benutzt werden. Ist man bereits bei Google eingeloggt, so wird sie als OpenID erkannt und der entsprechende Service kann weiter machen, ansonsten wird man zu Google weiter geleitet und muss sich dort erst einloggen.

Ein OpenID Provider ist natürlich ein Service, der genau erfährt, wann welcher Benutzer sich bei welchem Service anmelden wollte. Das ist sicherlich ein guter Grund, warum auch Google eine OpenID anbietet. Es reichert das erhebliche Wissen, das Google sowieso schon über seine User hat, um weitere Informationen an. Wer das nicht will, aber nicht gleich einen eigenen OpenID Server einrichten will / kann, dem würde ich empfehlen einen Provider zu benutzen, der immerhin nur OpenID anbietet und somit nicht die Informationen mit anderen vermischen kann.

Ein solcher Provider ist myOpenID.com.

myOpenID.com

Bei myOpenID.com kann sich jeder kostenlos eine OpenID erstellen, man kann dort sogar unterschiedliche Identitäten hinterlegen, die z.B. unterschiedliche Emails, Aufenthaltsorte oder Benutzernamen an den OpenID Consumer übermitteln. Die Registration bei OpenID sollte recht selbst erklärend sein.

Vor allem sollte man seinen Benutzernamen bei myOpenID mit Bedacht wählen, denn dieser wird nachher Teil der von myOpenID für Logins zur Verfügung gestellten URL sein. Mein Benutzername bei myOpenID ist brockhaus, meine URL, die mir myOpenID zur Verfügung stellt, ist somit http://brockhaus.myopenid.com.

Wer sich jetzt vielleicht darüber wundert, dass ich meine OpenID hier so bekannt gebe: Das schöne ist ja eben, dass man diese nicht (im Gegensatz zu normalen Logins) geheim halten muss. Wer sie benutzt, muss sich bei myOpenID einloggen, damit sie für einen Consumer lesbar wird, und zwar mit meinem Login bei myOpenID. Letzteres muss ich natürlich dann geheim halten.

OpenID Delegation

Die OpenID URL bei myOpenID ist ja noch einigermaßen merkbar. Aber weißt Du noch die URL, die Du benutzen kannst, wenn Du einen Google Account hast?

Durch einen Trick ist meine eigene OpenID URL inzwischen eine, die ich mir gut merken kann: Die URL meines Blogs. Das habe ich über OpenID Delegation gelöst. Bei der Delegation wird zwischen dem Consumer und dem Provider ein Delegator geschaltet. Das funktioniert so:

• Beim Consumer (dem Service, bei dem man sich anmelden möchte) trägt man die URL des Delegators ein. In dem Fall also die URL meines Blogs.
• Der Consumer schaut bei der URL nach, ob dies ein Provider ist. Ist dies nicht der Fall (so wie im Falle meines Blogs), so schaut der Consumer, ob er hier eine Delegations Beschreibung findet, was im Falle meines Blogs zutrifft. Wer den Code meiner Blog Seite genau ansieht, erkennt es: Hier ist meine OpenID bei myOpenID eingetragen.
• Der Consumer erkennt dies und fragt nun bei myOpenID nach und führt das OpenID Handshake so aus, als wenn ich direkt meine URL bei myOpenID eingergegeben hätte.

Das hat nun 2 Vorteile:

Zum einen kann man so eine Delegation auf jeder beliebigen Webseite einrichten, für die man den HTML Code verändern kann und deren URL man sich gut merken kann. Es muss hier keine spezielle Funktion hinterlegt werden. In meinem Blog findet man die folgenden beiden Zeilen im Head Bereich meines HTML:

<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://brockhaus.myopenid.com" />

Dabei ist der openid.server der Dienst, der den OpenID Service zur Verfügung stellt und openid.delegate die OpenID URL, auf die man delegieren möchte. Nachdem man dieses auf seiner Webseite hinterlegt hat, kann man nun diese als OpenID URL benutzen anstatt des eigentlichen Providers.

Das geht auch mit Google. Hier wäre der (von mir selbst nicht ausprobierte sondern ergooglete) Eintrag:

<link rel="openid2.provider" href="https://www.google.com/accounts/o8/ud?source=profiles">
<link rel="openid2.local_id" href="https://profiles.google.com/[YOUR PROFILE ID]"> 

Der zweite Vorteil an der Delegation ist: Wenn man bei allen Services, die OpenID Logins unterstützen, immer seine eigene Seite als URL angegeben hat, fällt ein Wechsel auf einen anderen OpenID Provider viel leichter. Man muss dann nicht bei allen Services die OpenID Verbindung erneuern, sondern ändert einfach nur die Delegation im HTML seiner Seite.

Fazit

OpenID ist schon älter, hat sich etabliert und wird als Quasi Standard für Single Sign-Ons angesehen. Es gibt viele Services, die dieses Handshake unterstützen. Ich verwende es schon länger überall dort bevorzugt, wo es mir angeboten wird, denn gerade mit einer gut zu merkenden Delegation ist es sehr einfach zu benutzen und erspart einem die ewige Suche und das Einprägen von neuen sicheren Passwörtern.

Nebenbei kann man sich auch in das Serendipity Blog über OpenID einloggen. Dazu muss man das OpenID Plugin installieren. Dieses ist in Spartacus noch etwas "beta", aber ich sitze gerade daran, es zu erneuern und besser nutzbar zu machen. Doch davon soll dann ein weiterer Artikel berichten.

Ausnahme wären hier Strategie Spiele, da hier die Maus ein recht entscheidendes Spielhilfsmittel ist. Diese würde ich sicher noch am Laptop zocken. Gerade entdecke ich eine interessante Meldung auf Golem.de über ein freies und kostenloses Echtzeit Strategie Spiel namens 0AD, das für alle relevanten Betriebssysteme verfügbar ist. Es ist aktuell noch in der Alpha Phase, sieht aber schon ziemlich schön aus und fällt mir auch durch die stimmungsvolle Hintergrundmusik auf:

Unter Ubuntu kann man das mit 3 Kommandozeilen installieren:

sudo add-apt-repository ppa:wfg/0ad
sudo apt-get update
sudo apt-get install 0ad 

Ich habe es gerade mal schnell installiert und kurz rein geschaut. Installation war völlig problemlos und es sieht wirklich so aus und klingt wie in dem Video. Mal schauen, ob ich nicht doch mal wieder die ein oder andere Runde am Desktop zocke..