snirgel.de - Es ist im Computer drin » Uncategorized

Linklog – 312376.85052004055

snirgel — Mon, 16 Aug 2010 10:45:45 +0000

Wenn das in der Überschrift steht, dann kommt ein Post mit Links, die ich in der letzten Zeit hilfreich, cool, witzig oder vielleicht auch doof fand. Anzumerken ist, dass ich dabei nicht den Anspruch auf absolute Aktualität habe, denn auch Sachen die schon etwas älter sind können ja trotzdem gut sein und einem das Leben erleichtern und verschönern.

HTML5 Boilerplate
Paul Irish und Divya Manian haben eine HTML5-Template-Schablone gebastelt, die man quasi als Vorlage nutzen und weiterverarbeiten kann. Alles dazu fintet ihr unter html5boilerplate.com und den aktuellen Code dazu natürlich bei github

jQuery Mobile Project
Auch wenn ich in Sachen mobile mehr der Steinzeitmensch bin find ichs natürlich cool, dass man sich mit dem Projekt darum kümmert, eine platformübergreifende Lösung für JS-Mobile-Applikationen zu bauen: http://jquerymobile.com/. Vielleicht holt mich das ja dann auch aus der Steinzeit in die Neuzeit zurück.

HTML Entititities
Um mit euch meinen wunderschönen Code teilen zu können habe ich mich auf die Suche nach einem Wp-Plugin gemacht, was mir die HTML-Tags in Entities umwandelt, damit alles richtig dargestellt wird. Nach erfolglosem Finden bin ich aber auf dies kleine Tool gestoßen, was per Button-Klick alles umwandelt. Sicherlich auch nicht der Königsweg, aber trotzdem nett und mir eine Erwähnung wert.

Competition! Competition! Competition!
Leider scheitere ich immer an meiner eigenen Unkreativität und stehe mir deswegen selbst im Weg, um an sowas teilzunehmen, trotzdem finde ich die Aktion JS1k großartig. Ziel ist es ein Javascript zu schreiben, was kleiner als 1 Kilobyte und dabei trotzdem cool ist. Vielleicht hab ihr ja ne Idee???

Feel free to Flattr this post at flattr.com, if you like it.

Javascript: Klickst du schneller

snirgel — Fri, 06 Aug 2010 11:30:13 +0000

Ganz vergessen vorm Urlaub zu veröffentlichen:

Jaja…immer noch die onclick – Geschichte. Dies wird dann aber der letzte Post dazu, versprochen. Ich hab da aber nach langem Rumdiskutieren und Recherchieren mal ein wenig getestet und will euch die Ergebnisse nicht vorenthalten, falls ihr mal vor dem selben Problem steht.

Die Sache war nämlich die, dass mein CTO und ich nicht auf einen Nenner gekommen sind, ob wir trotz der großartigen Erkenntnis mit dem data-attr nicht doch onclick benutzen sollen. Argumente für und gegen Beides gab es ausreichend. Es mußten also Fakten her und die sollten sich daraus generieren, was nun beim initialen Laden letztendlich schneller ist.

Um dies rauszufinden bin ich zunächst hergegangen und habe eine Seite gebaut, die mir 1000 links erzeugt hat und mir einen Timer je ans Anfang und Ende des Body-Elements gesetzt:


  
  
    dumdidum

Die Seite habe ich jetzt 30 mal geladen und die Zeit gemessen um einen Referenzwert zu bekommen.
Um den Durchschnitt zu bilden habe ich von den gesammelten Zeiten je die schnellste und langsamste Zeit rausgestrichen, also folgende Rechnung durchgeführt:

Durchschnitt = ∑(time(1…29))/28 (->ich bin nicht so gut in Formeln aufstellen wie man merkt, aber ich denke, ihr wißt, was ich meine)

Dann habe ich meinen Link mit einem onclick bestückt:


  
  
    dumdidum

Selbiges noch einmal in der bind-click-unobstrusive-data-attr Variante:


  
  
    
      dumdidum

Nach wiederum je 30 Reloads und obiger Rechnung ergaben sich zum allgemeinen Erstaunen folgende Ergebnisse:

Ohne Klick:	1577,50 Sekunden
Late Binding:	1726,03 Sekunden
onclick:	1885,07 Sekunden

Irgendwie hatte ich nicht damit gerechnet, dass das late-binding wirklich schneller ist, als das gute alte onclick. Warum das so ist, kann ich mir auch nicht ganz erklären. Ich schätze mal, dass es daran liegen könnte, dass bei jedem onclick ein Event-Objekt instanziiert wird und das wohl seine Zeit dauert, wenn das bei jedem onclick extra gemacht wird, als eben gesammelt nachher. Aber wie gesagt, im Detail hab ich keinen Plan.

Ich hoffe mal, dass das Ganze jetzt nicht zu sehr nach Milchmädchenrechnung aussieht, denn natürlich könnte man meinen, dass nach 30 Reloads und bei der Art der Messung wahrhaftig keine validen Ergebnisse zustande kommen. Aber meiner Ansicht nach, ist eine klare Tendenz zu erkennen, dass das late-binding etwas performanter abläuft.

Feel free to Flattr this post at flattr.com, if you like it.

JS: onclick war die Frage, HTML5 die Antwort?

snirgel — Wed, 14 Jul 2010 06:29:47 +0000

Gestern hatte ich ja die Frage aufgeworfen, ob das gute alte onclick eigentlich noch verwendet werden soll und/oder ob man auf Biegen und Brechen auf unobstrusive bestehen sollte. Mein größtes Problem bei der ganzen unobstrusive Geschichte war dabei, dass ich mir Information wie, an welche Action und mit welchen Parametern, irgendwo im HTML merken muss, um das ganze möglichst generisch zu behandeln.

Nach einigen Diskussionen und Recherche ist mir eine Lösung untergekommen, die ich zu diesem Zeitpunkt zwar warscheinlich nicht implementieren werde, ich aber trotzdem irgendwie großartig finde (zugegeben, ich habe mich mit HTML 5 bisher noch nicht sonderlich auseinandergesetzt, weil “Never trust a draft”). Deswegen hier dann mal der Ansatz für alle, die wie ich vielleicht noch ein wenig hinterher sind:

1. Man definiere ein Element und füge die in HTML5 vorgesehen data-attribute hinzu:

  
    
      contentzeug

2. Man hole sich die gesetzten data-attribute im Javascript
2.1 Einmal für die doofen Browser statisch:

jQuery('.listeelement').live( "click", function() {
  var action = this.getAttribute('data-action');
  var id = this.getAttribute('data-id');
  var params = this.getAttribute('data-params');
}

Statisch deswegen, weil ich hier beim im Javascript auch immer genau wissen muss, welche data-attributes gesetzt sind

2.2 Für die doofen Browser mit jQuery-Plugin und nicht ganz so statisch, da es eine Methode gibt, die alle data-attribute holt

jQuery('.listeelement').live( "click", function() {
    var mydataset =  jQuery(this).dataset();
    var myaction = mydataset.action;
    delete mydataset.action //damit die action nicht nochmal ans GET/POST als Param dran gehangen wird
    doSendRequest(myaction, mydataset);
});

2.3 Oder ganz einfach wie in der HTML5-Spec beschrieben, was im Endeffekt wohl dasselbe ist, wie 2.2. Da ich das Plugin nicht ausprobiert habe, kann ich derweil nicht sagen, was es mit den data-attributen in den doofen Browsern macht. Gilt noch zu recherchieren!

  jQuery('.listeelement').live( "click", function() {
    var mydataset =  this.dataset;
    var myaction = mydataset.action;
    delete mydataset.action //damit die action nicht nochmal ans GET/POST als Param dran gehangen wird
    doSendRequest(myaction, mydataset);
  });

3. Man schicke den ganzen Kram an die Action. Aber ACHTUNG, nicht funktionierend mit der Variante 1, da müßt ich dann nochmal bißchen Hirnschmalz für opfern, um das praktikable zu gestalten:

  function doSendRequest(pAction, pParams) {
      jQuery.ajax({
        type: "GET",
        url: pAction,
        data: pParams,
        success: doSomething
      });
  }

Na? Was meint Ihr? Ich finds insgesamt ner sehr gelungend Lösung und bin nahezu begeistert, mal abgesehn von der statischen Variante für die doofen Browser, aber sicherlich ließe sich auch hier noch was geeignetes finden.

Mein herzlicher Dank geht an den Input von der großartigen Community von Stackoverflow. Klickt ihr hier und hier um die entsprechenden Diskussionen anzuschauen.

Feel free to Flattr this post at flattr.com, if you like it.

JS: onclick oder nicht, das ist hier die Frage

snirgel — Tue, 13 Jul 2010 08:16:07 +0000

Ich versuche mittlerweile Javascript immer möglichst generisch zu schreiben um Redundanzen zu vermeiden und zusätzlich möchte ich am liebsten auch kein Inline-Javascript verwenden. Diese hat neben den best-practice-unobstrusive-… auch Performance-Gründe, denn bei jedem sich öffnenden Script-Tag im Code wartet die Seite beim Laden bis dieser ausgeführt ist und wird dann erst weiter gerendert.

Jetzt stehe ich gerade vor dem Problem, dass ich eine Liste von Elementen habe, die bei einem Klick alle das gleiche machen sollen, nämlich einen Request, der HTML zurückliefert, womit ein anderer Bereich der Seite aktualisiert wird:

  
    contentzeug
    contentzeug
    contentzeug
    contentzeug

Im ersten Moment würde ich jetzt den Klick wie folgt an das .listelement hängen und den Request starten (so auch meine bisherige Vorgehensweise):

function sendRequest() {
  jQuery('.listeelement').live( "click", function() {
    1. Fummel die Id des nachzuladenden Contents aus der css-id raus
    2. Sende den Request an die Action
  });
}

Irgendwie nervt mich hierbei aber ganz gewaltig Punkt 1 bei der Verarbeitung des Klicks. Denn man muss etwaige Parameter erstens immer irgendwie im Markup ‘verstecken’ und zweitens es dann wieder rausfummeln um es an die Action zu schicken. Schön ist anders und unter dem Performance-Aspekt kann das ja auch nicht der Stein des Weisen sein.

Am einfachsten und mir am liebsten wäre meiner Ansicht nach einfach folgendes:

  
    contentzeug
    contentzeug
    contentzeug
    contentzeug

Woraus sich folgendes Script ergibt:

function sendRequest(pParams) {
      jQuery.ajax({
        type: "GET",
        url: action,
        dataType: "json",
        data: pParams,
        success: doSomething
      });
}

Die Verarbeitung ist, meiner Ansicht nach, damit definitv viel einfacher und auch schneller, würd ich mal meinen.
Ich bin aber etwas unsicher, ob das jetzt ne gute oder schlechte Idee ist diesen Weg zu gehn, da zumal auch nicht genau weiß, ob das onclick überhaupt noch verwendet werden soll.

Na vielleicht hat da ja irgendjemand ne Meinung dazu. Würde mich freuen und auch wirklich weiterhelfen.

Feel free to Flattr this post at flattr.com, if you like it.

Themenbruchkante

snirgel — Fri, 25 Jun 2010 14:06:04 +0000

Insgesamt und überhaupt und sowieso hat das wenig Sinn, den Themenschwerpunkt in diesem Blog weiterhin auf das OpenWeb und die damit verbunden Standards, wie vor allem OpenID zu beschränken. Desterwegen habe ich mich dazu entschlossen, euch in Zukunft verstärkt mit anwendungsentwicklertechnischen Problematiken zu konfrontieren. Javascript (!), PHP, Symfony und Co., sind die Dinge, mit denen ich mich tagtäglich am meisten beschäftige, warum also nicht auch die Thematik dieses Blogs ein wenig mehr darauf konzentrieren?

Nicht, dass mich das Openweb nicht mehr interessiert und es darüber nichts mehr zu sagen gäbe, aber erstens reg ich mich meistens sowieso nur auf, zweitens kostet es mich wahnsinnig viel Zeit einen Post über die diesbezüglichen Themen zu verfassen und drittens schließt das eine das andere ja nicht aus. Trotzdem wird es ab sofort etwas Entwickler- und vor allem Javascript-lastiger. Schätzungsweise werden damit auch die Posts kürzer und die Frequenz höher, da ich häufiger schreiben kann, was mir gerade durch den Kopf geht, ohne stundenlang ausholen zu müssen.

Euren Mut und Unmut darüber dürft ihr dann gerne über den in den letzten Wochen entstandenen Button äussern. Kaum zu glauben, dass so ein kleines Ding soviel Tränen, Schweisss und Blut kosten kann. Würde mich also freuen, wenn ihr mal klicken könntet .

Feedback welcome (zur Themenbruchkante UND vor allem zum Button natürlich, der sich allerdings noch in der Testphase befindet).

Feel free to Flattr this post at flattr.com, if you like it.

Wer bin ich und wenn ja mit wem? – Authentifizierung mit FbConnect oder OpenID

snirgel — Sun, 28 Mar 2010 15:30:52 +0000

Wie angekündigt werde ich nun heute endlich den “Kampf” eröffnen und dabei die offenen Technologien und im Gegenzug Facebook-Connect mal etwas genauer anschauen (Achtung, im Vergleich zu sonst wird es etwas technischer) :

“Authentifizierung und Austausch von Profildaten. Wer ist der User, der meinen Service nutzen möchte?”

Dank yiid durfte ich mich in letzter Zeit etwas näher mit Facebook und dessen APIs auseinandersetzen (man kann sich jetzt seine Facebook-Aktivitäten in yiid anzeigen lassen). Dies war, nach anfänglich sehr hoher Motivation meinerseits, nicht unbedingt der Spass, den ich erwartet hatte, sondern ist zur etwas größeren Herausforderung mutiert. Wie auch immer hoffe ich, dass ich jetzt nicht zu (negativ) vorbelastet bin und meine Voreingenommenheit sich in Grenzen hält. Sollte ich zu kritisch werden, dann bitte ich dies zu entschuldigen und auf jeden Fall in den Kommentaren anzumerken.

OpenID integrieren

Unter wiki.openid.net/Libraries sind neben den Bibliotheken für alle gängigen Programmiersprachen (Java, C#, Python, Ruby….) auch insgesamt 7 PHP-Bibliotheken gelistet. Für welche man sich dabei entscheiden mag, ist sicherlich letztendlich Geschmacksache. So gibt es bspw. sowohl Plugins für diverse Frameworks wie Symfony oder auch Drupal, als aber auch unabhängige Klassen, die ich persönlich bevorzugen würde, da Plugins, wie für Symfony, meistens doch nicht genau das machen was man will oder nicht zur Projektkonfiguration passen. Meine Empfehlung deswegen sind die PHPOpenID-Klassen von JanRain, mit denen man meiner Ansicht nach nicht viel falsch machen kann (denn ja quasi von den OpenID-Machern gemacht ). PHPOpenId bringen eigentlich alles mit, was man für einen lauffähigen Client braucht und für ambitionierte bietet die Bibliothek auch die Möglichkeit, selbst einen Provider zu implementieren. Die Extensions für sReg und Attribute Exchange sind in den Klassen ebenfalls mit enthalten.

Leider habe ich selbst noch nie einen OpenID-Consumer in ein bestehendes Projekt eingebaut. Um mir aber doch eine Meinung bilden zu können habe ich mir heute mal die Mühe gemacht, zumindest mal etwas näher draufzuschauen und bin dem -meiner Ansicht nach großartigen- Tutorial auf Dr. Web gefolgt, um mal eine grobe Consumer-Implementierung bei mir Lokal zu “simulieren”. Dank des Tutorials war dies denkbar einfach und ich habe keine halbe Stunde gebraucht, um einen Login mit meiner OpenID hinzubekommen und die sReg-Daten gabs obendrein noch gratis dazu. (Aufgrund des erwähnten Tutorials spare ich mir an dieser Stelle weitere Details zur Implentierung, denn ich würde sowieso nur das wiedergeben, was dort steht.). Die komplette OpenId-Integration läuft auf der Server-Seite ab, was die Sache auch nochmal vereinfacht und ich musste mich eigentlich lediglich mit dem anständigen Includieren der Klassen und der Kommunikation zwischen meinem Client und dem Provider kümmern und sonst nichts (Warum das erwähnenswert ist sehen wir nachher bei der Facebook Connect – Integration).

Natürlich kann man dies als eine kleine Milchmädchenrechnung auslegen, denn ich habe ja kein komplexes Framework, in das das Ganze integriert werden muss. Doch auf Grund der Einfachheit und der Aussagen anderer Entwickler schätze ich den Aufwand auf keinesfalls höher als einen Tag, womit sich der Arbeitsaufwand in Grenzen hält will ich meinen.

Ist man absoluter Neuling auf dem Gebiet OpenID, dann fällt die Auseinandersetzung mit der Thematik sicherlich im ersten Moment ein wenig schwerer. Aber mittlerweile ist OpenID aus den Kinderschuhen entwachsen und es existieren zahlreiche Erklärungen, Tutorials und Dokumentationen zu OpenID. Hier eine kleine Liste:

Oben erwähntes Tutorial in Deutsch: http://www.drweb.de/magazin/openid-demystified-teil-1/
Einführung bei Heise (deutsch): http://www.heise.de/developer/artikel/Identity-Management-Authentifizierungsdienste-mit-OpenID-227202.html
Alles über OpenID (deutsch): http://openidgermany.de
Und natürlich nicht zu vergessen die Basics hier und hier (deutsch)
Best Practice für Consumer (englisch): http://wiki.openid.net/Details-of-UX-Best-Practices-for-RPs

OpenID als Consumer für den SingleSignOn zu implementieren scheint mir verhältnismäßig einfach und schnell zu gehen. Mit einem Gewissen Basiswissen und den ausreichenden Dokumentationen fühle ich mich gut gewappnet und konnte schnell und erfolgreich einen Login/Registrierung bauen. Die Integration in ein komplexes Framework kann ich zwar nicht hundertprozentig beurteilen, scheint aber auch vom Aufwand überschaubar. Wenn die Bibliotheken in anderen Programmiersprachen ähnlich komfortabel sind, wie die für PHP, dann fallen mir wenig bis keine Argumente gegen eine Implentierung ein.

Facebook Connect ingetrieren

Während ich mich bei der OpenID-Imlementierung lediglich um die serverseitige Implementierung und damit auf PHP konzentrieren konnte, scheinen die Bedürfnisse für Facebook doch ein wenige vielfältiger zu sein. Für den Registrierungs- und Login-Prozess empfiehlt Facebook in seinen Getting-Startet-Dokus die Implementierung mit Javascript, der FacebookMarkupLanguage UND einer serverseitigen Programmiersprache wie PHP. Die serverseitigen Clien-Libraries sind dabei, wie bei OpenID in jeder gängigen Programmiersprache vorhanden, wobei es allerdings von Seiten Facebooks nur für einige wenige einen Support gibt (z.B. für PHP5). Um überhaupt mit der Facebook-Implementierung beginnen zu können, muss man neben den Library-Include noch eine App innerhalb von Facebook selbst anlegen und korrekt konfigurieren, dort erhält man dann auch die unbedingt notwendige application id und das application secret. Beim erstellen der App wird man aufgefordert, die sogenannte xd_receiver.htm herunterzuladen und gebeten, diese im Verzeichnisroot der eigenen Applikation abzulegen. Hat man dies alles gemacht, dann kann man mit der eigentlichen Implementierung beginnen.

Leider muss ich an dieser Stelle sagen, dass es den Rahmen dieses ohnehin schon wieder sehr langen Artikels definitiv sprengen würde, eine komplette Facebook-Connect-Implementierung zu beschreiben. Deswegen muss ich vorerst auf die (englischen) Tutorials, die von Facebook selbst bereitgestellt werden verweisen:

FacebookConnect Tutorial: http://wiki.developers.facebook.com/index.php/Facebook_Connect_Tutorial1
Tutorial von Goldsteintech.com: http://www.goldsteintech.com/facebook_connect/landing_page.php

Auf deutsch habe ich dazu noch nichts wirklich Gutes gefunden (wenn ihr eins kennt, bitte in den Kommentaren posten), plane aber in den nächsten Wochen selbst Eines zu schreiben und hier zu veröffentlichen, also noch ein wenig Geduld . Grob erklärt läuft das Ganze aber über die Facebook-Session-Cookies ab, und es wird überprüft, ob der User gerade bei Facebook eingeloggt ist. Wenn ja, dann muss man nachschauen, ob man innerhalb des Systems eine passende Fb-UserId hat, wenn ja, dann kann man den User einloggen, wenn nein, dann muss der User den FB-Button klicken (ebenso, wenn er gerade nicht bei Fb eingeloggt ist). Nach dem Klicken auf den Button, dem Login bei Facebook und ggf. der Autorisierung der App kommt der User dann zurück auf den eigenen Service und man überpüft erneut die userid. Gibt es den User tatsächlich noch nicht, dann bietet man eine Registrierung an und speichert daraufhin die Daten und die UserId, gibt es ihn, dann kann man ihn einloggen.

Diese Kommunikation wird insgesamt, wie gesagt mit Javascript, FBML und PHP abgefrühstückt. Sicherlich ist auch eine Implenetierung nur mit PHP und HTML möglich, habe ich aber nur kurz ausprobiert und hat nicht besonders gut geklappt (was auch an mir liegen kann).

Hat man nun alles geschafft und erfolgreich eingebaut und alles funktioniert, dann bekommt man (dank der freizügigen FB privacy policies) auch hier eine Fülle von Informationen über den gerade angemeldeten User. Einen kompletten Überblick darüber findet ihr hier. Vorraussetzung hierfür ist allerdings unbedingt, dass der User eure App hinzugefügt und autorisiert hat.

Die Facebook-Connect-Integration ist mir persönlich sehr schwer gefallen, da mich der Mischmasch aus JS/FBML und PHP extrem irritiert hat. Die Dokumentation der gesamten Facebook-APIs ist zwar unglaublich umfangreich, aber in diesem Fall ist weniger vielleicht manchmal mehr. Beim lesen kommt man von Hölzchen auf Stöckchen und findet eigentlich nie raus, was man jetzt wirklich braucht oder gar falsch macht, wenn etwas nicht klappt. Klar klingt das jetzt sehr schwarz-weiß-malerisch, aber ich habe doch hin und wieder mal irgendwelche APIs angebunden und mir eigentlich selten so schwer getan. Ich schiebe dies auf den Overkill an Informationen, den man bekommt, denn auch die Schritt für Schritt-Anweisungen innerhalb der Doku verweisen einen immer wieder auf weiterführende Informationen und am Ende weiß man gar nicht mehr, wo man vorne angefangen hat.

Genervt hat auch die Registrierung der App innerhalb von Facebook, denn es gibt dann doch ne ganze Menge, die man konfigurieren muss oder jedenfalls kann. Und auch hier hilft einem die Dokumentation nicht so wirklich weiter, denn um komplett zu verstehen, was man wofür braucht oder auch nicht ist man eine ganze ganze Weile erstmal beschäftig. Gefühlt war es so, als hätte ich vorher erstmal ne ein paar Tage recherchieren und Facebook Connect KOMPLETT verstehen müssen, um endlich vernünftig anfangen zu können (und wie gesagt, war jetzt auch nicht meine erste API).

Und leider muss ich noch ein weiteres Minus für Facebook vergeben, denn so schnell ich eben ganz fix den OpenID-Client bei mir lokal implementieren und auch testen konnte, so wenig ging dies mit Facebook Connect, denn die Entwicklung des FB-Logins innerhalb einer lokalen Testumgebung hat nach stundenlangem Rumgefummel immer wieder bloss eine Endlosschleife hervorgebracht. Kann sein, dass es Möglichkeiten gibt, FB lokal zu testen. Wenn ja, dann weiß ich allerdings nicht wie und scheint auch ein wenig mehr Aufwand zu sein. Hinzukommt, dass Facebook den Firebug blockiert, was bedeutet, dass bei angeschaltetem Firebug kein Facebook-Javascript ausgeführt wird, was das Entwickeln und Debuggen nicht unbedingt besser macht.

Fazit:

OpenID – Klar abgegrenzt, übersichtlich und überschaubar im Aufwand mit wenigen Implementierungshürden und guten Dokus. Zudem gut zu entwickeln, weil lokal test- und ausführbar.
FacebookConnect – Relativ viele Hürden vorab und Information-Overkill während der Implentierung und bei der Doku. Zudem nicht besonders entwicklerfreundlich durch komplizierte oder nicht mögliche lokale Integration und Testbarkeit. Allerdings: Hat mans mal Verstanden und die Einstiegshürden überwunden, dann ist es ok damit zu arbeiten und warscheinlich sogar relativ einfach -> Übrigends auch ein Satz der mir relativ oft beim Einlesen begegnet ist (‘Wenn mans erst verstanden hat…..’)

Jaja, ich weiß, die die mich kennen und die Kritiker unter Euch werden jetzt sagen: “War ja klar, dass sie Facebook per se negativer Beurteilen wird”. Stimmt, ich mag Facebook und seine, von mir als arrogant empfundene, Politik nicht besonders. Aber als ich angefangen habe mich damit zu beschäftigen, war ich hoch motiviert und auch einigermaßen vorurteilsfrei (ausser,dass es eben proprietär ist). Nach einigen Tagen war ich allerdings so frustriert wie noch nie in meinem Entwicklerdasein, was mich eben zu diesem ein wenig schwarz-weiß-malerischen Urteil gebracht hat.

Auserdem muss ich noch dazu sagen, dass es beim nächsten mal um die Autorisierung von Daten geht, also Facebook vs. oAuth und ich habe den Verdacht, dass Facebook dabei etwas besser abschneiden könnte .

Feel free to Flattr this post at flattr.com, if you like it.

Willkommen in der wirklichen Welt!

snirgel — Tue, 27 Oct 2009 12:07:59 +0000

Nein, es gab nicht nur schlechte Nachrichten was OpenID betrifft in meiner Blog-Abstinenz. Auch wenn sich die Implementierungen in Grenzen halten ist der Begriff OpenID doch wenigstens etwas populärer geworden.

Sogar Facebook, das eigentlich eher für die Entwicklung proprietärer Lösungen bekannt ist, ist mit viel Tamtam und Getöse der OpenId Foundation beigetreten und hat seine Zusammenarbeit und Unterstützung zugesichert. Zudem ging ein Raunen durch die Netzwelt, als es auf einmal hieß: Facebook implementiert die openID – Relaying Party (Artikel leider auf Englisch, sorry). Denn wenn die Netzriesen wie Facebook, Google und Co. nicht nur ihre Unterstützung zusagen, sondern auch Taten folgen lassen, ist das für jede Technologie ein großer Schritt und kann eine Menge in Gang setzen, da dann plötzlich nicht mehr nur die sowieso schon Interessierten auf etwas aufmerksam werden, sonder auch der Rest der Welt.

Die Freude darüber wurde allerdings schnell wieder gebremst, denn auch hier hat Facebook es wieder geschafft, eine proprietäre Lösung bei der Implementierung der Relaying-Party auf die Beine zu stellen, die eigentlich jeden Gedanken über diese Technologie irgendwie ad absurdum stellt (so zumindest meine persönliche und bescheidene Meinung). Facebook merkt sich nämlich den Provider über ein Browser-Cookie und immer wenn ich mit einem anderen Browser daher komme muss ich mich auf herkömmlichem Weg anmelden, meine openID hinzufügen, um das Cookie zu erhalten und dann funktioniert das Ganze wieder. Richtig, das war irgendwie nicht das was ich wollte, oder?

Da ich nach den Testberichten von den Herren Pfefferle und Pötter den Facebook-Login mit openID gar nicht erst ausprobiert habe, wollte ich dem Ganzen eben eine zweite Chance geben und einfach mal ausprobieren, ob sich etwas entwickelt und vllt. verbessert hat, ist ja jetzt auch alles schon ne Weile her. Leider bin ich schon direkt an der Usability gescheitert und finde einfach nicht die Stelle, wo ich die openID meinem Account hinzufügen kann. Vielleicht weiss ja einer von Euch da draussen, wie derweil der Stand der Dinge ist und möchte seine Erfahrungen in den Kommentaren mit mir Teilen (oder mir auch zumindest verraten, wie und vor allem wo in Facebook ich es selbst testen kann).

Feel free to Flattr this post at flattr.com, if you like it.

Wat macht eigentlich nochmal….openID?

snirgel — Sun, 18 Oct 2009 13:06:47 +0000

Klar, ich habe lange nichts geschrieben und man könnte den Eindruck bekommen, dass ich damit vllt. auch ein wenig die Kompetenz verloren habe, mir ein Urteil über die Details zum Thema openID zu bilden. Doch eigentlich halte ich es gerade für gut, mit ein wenig Abstand noch einmal auf die Dinge zu blicken, da dadurch die Sicht der Dinge meistens wieder etwas an Objektivität gewinnt. Und diese Sicht der Dinge will ich Euch natürlich nicht vorenthalten.

Was ist also aus der guten alten openID im letzten halben Jahr geworden?
Mein erste stille Antwort dazu war für einen kurzen Moment: “Nichts ist draus geworden”. Doch dies stimmt natürlich nicht ganz. OpenID hat in der letzten Zeit einiges an Bekanntheitsgrad hinzugewonnen und man wird nicht mehr ununterbrochen wie ein Bewohner eines fremden Planeten angeschaut, wenn man davon spricht oder schreibt. Dank Aktionen wie dem Beitritt des US-Governments und Webriesen wie Facebook (dazu folgt noch ein etwas ausführlicherer Artikel) in der openID-Foundation hat der Bekanntheitsgrad, der -meiner Meinung nach- immernoch großartigen Technologie in einige Köpfe mehr geschafft. Und langsam aber sicher scheint sich das Single-Sign-On-System -zumindest in der Theorie- durchzusetzen.

Soweit die Theorie, aber was ist mit der Praxis?
Und auf diese Frage passt auch meine Antwort wieder: “Nichts ist draus geworden”. Denn mal Hand aufs Herz, wie oft im Otto-Normal Webleben begegnet uns das Single-Sign-On-System tatsächlich? Richtig, so gut wie nie. Auf meiner täglichen Webreise, die aus dem Absurfen von einigen Email-Konten und Sozialen Netzwerken besteht kommt es so gut wie nie vor, dass ich die Möglichkeit bekomme, mich ohne Passwort und mit einem Klick irgendwo einzuloggen und grad schon gar nicht mit einer frei wählbaren openID, sondern allenfalls mal mit fest vorgegebenen Möglichkeiten via Facebook oder Twitter. Und es ist nicht wirklich so, als wäre ich ständig auf irgendwelchen Nischen-Platformen unterwegs, sondern auch ich bin vom Grundprinzip her nur ein 0815-Webuser.
Sicherlich melde ich mich – berufsbedingt- warscheinlich im Schnitt bei mehr neuen Services an, als so manch Anderer, was aber nicht unbedingt zu einem positiveren Meinungsbild führt. Ich kann mich nicht an eine einzige Platform in den letzten Monaten erinnern, wo ich mich neu angemeldet habe und ich nicht gezwungen war, Benutzerdaten auszufüllen und ein Passwort zu vergeben.

Und die Dichter und Denker?
Vor allem und gerade bei deutschen Services scheint bisher die Thematik und damit verbundene Technologie mal sowas von nicht angekommen zu sein. Die Ignoranz der deutschen Unternehmen gegenüber webtechnischen Neuerungen scheint mir ungebrochen und da können Xing und Co. dreimal opensocial einbinden, einen Vorreiter-Status in Sachen offenes Web erreichen sie dadurch noch lange nicht. Neue Technologien werden einfach nicht voran getrieben oder gar mitentwickelt. Schön brav abwarten was aus dem Valley kommt und dann vllt. mal nachmachen lautet immernoch die Devise. So gut wie jedem deutschen Internetunternehmen scheint jegliche Weitsicht und Vision komplett abzugehen. Es wird nicht riskiert und nicht investiert und das Land der Dichter und Denker verharrt -webtechnisch betrachtet- in einem Stillstand, der schon fast erschreckend ist.
So muss man sich beispielsweise mal reinziehen, dass ich mich TÄGLICH auf VIER Email-Konten des größten deutschen Internetanbieters mit VIER verschiedenen Passwörtern anmelde. Da bringt es mir rein gar nichts, dass mir jetzt auch das Facebookkonto eines Absenders vorgeschlagen wird.

Ok…genug..bevor ich mich weiter in Extase schreibe. Ich denke ich habe auch so deutlich machen können, was ich meine.

Sorry, dass bei meiner heutigen Bilanz relativ viel Pessimismus mitschwingt, aber ich glaub es musst mal raus, damit ich mir nicht ganz so doof vorkomme, wenn ich diesen Blog wieder zum Leben erwecke und über Dinge schreibe, die sowieso keinen Interessieren .

Vielleicht seht Ihr das ja alles komplett anders und natürlich freue ich mich über zahlreiche Meinungen, Meinungen, Meinungen…..

Feel free to Flattr this post at flattr.com, if you like it.

Wenn ich nicht hier bin…

snirgel — Sat, 25 Apr 2009 10:14:20 +0000

…bin ich aufm Sonnendeck.

Oder vielleicht auch hier:

…hier:

….oder hier:

Quelle: singapur-reiseinfo.de

Feel free to Flattr this post at flattr.com, if you like it.

o..o..o….oAuth

snirgel — Sun, 22 Mar 2009 13:45:13 +0000

Also dann wohl oAuth. Eigentlich hatte ich gehofft, das Thema ein wenig vor mir herschieben zu können, da mit ma.gnolia alle meine Links zum Thema dahin gegangen sind. Aber dem gigantischen Feedback bezüglich meines letzten Posts kann ich mich wohl nicht erwähren und sammle einfach nochmal neu (diesmal dann aber mit delicious)

Wie wir gelernt haben, konnte -dank OpenID- eine Problematik der Webwelt bezüglich der Nutzung von Webservices gelöst werden: Das ständige Nutzername, Passwort und Registrierungswirrwarr und offen gesagt auch Generve. Ständig musst man sich ein neues Passwort merken und immer wieder die gleichen Nutzerdaten eintippen. OpenID sei dank hat das Passwortgeraffel nun ein Ende und, wir erinnern uns, dank der Erweiterungen sReg und Attribute Exchange, das ständige Eingetippe der Profildaten auch.

Während diese Problemstellung gelöst scheint, ist nun aber natürlich schon die nächste in Sicht: Der sichere Austausch von Daten zwischen zwei Services, denn hierfür bietet OpenID keine Lösung, ausser eben bis auf die wenigen Nutzerdaten, die durch sReg und AX mitgesendet werden können.

Prinzipiell ist es ja so, dass man schon viele Dinge irgendwo im Internet gespeichert hat: Flickr hat meine Bilder, LastFM weiss Bescheid über meinen Musikgeschmack und bei Delicious liegen meine Bookmarks. Möchte ich diese Daten nun aber an anderes Stelle benutzen, war bisher der einzige Weg: alles nochmal neu eingeben oder hochladen.
Wenn ich nun meine Urlaubsbilder, die ja eigentlich schon schön vorsortiert bei Flickr liegen, gerne bei einem Online-Photo-Service entwickeln lassen will, dann muss ich wohl oder übel nochmal alles sortieren und hochladen, damit ich sie auch in analog 1.0 – Form in Händen halten kann.

Wo ist denn da das Problem? Soll doch Flickr einfach die Bilder an den Müllen-Photo-Service schicken und fertig. Gute Idee! Aber woher weiß Flickr es dem Photoservice vertrauen kann, der Sevice die Photos von der snirgel schicken will und vor allem: Woher weiß Flickr, dass es auch die snirgel ist, die die Photos woanders braucht und nicht irgendjemand sonst? Die Antwort auf diese Frage lautet -natürlich-: oAuth! Denn oAuth ist ein standartisiertes Protokoll, was eine sichere und relativ einfache Authentifizierung zwischen Internetschnittstellen (APIs) ermöglicht. Das bedeutet, man hat einen Weg gefunden, wie zwei Server wissen können, das Daten von einem bestimmten User ausgetauscht werden sollen.

Im Detail sieht das ganze wie folgt aus:
Die snirgel (der User) hat ihre Bilder (protected resources) nun also bei Flickr (service provider) hochgeladen und möchte diese bei einem Photoservice (Consumer), den wir zur Einfachheit mal Photoblitz nennen, entwickeln lassen. Nun hat sie sich bei Photoblitz eingeloggt und möchte loslegen. Photoblitz, als oAuth-Consumer bietet ihr nun an, Photos von diversen Plattformen, u.a. auch Flickr, mittels Auswahlbox zu importieren. Sie klickt den Bilder-importeiren-Button bei Photoblitz und wählt Flickr aus. -Damit snirgel Flickr überhaupt auswählen kann, musste der Entwickler von Photoblitz bereits bei der Implementierung bei Flickr einen sogenannten Consumer Key und ein Consumer Secret beantragen. Dies ist notwendig, damit Flickr später weiß, dass es Photoblitz vertrauen kann-. Nach der Auswahl klickt snirgel noch den Weiter-Knopf und los gehts:

Photoblitz beantragt bei Flickr nun im Hintergrund einen Request-Token, dass ist eine Art Passierschein für den Consumer (also Photoblitz) und hat erstmal nichts mit dem User selbst zu tun, während snirgel darauf wartet, das es weiter geht.
Hat Photoblitz den Passierschien von Flickr bekommen, wird snirgel auf eine oAuth-Authorisierungsseite von Flickr weitergeleitet. Hier kann sie sich nun einloggen, womit Flickr dann gleichzeitig weiß, dass es sich um einen Zugriff auf die Bilder von User snirgel handelt (Die Eingabe von Passwort und Username laufen natürlich nur bei Flickr ab und Photoblitz bekommt davon nichts mit).
Um nun wirklich sicher zu gehen, dass snirgel auch damit einverstanden ist, dass Photoblitz die Bilder bekommen soll, muss sie bei Flickr nochmal extra den Zugriff auf die Bilder erlauben. Zudem kann sie an dieser Stelle noch ein einstellen, wie oft und wie lange Photoblitz auf die Flickr-Bilder zugreifen darf.

Nachdem snirgel nun alles bestätigt hat, merkt sich Flickr, dass und wielange/wieoft Photoblitz auf die Bilder zugreifen darf und schickt snirgel zurück zu Photoblitz. Nebenbei schickt Flickr noch einen Requesttoken(einen weiteren Passierschein) zu Photoblitz mit zurück. Dadurch weiss Photoblitz dass es jetzt anfangen kann, die Bilder zu importieren. Das heißt, die ersten Schritte waren zunächt nur dazu da, alle Berechtigungen zwischen den beiden Servern unter Einbeziehung des Users zu regeln.
Erst jetzt beginnt der eigentlicht Datenaustausch: Photoblitz schickt den erhaltenen Passierschein zu Flickr und tauscht diesen gegen einen Accesstoken um. Dies ist jetzt nur noch eine Art Empfangsberechtigungsschein, der jetzt nur noch den Datenaustausch an sich regelt. Mit dieser Empfangsberechtigung kann nun Photoblitz für den von snirgel festgelegten Zeitraum auf die Bilder von Flickr zugreifen und sie importieren.

Klingt kompliziert, ist es prinzipiell auch. Allerdings nicht für den User, denn auch hier soll er natürlich so wenig wie möglich von der ganzen Angelegenheit mitbekommen. Er sich lediglich einloggen und den Zugriff bestätigen, was ja eigentlich nicht zuviel verlangt ist und der Aufwand, im Vergleich zum neuen Zusammensuchen und Hochladen, ja schon überschaubar ist.

Die Aufmerksamen unter euch könnten jetzt anmerken: Warum muss ich mich wieder erst noch bei Flickr mit Username und Passwort einloggen, wenn ich doch eine OpenID habe, die ich sowohl bei Photobox und Flickr hinterlegt habe. Berechtigter Einwand. Doch kann man sich denken, dass dies den Entwicklern beider Standards auch schon aufgefallen ist und hierfür gerade an einer Lösung gearbeitet ist. Kann sogar sein, dass es schon eine Lösung gibt. Darauf gehe ich dann in einer der nächsten Posts etwas näher ein.

Was ich zum Schluss nochmals erwähnen möchte, da es -glaub ich- oft noch mißverstanden wird und auch durch den Beginn dieses Posts mißverstanden werden kann: oAuth ist lediglich ein Protokoll zur Autorisierung und hat nichts mit den Daten zu tun, die dann letztendlich ausgetauscht werden. Was dann wie und in welcher Form zwischen den Servern hin und hergeschickt wird steht auf einem anderen Blatt. OAuth regelt lediglich sicher und zuverlässig die Zugriffsberechtigungen.

Welches Potential aber hinter einer solchen Lösung wie oAuth steckt, was man dadurch alles anstellen kann und welche Services es wofür benutzen, erzähl ich dann beim nächsten mal.

Quellen:
hueniverse – Beginner’s Guide to oAuth – Part I
hueniverse – Beginner’s Guide to oAuth – Part II
Wikipedia

PS: Da ich mir mit dem Thema noch etwas unsicher war/bin, freue ich mich sehr über Feedback und auch Richtigstellungen, sollte ich etwas falsch erklärt haben

Feel free to Flattr this post at flattr.com, if you like it.