SCREENGUIDE Logo

Neuer Name, neues Layout, den Fokus nicht mehr so streng auf Webstandards aber immer noch mit „Pfefferles OpenWeb“ 🙂

Seit dem 16.03. heißt das Webstandards-Magazin offiziell SCREENGUIDE und ist in allen Bahnhofs- oder Flughafen-Buchhandlung erhältlich.

In meiner Kolumne geht es diesmal um den Wandel im OpenWeb:

Das OpenWeb hat keine Zukunft! Die proprietären Systeme von Twitter und Facebook haben sich durchgesetzt und die goldenen Zeiten von RSS sind vorbei. So sieht es zumindest Robert Scoble. Der kampf für ein OpenWeb und DataPortability von 2008 scheint verloren und viele der Revoltierenden arbeiten heute sogar für das damalige Feindbild Facebook.

Kaufen! Danke!

t3n Nr. 27 - Future-Cash

Ich durfte mal wieder einen Artikel für die t3n schreiben und das Thema ist (auch mal wieder) Single Sign On.

Seit Jahren spricht niemand mehr von Data Portability, und auch der Hype um OpenID flacht aus vielerlei guten Gründen immer weiter ab. Es ist an der Zeit, Bilanz zu ziehen, die Themen „Online Identity“ und „Single Sign-On“ neu anzugehen und aus den Fehlern der letzten Jahre zu lernen. Ein Ausblick.

Der Artikel beschreibt im Wesentlichen die aktuellen Projekte von OpenID (OpenID Connect und Account Chooser), Google (Google Identity Toolkit) und Mozilla (BrowserID) und deren Starken und Schwächen.

Seit Freitag ist Ausgabe 27 des t3n-Magazins im Handel erhältlich… also ab in den Laden, kaufen, meinen Artikel lesen und mir Feedback geben! Danke 🙂

openid-complex

Hat der erste Entwurf von OpenID Connect noch auf eine (übersichtliche) Seite gepasst, braucht der Draft der OpenID Foundation schon 7 unterschiedliche Spezifikationen.

Wieso müssen „Standard“-Organisationen wie das W3C (z.B. RDFa) oder der OpenID Foundation denn alles so unnötig kompliziert machen? Immerhin schafft es ja sogar Facebook seinen Authentifizierungsprozess auf einer Seite zu erklären. …und noch besser! Er lässt in drei Sätzen zusammenfassen:

  1. Hol dir über folgende URL einen Access-Token:
    https://www.facebook.com/dialog/oauth?
    client_id=YOUR_APP_ID&redirect_uri=YOUR_URL
  2. Häng ihn an folgende URL, auf den du den User weiterleitest:
    https://www.facebook.com/dialog/oauth?
    client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&
    scope=email,read_stream
  3. Fertsch!

…dazu kommen eine weitere Discovery-Variante die Webfinger, host-meta, XRD, XRDS oder YADIS komplett ignoriert und eine Identity-API die SREG oder AX noch nicht einmal ähnelt!

Mike Jones, einer der Hauptentwickler der Spezifikation, schreibt zwar:

The design philosophy behind OpenID Connect is “make simple things simple and make complex things possible”.

Das ist aber nur die halbe Wahrheit. Webseitenbetreiber, die zukünftig einen OpenID Connect Login anbieten wollen, haben es in der Tat etwas einfacher, da sie sich auf die „Minimalanforderungen“ konzentrieren können. Seiten die einen OpenID Connect Provider stellen wollen haben aber folgendes Problem:

Authorization Requests can follow one of two paths; the Implicit Flow or the Authorization Code Flow. […]
The OpenID Connect Basic Client profile only documents Clients using the Implicit Flow. OpenID Providers MUST support both flows. […]

Damit begeht die OpenID Foundation wieder den gleichen Fehler wie bei OpenID 2.0. Am Schluss gibt es so viele unterschiedliche und halbfertige Implemenrierungen, dass man wieder auf SaaS-Dienste wie Janrain oder Gigaya zurückgreifen muss. Wozu braucht es dann noch einen „Standard“?

Warum denn immer 1000 Alternativen anbieten? Bei Facebook klappts ja auch ohne…

BrowserID

Ich schreibe gerade einen Artikel für das t3n Magazin über aktuelle Sign-In-Mechanismen und hab mir in dem Zuge BrowserID mal etwas genauer angeschaut. Ich bin wirklich extrem überrascht mit wie wenig Arbeit es sich in z.B. WordPress einbauen lässt.

BrowserID besteht eigentlich nur aus einem JS-File,ein paar Zeilen JS-Code:

<script src="https://browserid.org/include.js" type="text/javascript"></script> <script type="text/javascript"> navigator.id.get(function(assertion) { if (assertion) { // This code will be invoked once the user has successfully // selected an email address they control to sign in with. } else { // something went wrong! the user isn't logged in. } }); </script>
Code-Sprache: HTML, XML (xml)

und dem anschließenden Verifizieren der assertion:

$ curl -d "assertion=&audience=https://mysite.com" "https://browserid.org/verify" { "status": "okay", "email": "lloyd@example.com", "audience": "https://mysite.com", "expires": 1308859352261, "issuer": "browserid.org" }
Code-Sprache: JavaScript (javascript)

Den ausführlichen Ablauf der Authentifizierung findet ihr auf Github.

Um BrowserID in WordPress zu integrieren lädt man also zuerst den JS-Code in den Login Header:

// add the BrowserID javascript-code to the header add_action('login_head', 'bi_add_js_header'); function bi_add_js_header() { echo '<script src="https://browserid.org/include.js" type="text/javascript"></script>'; echo '<script type="text/javascript">'."\n"; echo 'function browser_id_login() { navigator.id.get(function(assertion) { if (assertion) { window.location="' . get_site_url(null, '/') .'?browser_id_assertion=" + assertion; } else { // do nothing! } }) };'."\n"; echo '</script>'; }
Code-Sprache: PHP (php)

und platziert den BrowserID-Button auf der Login-Seite:

// add the login button add_action('login_form', 'bi_add_button'); function bi_add_button() { echo '<p><a href="#" onclick="return browser_id_login();"><img src="https://browserid.org/i/sign_in_blue.png" style="border: 0;" /></a></p>'; }
Code-Sprache: HTML, XML (xml)

Nach dem klick auf den Button öffnet sich das Autorisierungs-Fenster von BrowserID und nach dem erfolgreichen Sign-In wird die gerade implementierte Methode navigator.id.get(function(assertion) {} aufgerufen.

BrowserID login window

Im nächsten Schritt muß man die erhaltene assertion über BrowserID.org verifizieren. Da ich den notwendigen POST nicht über JavaScript absetzen will, leite ich einfach auf eine Seite weiter und übergebe die erhaltene assertion als GET-Paramater.

if (assertion) { window.location="' . get_site_url(null, '/') .'?browser_id_assertion=" + assertion; }
Code-Sprache: JavaScript (javascript)

Jetzt kann der POST bequem über WordPress abgesetzt werden.

// the verification code add_action('parse_request', 'bi_verify_id'); function bi_verify_id() { global $wp_query, $wp, $user; if( array_key_exists('browser_id_assertion', $wp->query_vars) ) { // some settings for the post request $args = array( 'method' => 'POST', 'timeout' => 30, 'redirection' => 0, 'httpversion' => '1.0', 'blocking' => true, 'headers' => array(), 'body' => array( 'assertion' => $wp->query_vars['browser_id_assertion'], // the assertion number we get from the js 'audience' => "http://".$_SERVER['HTTP_HOST'] // the server host ), 'cookies' => array(), 'sslverify' => 0 ); // check the response $response = wp_remote_post("https://browserid.org/verify", $args); if (!is_wp_error($response)) { $bi_response = json_decode($response['body'], true); // if everything is ok, check if there is a user with this email address if ($bi_response['status'] == 'okay') { $userdata = get_user_by('email', $bi_response['email']); if ($userdata) { $user = new WP_User($userdata->ID); wp_set_current_user($userdata->ID, $userdata->user_login); wp_set_auth_cookie($userdata->ID, $rememberme); do_action('wp_login', $userdata->user_login); wp_redirect(home_url()); exit; } else { // show error when there is no matching user echo "no user with email address '" . $bi_response['email'] . "'"; exit; } } } // show error if something didn't work well echo "error logging in"; exit; } }
Code-Sprache: PHP (php)

Gibt es einen User mit der entsprechenden E-Mail – Adresse wird er eingeloggt, falls nicht, wird ein Fehler ausgegeben.

Bei der Demo hab ich mir aus Zeitgründen ein wenig Code bei Marcel Bokhorst geliehen, dessen BrowserID-Plugin wesentlich ausgereifter und vollständiger ist als der kleine Demo-Code den ich hier zusammengestückelt habe.

Wenn euch das zu schnell ging und ich auf einige Details nicht genügend eingegangen bin, könnt ihr gerne fragen 🙂

Ich habe den kompletten Code übrigens auch auf Github hochgeladen… das ist einfacher als sich alles zusammen zu kopieren.

Ich habe mich letzte Woche ein wenig mit Carsten über das „scheitern“ des OpenWebs unterhalten… wen es interessiert und wer mit diskutieren will, sollte am besten bei Marcel vorbei schauen, der hat den Dialog schön zusammengefasst und um ein paar eigene Gedanken erweitert.

Marcels Fazit:

Neben dem Chaos, das das Einbinden offener Standards, oder Möchte-gern-Standards für Entwickler unattraktiv macht, gibt es noch ein weiteres Problem, dem sich das Open Web, das dezentrale Web, gegenüber sieht: Die Protagonisten, also die Fürsprecher und die, welche die Grundlagen entwerfen und weiter entwickeln, haben es bis dato versäumt, einen effektiven Hebel zu erschaffen, um Anreize für alle Seiten zu generieren, die dann zu den virtuosen selbstverstärkenden Effekten führen.

Die im Gespräch angemerkte Kurzlebigkeit der Standards ist das Gegenteil eines effektiven Hebels: Sie treibt die notwendige Entwicklerseite frustriert weg.

Ich bin im übrigen mittlerweile fast der Meinung, dass jede signifikante Weiterentwicklung von Webstandards von Unternehmen wie Google und Facebook kommen wird und muss. Denn in deren Produkten steckt der Hebel schon drin. Das bringt uns allerdings wieder zurück zu den Argumenten von Bradbury zur Abhängigkeit bei Web-APIs.

Obwohl ich das immer noch nicht so richtig wahr haben will hat Marcel mit seiner Aussage wohl den Nagel auf den Kopf getroffen. Ein aktuelles Beispiel: Schema.org! Ich beschäftige mich seit mehr als 5 Jahren mit Microformats und RDFa… für mich ist Schema.org einfach nur ignorant!
Für die meisten Webentwickler ist Schema.org aber der erste Berührungspunkt mit Websemantiken, wieso sich also weiter mit Altlasten herumplagen. Google, Microsoft und Yahoo! einigen sich auf Schema.org… ein simples Format und ein valider Usecase. Damit wird Schema.org zum neuen defacto Standard ohne je den Anspruch darauf erhoben zu haben:

schema.org is not a formal standards body. schema.org is simply a site where we document the schemas that three major search engines will support.

Der Punkt ist: Was bringens uns „Standards“ von W3C und IETF wenn sie niemand unterstützt. Wir brauchen Formate die ein Bedürfnis decken und von der breiten Masse akzeptiert werden… ob man sie jetzt „Standard“ nennt oder nicht!

(Um dieses Thema geht es übrigens auch in meiner Kolumne im nächsten Webstandards Magazin.)

Was das OpenWeb so kompliziert macht ist das Wörtchen „alternativ„!

  • OpenID Discovery basiert auf Meta-Tags, alternativ funktioniert aber auch XRDS(-Simple)/Yadis oder Webfinger.
  • OpenID stellt über SREG Profilinformationen bereit, alternativ aber auch über Attribute Exchange.
  • RDFa 1.1 ist folgendermaßen aufgebaut: <html prefix="foaf: http://xmlns.com/foaf/0.1/" > ... <span property="foaf:name">John Doe</span> ... </html> alternativ aber auch: <div vocab="http://xmlns.com/foaf/0.1/" about="#me"> <span property="name">John Doe</span> </div> …oder: <div profile="http://xmlns.com/foaf/0.1/" about="#me"> <span property="foaf:name">John Doe</span> </div>
  • OpenSocial, oEmbed, ActivityStrea.ms und host-meta benutzen JSON, alternativ aber auch XML
  • OAuth verschlüsselt mit HMAC-SHA1, alternativ aber auch mit RSA-SHA1 oder PLAINTEXT

To be continued…

Wie viel Komplexität man sich sparen könnte wenn man sich auf eine Variante beschränken würde.

Webstandards Magazin Nr. 11

Seit 16.09. ist das neue Webstandards-Magazin im Handel erhältlich und gerade jetzt vergess‘ ich darüber zu posten… immerhin enthält es Folge 10 von Pfefferles OpenWeb 🙂

…und zur Feier des Tages gibt es ein wenig Schema.org-Bashing:

Knapp 2 Milliarden Webseiten sind mit einer hCard ausgezeichnet und RDFa verzeichnete zwischenzeitlich ein Wachstum von 510% , trotzdem haben sich Google, Yahoo! und Microsoft dazu entschlossen ein neues Format zu entwickeln.

Viel Spaß beim lesen und ich freue mich wie immer über ein bisschen Feedback.

…und das Open Web kennt mindestens genau so viele Wörter für „Name“!

Ich hab mir letzte Woche mal den aktuellen Draft von OpenID Connect angeschaut und mich riesig gefreut, dass die OpenID-Community ihrer Linie treu bleibt und dem User-Schema wieder komplett neue Bezeichnungen gibt. Aber das scheint ein genereller Spaß in OpenWeb-Kreisen zu sein. Ich hab mir mal einen Spaß d’raus gemacht einzelne Bezeichnungen verschiedener „Standards“ die mit Profil/User-Infos zu tun haben, zu vergleichen.

Claims für den kompletten „Namen“ eines Users:

  • fn (vCard, hCard)
  • name (foaf, OpenID Connect, Facebook Connect, schema.org)
  • fullname (OpenID SREG)
  • namePerson (OpenID AX)
  • displayName (Portable Contacts, Open Social, Activity Streams)

Claims für den „Nachnamen“ eines Users:

  • given name (vCard)
  • given-name (hCard)
  • lastName (foaf)
  • family_name (OpenID Connect, Facebook Connect)
  • namePerson/last (OpenID AX)
  • givenName (Portable Contact, Open Social)

Gut dass wir das W3C, die WHATWG, die IETF und diverse ander Standard-Organisationen haben die in jahrelanger Arbeit, Standards wie RDF, XML, JSON, RDFa und Microdata spezifizieren und dann jeder, wie er gerade bock hat, ein Schema dafür baut 😀

Schema.org und das Open Graph Protocol sind perfekte Beispiele dafür, wie man gekonnt bestehene Schemas ignoriert und einfach macht, wie man denkt!

P.S. Ich weiß dass man die Bezeichnung „Eskimo“ eigentlich nicht mehr benutzt und wehe mir nimmt jemand den Mythos mit den 90 Wörtern für Schnee 😉

HTML5 Logo

Dass HTML5 ein paar neue input-types definiert, habe ich durch die hcard-input-brainstorming so am Rande auf geschnappt, mir aber nichts weiter dabei gedacht… Durch Zufall bin ich heute aber über folgenden Tweet von Sylvia Egger gestoßen:

Just implemented native #HTML5 form validation on #wp comments form – it' quite simple & should be in #wp default theme

und habe bissle recherchiert… Mit den neuen Input-Types ist es doch tatsächlich möglich Input-Felder über den Browser validieren zu lassen… Ich bin begeistert! 🙂

Trägt man beispielsweise eine Nicht-Email-Adresse in folgendes Feld…

<input type="email" />
Code-Sprache: HTML, XML (xml)

bekommt man…

Email Validation im Firefox

Schön wenn man sich noch über solche Kleinigkeiten freuen kann oder 😉

Lange rede kurzer Sinn: Da WordPress alle Formulare an zentraler Stelle definiert, ist es ziemlich einfach sie mit ein paar neuen Input-Types zu versehen. Mit dem folgenden Code wird das Kommentar-Formular mit den Typen "email" und "url" und das Suchformular mit dem Typ "search" (funktioniert nur in den WebKit-Browsern) erweitert:

Code-Update: Eric Eggert hat mich in den Kommentaren darauf hingewiesen, dass man mit <input required /> auch noch die Pflichtfelder validieren kann. Danke!

Code-Update 2: Dank maxe werden jetzt auch die WordPress Settings berücksichtigt (Comment author must fill out name and e-mail) und das "Comment"-Feld ist natürlich auch required

<?php /* Plugin Name: html5 input-types Plugin URI: https://notiz.blog/ Description: Adds the new HTML5 input-types to WordPress' default forms Version: 0.1 Author: pfefferle Author URI: https://notiz.blog/ */ add_filter("comment_form_default_fields", "change_comment_input_types"); function change_comment_input_types($fields) { if (get_option("require_name_email", false)) { $fields['author'] = preg_replace('/<input/', '<input required', $fields['author']); $fields['email'] = preg_replace('/"text"/', '"email" required', $fields['email']); } else { $fields['email'] = preg_replace('/"text"/', '"email"', $fields['email']); } $fields['url'] = preg_replace('/"text"/', '"url"', $fields['url']); return $fields; } add_filter("get_search_form", "change_search_form_input_types"); function change_search_form_input_types($form) { return preg_replace('/"text"/', '"search"', $form); } add_filter("comment_form_field_comment", "change_comment_field_input_types"); function change_comment_field_input_types($field) { return preg_replace('/<textarea/', '<textarea required', $field); } ?>
Code-Sprache: HTML, XML (xml)

Funktioniert als Plugin und in Child-Themes (einfach in die functions.php kopieren).

Danke auch an Marc Görtz der mich über Twitter reichlich mit Links zu dem Thema versorgt hat:

Testen könnt ihr das übrigens hier auf notiz.blog.

Microdata – wie Microformats bloß besser… (Teil 1): über abbr-design-pattern, value-class-pattern und Meta-Informationen

Knapp zwei Jahre nach dem ersten Teil, komme ich endlich mal zu Nummer 2 🙂 Nach den ganzen Diskussionen um schema.org und Microformats V2 ist es mal wieder an der Zeit, am Image von Microdata zu arbeiten.

Namenskollisionen und Namespaces

class-Attribute werden in erster Linie zum Gestalten (CSS) und für JS benutzt! Laut "The State of Web Development 2010" setzen nur knapp 35% aller Befragten Microformats ein, das heißt mehr als 65% haben keine Ahnung von Mikroformaten oder setzten sie nicht ein. Das kann zu zwei Problemen führen:

  1. Microformats werden oft durch Re-Designs zerstört. Facebook ist wohl das prominenteste Beispiel, nach einem Re-Design verschwanden alle Microformats von den Profilseiten.
  2. Es werden fälschlicherweise class-Attribute interpretiert die gar nichts mit Microformats zu tun haben nur zufällig den passenden Namen tragen. Anfällige Klassen sind z.B. url (hCard), photo (hCard), summary (hReview), description (hReview) oder author (hAtom).

Um diesem Problem Herr zu werden denkt die Community Tantek Çelik über eine Art Namespace-Erweiterung nach.

Microformats

So könnten Microformtas demnächst folgendermaßen aussehen:

<div class="h-card"> <span class="p-fn">Max Mustermann</span> </div>
Code-Sprache: HTML, XML (xml)

Dabei steht:

  • "h-*" für die root-names, z.B. "h-card", "h-event", "h-entry"
  • und "p-*" für "simple" (Text) Properties, z.B. "p-fn", "p-summary"

…und es gibt noch eine reihe weiterer Prefixes. Das ist zwar schön und gut und verhindert sicherlich einen Großteil der Namenskollisionen und man kann seinen Entwicklern sicherlich auch eintrichtern, alle x- Klassen in ruhe zu lassen… aber man mach damit jegliche Semantik kaputt. Nix mehr mit Plain Old Semantic HTML (POSH):

POSH encapsulates the best practices of using semantic HTML to author web pages. Semantic HTML is the subset of HTML 4.01 (or XHTML 1.0) elements and attributes that are semantic rather than presentational. The best way to learn and understand POSH is to do it.

…und semantic class names:

Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.

Außerdem verkompliziert man das, jetzt noch so einfach zu nutzende, Format unnötig. Wann ist etwas eine id (i-*) oder eine Nummer (n-*) und was ist mit Attributen, die sowohl aus auch sein können?

Microdata

Der Microdata Teil ist relativ schnell abgehandelt… Durch die Trennung von Semantik und Design kommt es bei Mircodata per se zu keinen Kollisionen:

<div itemtype="http://microformats.org/profile/hcard" itemscope> <span itemprop="fn">Max Mustermann</span> </div>
Code-Sprache: HTML, XML (xml)

Informationen Referenzieren

Informationen stehen auf Webseiten nicht immer so nahe beieinander, so dass es oftmals schwer ist, alle Daten mit einem HTML Attribut zu umschließen.

Microformats

Je komplizierter das Format oder der Anwendungsfall, desto mehr stößt man mit Microformats an die grenzen des machbaren. HTML 4 bietet keinerlei Mechanismen, den oben angesprochenen Problem zu lösen, deshalb greift die Microformtas-Community zu einer recht Kreativen Lösung: dem include-pattern.

<div class="vcard"> <a class="include" href="#author-name"></a> </div> <span class="fn n" id="author-name">Max Mustermann</span>
Code-Sprache: HTML, XML (xml)

oder:

<div class="vcard"> <object class="include" data="#author-name"></object> </div> <span class="fn n" id="author-name">Max Mustermann</span>
Code-Sprache: HTML, XML (xml)

Nette Idee mit etlichen Unschönheiten:

  • Leere HTML-Elemente
  • Zweckentfremdung von Object- bzw. Link-Element
  • Die Nutzung von <object /> führt zu einigen Problem bei einigen Versionen von Internet Explorer, Safari und Firefox

Microdata

Microdata löst das Problem mit dem itemref-Attribut:

<div itemscope itemtype="http://microformats.org/profile/hcard" itemref="author-name"> ... </div> <span itemprop="fn n" id="author-name">Max Mustermann</span>
Code-Sprache: HTML, XML (xml)

Viel mehr gibt es dazu eigentlich nicht zu sagen 🙂

Fazit

Als Fazit, passt hier sehr gut ein Satz den ich auch als Fazit im aktuellen Webstandards-Magazin verwende:

Microformats sind und bleiben Plain Old Semantic HTML und man sollte auch in Zukunft keinesfalls darauf verzichten sie einzusetzen, selbst mit dem Risiko einer fehlerhaften Implementierungen oder Namenskollisionen, „erzieht“ die Nutzung von Microformats einen jeden Webentwickler dazu „schönen“ und „sprechenden“ HTML-Code zu schreiben.

…um HTML-Code aber wirklich maschinenlesbar zu machen, wird es Zeit auf Microdata und RDFa zu setzen. Microformats haben den Weg für bessere und native Lösungen geebnet und haben weiterhin ihre Daseinsberechtigung aber man sollte nicht mehr als dem Format machen, als es leisten kann.