Artikel mit Tag portier
Verwandte Tags
Keine verwandten Tags gefunden.Portier bald mit besserer Unterstützung für private Email-Domains
Friday, 25. August 2017
Die Entwicklung von Portier hat wieder Fahrt aufgenommen, nachdem das Projekt eine Weile einfach vor sich hin lief. Und die anstehenden neuen Funktionen sind richtig nett.
Portier funktioniert ja mit jeder Email-Adresse. Um sich einzuloggen gibt der Webseitenbesucher seine Emailadresse an, die Seite leitet sie an Portier weiter, und Portier authentifiziert sie dann. Ich nutze das bereits auf Pipes (einfach mal in den Editor gehen und speichern). Aber Portier hatte eine Sonderbehandlung für Gmail: Nutzer von Gmail müssen nicht in ihre Emails schauen, sondern loggen sich einfach mit ihrem Account ein. Und da die meisten Nutzer sowieso bei Google eingeloggt sind geht das oft sogar automatisch.
Mit dem neuen Code, heute gemerged, geht das auch mit anderen Email-Adressen. Der Mailbetreiber muss nur eine Webfinger-Datei ausliefern, dort auf einen Identity Provider (IdP) verweisen, der dann dem Nutzer eine Loginseite anzeigen kann. Und diesen Login natürlich ebenfalls langfristig speichern könnte.
Idealziel davon ist natürlich, dass große Webmailanbieter für ihre Nutzer solche IdPs bereitstellen und so die Nutzung von Portier komfortabler machen.
Nutzer mit sinatra-portier einfachst authentifizieren
Tuesday, 15. November 2016
Sinatra-portier ist ein Fork des Gems sinatra-browserid, das ich ebenfalls vorher geforkt hatte. Es funktioniert für den Entwickler noch genauso, der Unterschied ist, dass statt dem Button ein Formular erstellt wird, und dass Portier zum Bestätigen der Email benutzt wird.
Ein Sinatra-Projekt von Persona auf Portier umstellen
Sinatra-portier ist ganz offiziell als Gem registriert und kann darüber installiert werden:
gem install sinatra-portier
Im Sinatra-Projekt bindet man aber weiterhin sinatra/browserid ein:
require 'sinatra/browserid'
Dadurch kann man ohne Codeanpassung von Persona zu Portier wechseln. In den meisten Projekten muss man nur in der Gemfile gem sinatra-browserid
mit gem sinatra-portier
ersetzen und dann schauen, ob das Loginformular anstatt des Buttons im bestehenden Design ebenfalls funktioniert.
Die API
Es werden einige weniger Helferfunktionen und sinatraweit globale Variablen definiert, mit denen das Gem genutzt wird:
authorized?
True wenn der Nutzer sich mit Portier eingeloggt hat. Die Kernfunktion.
authorized_email
Die Email (als String), mit welcher der Nurzer eingeloggt ist. Kann benutzt werden um die genauen Rechte des Nutzers zu prüfen.
authorize!
Leitet zur Loginseite weiter, wenn der Nutzer nicht bereits eingeloggt ist.
render_login_button
Gibt das HTML des Loginformulars aus.
logout!
Loggt den Nutzer aus,
authorized?
ist danach false undauthorized_email
leer.
Ein Codebeispiel zeigt, wie die Funktionen benutzt werden können:
require 'sinatra/base' require 'sinatra/browserid' module MyApp < Sinatra::Base register Sinatra::BrowserID set :sessions, true get '/' if authorized? "Welcome, #{authorized_email}" else render_login_button end end get '/secure' authorize! # require a user be logged in email = authorized_email # browserid email ... end get '/logout' logout! redirect '/' end end
Nutzungspattern
Mit der obigen API gibt es mehrere Wege, wie man am besten Nutzer anmeldet und ihre Email prüft. Aber ich weiß noch, dass ich eine Weile brauchte um das für mich durchzustrukturieren, trotz des Beispiels. Nicht einfach zu prüfen, ob das eingegebene Passwort das gespeicherte ist, war ungewohnt. Aber im Grunde ist es noch einfacher: Prüfen, ob man die Emailadresse bereits kennt (=ist sie in der Datenbank?) und welche Rechte sie hat.
Ersten Nutzer zum Admin machen
Aber wo fängt man an? Bei der ersten Nutzung ist die Datenbank ja noch leer, es gibt nichts abzugleichen. Meine Projekte, die dieses Gem nutzen (ursprung, feedtragón und music-streamer) zeigen daher einen kleinen Installer, wenn die Datenbank leer ist. In diesem loggt der Nutzer sich über Portier ein, und diese erste Emailadresse wird dann als Adminadresse in der Datenbank gespeichert. Später prüft man, ob authorized_email
die gespeicherte Emailadresse ist, und kann so zu schützende Bereiche der Seite abriegeln.
Weitere Helfer erstellen
Um die Emailadresse auf Adminrechte zu prüfen definiert man am besten zwei weitere Helfer:helpers do def isAdmin? if authorized? if Database.new.getAdminMail == authorized_email return true end end return false end def protected! unless isAdmin? throw(:halt, [401, "Not authorized\n"]) end end end … get %r{/([0-9]+)/editEntry} do |id| protected! … end
Mit Nutzerliste abgleichen
Was aber, wenn man mehr als einen Nutzer haben will? Dann vergleicht man mit der Nutzerdatenbank.helpers do def isAdmin? if authorized? return Database.new.getAdminMail == authorized_email end return false end def isRegistered? if authorized? return Database.new.registered?(authorized_email) end end def protected! unless isRegistered? halt 401, erb(:login) end end def adminProtected! if (isRegistered? && isAdmin?) return true else halt 401, erb(:login) end end endRouten, die normale Nutzer aufrufen können, werden wie zuvor mit
protected!
geschützt. Hier wird nur geschaut, ob in der Datenbank der Nutzer registriert ist. Music-streamer z.B. hat eine Liste in den Einstellungen, in die der Admin neue Adressen und damit neue Nutzer hinzufügen kann. adminProtected!
hingegen prüft, ob authorized_email
die gespeicherte Emailadresse des Admins ist.
Das könnte dann mit einem kompletten Rollensystem erweitert werden, in dem der Code für jede Email prüft, welche Rolle und damit welche Rechte er hat. Und die Datenbankstruktur dafür bleibt simpel:
CREATE TABLE IF NOT EXISTS users( mail TEXT PRIMARY KEY, role TEXT );
Das schöne an dem System ist, was auch bei Persona schon hübsch war: Wir haben mit dem bisschen Code eine komplette Nutzerverwaltung in ein Sinatra-Projekt eingebaut, ohne ein einziges Passwort zu speichern oder auch nur einen Gedanken an Hashverfahren zu verschwenden.
Portier: Ein Nachfolger für Mozillas Persona/Browserid
Monday, 31. October 2016
Wir stellen heute Portier vor. Portier ist freie Infrastruktur für das Web. Es ist ein Loginsystem, das Seiten benutzen können, um Nutzern die Möglichkeit zu geben sich per Email anzumelden. Der Kniff dabei ist, dass die Seite keinerlei Passwort speichern muss.
Das folgende ist einfach zu verstehen, wenn du vorher die Demo ausprobierst.
Portier funktioniert so: Auf der Webseite, in die man sich einloggen will, ist ein Loginformular, das nach der Emailadresse fragt. Der Nutzer gibt seine Adresse ein und schickt das Formular ab. Es wird zu Portier geschickt, dessen Aufgabe dann ist diese Emailadresse zu authentifizieren. Er prüft ob der Nutzer die Emailadresse wirklich kontrolliert. Dafür hat Portier zwei Möglichkeiten:
- Er kann eine Email mit einem Bestätigungslink zurück zu Portier an die Adresse schicken.
- Alternativ wird die OpenID-Authentifizierung des Email-Providers genutzt, also bei den meisten Google Sign-In. Das ist komfortabler, da komplett im Browser.
Weiß Portier dann, dass die Emailadresse wirklich dem Nutzer gehört, schickt er an die Seite eine signierte Bestätigung und leitet den Nutzer zurück. Die Seite kann den Nutzer dann einloggen.
Portier und Mozillas Persona
So etwas ähnliches gab es schonmal, es war ein Projekt von Mozilla. Es hieß anfangs Browserid, später war das dann nur noch der Name des verwendeten Protokolls und das Projekt wurde zu Persona umgetauft. Das war hochproblematisch, denn Persona war bereits der Name von diesen Firefox-Themes. Persona hatte noch mehr Probleme: Es war nicht einfach Infrastruktur, sondern sein eigenes Produkt, das Bekanntheit erlangen sollte und das größer war als ein einfacher Email-Bestätiger. Beispielsweise mussten Nutzer sich beim ersten Login auf der Persona-Seite einloggen und dafür ein Passwort wählen, und es konnte nur funktionieren, wenn Nutzer den Persona-Button einordnen konnten. In einem Nutzertest von mir hat keiner der Testpersonen den dafür nötigen Wechsel zwischen Browser, Emailprogramm und Tabs samt anschließendem Zurückwechseln zur Zielseite hinbekommen.
Das alles will Portier besser machen, wobei klar ist: Persona war eine in meinen Augen großartige Idee. Das Portier-Projekt ist ein Versuch, diese Idee weiterleben zu lassen und die Fehler, die Persona gemacht hat, nicht zu wiederholen.
Portier versucht nicht, ein Single-Sign-On-System zu sein, also dass ein Nutzer automatisch auf jeder Portier-nutzenden Seite eingeloggt sind, nur weil er auf einer einzelnen Seite sich mit Portier einloggte. Es gibt schlicht keine zentrale Instanz, in die der Nutzer sich einloggen muss. Es gibt nur den Portier-Broker, der keine Nutzerdaten speichert und von dem es viele verschiedene Installationen geben kann. Wir werden eine Instanz hosten (auf https://broker.portier.io/), aber theoretisch kann jede Seite seinen eigenen Broker haben. Auch praktisch werden wir versuchen das möglichst einfach zu machen – der Code ist überschaubar, das Protokoll möglichst simpel und nutzt mit OpenID existierende Standard, und mit der verwendeten Programmiersprache Rust können Binaries bereitgestellt werden.
Persona wird Ende November abgeschaltet. Es erreichte nicht die Bekanntheit, die Mozilla sich erhofft hatte. Portier eignet sich als Alternative, z.B. mein sinatra-portier-Gem kann direkt sinatra-browserid ersetzen, ohne dass groß der Code angepasst werden muss.
Das Portier-Projekt
Portier ist kein Mozilla-Projekt. Nach der Ankündigung der Abschaltung haben sich einfach ein paar Entwickler zusammengetan, um eine Alternative zu schaffen. Nach einer durchaus langen Planungsphase ist daraus Portier entstanden, das jetzt einsatzbereit wird. Es gibt noch viel zu tun (es gibt eine Roadmap): Arbeit am Broker, Verbessern der Dokumentation auf der Webseite, und generell das Bauen von Modulen für Webframeworks, um die Integration möglichst einfach zu machen. Da können wir Hilfe brauchen. Aber schon jetzt funktioniert Portier und kann allen Webentwicklern helfen, die Persona ersetzen müssen, oder die so etwas wie Persona nur als aktives Projekt haben wollen.