Schlagwort: FediBlog

  • 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…

    3 Kommentare zu OpenID Connect Complex
  • 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.

    6 Kommentare zu BrowserID – as easy as copy & paste
  • 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.)

    1 Kommentar zu The Long-Term Failure of OpenWeb
  • 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.

    2 Kommentare zu Kleines Jubiläum #webstandardsmag
  • 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 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.

    6 Kommentare zu HTML5, Input-Types, Form-Validierung und WordPress
  • Pfefferles OpenWeb: Microformats V2

    Seit Freitag gibt es wieder eine neue Ausgabe des Webstandard-Magazins, mit dem Fokus auf Communities.

    …als hätte ich es gerochen, passt das Thema meiner Kolumne recht gut zu den aktuellen Diskussionen um Microformats, Microdata, RDFa und schema.org. Noch genauer: Es geht um die Zukunft der Microformtats.

    Dieses Jahr feierten die Microformats ihren 8. Geburtstag. In diesen 8 Jahren haben sich mehr als zwei Milliarden hCards im Yahoo! Index angesammelt und die Mikroformate dominieren mit 94% Googles rich snippets (im Verhältnis zu RDFa und Microdata). Trotz allem sind Microformats eine Übergangslösung und es wird Zeit für einen richtigen Standard!

    Wie sieht die Zukunft der Microformats aus, was ist ist geplant, machen Microformats neben Microdata und RDFa überhaupt noch Sinn usw.

    Also los… kaufen! Zack, zack!

    2 Kommentare zu Pfefferles OpenWeb: Microformats V2
  • Neben all den negativen Meldungen endlich mal wieder ein Highlight für OpenID: Seit dieser Woche ist PayPal offizieller OpenID-Provider mit allen Schikanen (OpenID 2.0, OpenID Simple Registration, OpenID attribute exchange, OpenID user interface, PAPE specification).

    Die Meldung ist nicht nur erfreulich, sondern vielleicht auch die Rettung des etwas angeschlagenen offenen Standards. Trotz des eher hinkenden Vergleichs, wurde OpenID immer mit dem Erfolg von Facebook Connect gemessen. Die OIDF hat es durchweg versäumt den Standard als reines „Werkzeug“ sehen und die Produkte basierend auf OpenID zu promoten. Wie ich schon im Webstandards-Magazin (Ausgabe 9: Pfefferles OpenWeb) schrieb:

    Facebook Connect ist nicht wegen seinem proprietären System so erfolgreich und der Misserfolg von MySpaceID hat nichts mit den benutzten offenen Standards zu tun. Promote the utility not the technologie. To reach the majority of users who aren’t familiar with OpenID as a technology, promote the ability to log in using an existing account, not „OpenID“ itself. Ich würde sagen das Problem liegt nicht am Protokoll sondern an den fehlenden sinnvollen Anwendungsfällen. OpenID funktioniert überall da, wo der User einen Nutzen hat ohne zu wissen was unter der Oberfläche passiert, beispielsweise „Sign in with Google“ oder „Sign in with Yahoo!“. Wo bleiben also die Killerapplikationen wie z.B. Paypals angekündigtes Express Checkout auf Basis von OpenID?

    Reines Single-Sign-On ist ein Geek-Thema und scheint wohl kein generelles Bedürfnis zu befriedigen. Ein „Mit einem Klick-Bezahlen“ ist dagegen eine enorme Chance für Einkäufer und kleine Verkäufer. Wo man bisher, oft durch die langwierige Anmeldung und das hinterlegen der Kontodaten, trotz günstigerer Angebote doch wieder bei Amazon bestellt hat, bietet PayPal in Zukunft vielleicht die Lösung: Schnelles, unkompliziertes und sicheres Einkaufen mit einem „Klick“.

    Hoch lebe OpenID 🙂

    3 Kommentare zu PayPal: Die letzte Chance für OpenID?
  • OpenWeb-Kolumne (wsm)

    Damit das ganze Zeug über das ich so einmal im Quartal im Webstandards-Magazin schreibe nicht pure Science Fiction bleibt, hab ich mich die letzten Wochen mal daran gemacht, ein bisschen Federated Social Web für WordPress zu basteln!

    Vor einigen Monaten kam Pepijn de Vos auf mich zu, ob ich ihm nicht bei einem „OStatus for WordPress“ (noch nicht runterladen! funktioniert noch nicht!) helfen wolle. Das damals größte Problem: Wie können wir so viele besehenden Plugins (pubsubhubbub, webfinger, …) wiederverwenden, ohne die Installation zu kompliziert zu gestalten. Da dieses Problem mittlerweile behoben ist und auch das Salmon-Plugin einigermaßen funktioniert, ist es Zeit für einen Test!

    Ich würde mich freuen, wenn ihr zwei, drei oder vier Leser da draußen mal diesen Blog bei Status.net oder Identi.ca (oder bei jedem anderen StatusNet-Klon) abonnieren und wie wild auf diesen Artikel antworten könntet. Dazu müsst ihr einfach pfefferle at notizblog dot org folgen:

    …und auf diesen Post antworten:

    Was bisher funktioniert:

    • Artikel landen in Echtzeit bei StatusNet/Identi.ca (pubsubhubbub)
    • Antworten auf diese Artikel landen als Kommentare bei WordPress (salmon)

    Zukünftige Features:

    • Kommentare auf WordPress-Seite sollen auch nach StatusNet/Identi.ca geschrieben werden
    • Bessere Integration in BuddyPress
    • …alles was euch noch so einfällt!?!

    Ich würde mich sehr über Feedback, Fragen, Anregungen, Kritik, … freuen. Viel Spaß beim testen!

    …sollte alles gut funktionieren, werde ich die Plugins dann nächste Woche veröffentlichen, also TESTEN!

    14 Kommentare zu FederatedPress
  • …darum geht es in der OpenWeb Kolumne des aktuellen Webstandards-Magazins (seit gestern (18.12.2010) im Fachhandel). Hier ein kleiner Auszug:

    DataPortability war das Thema in 2008, 2009 wurde der Begriff OpenWeb geprägt und nun dreht sich alles um das Federated Social Web.

    Chris Messina nennt es Distributed Social Network (kurz DiSo), bei Khris Loux heißt es SynapticWeb, Chris Saad bevorzugt das Interoperable Web und Evan Prodromou führt jetzt noch einen weiteren Begriff ein: „Federated Social Web“. Aber wo liegen die Unterschiede?

    Würde mich sehr über euer Feedback freuen!

    …man kann sich übrigens gerade alle alten Ausgaben des Magazins für lau runterladen… es kosten nur einen Tweet!

    4 Kommentare zu The Federated Social Web