Die DT 125 läuft. Nachdem ich heute den gereinigten Vergaser verbaut und die letzten Teile angebracht habe, bescherte mir direkt der erste Kick die für einen 2-Takter beim Kaltstart typische, dunkelblaue Abgaswolke. Die erste (kurze) Probefahrt beschränkte sich mangels Zulassung auf die Strecke zwischen Parkplatz und Tiefgarage des Supermarktes nebenan – aber Spaß hat es trotzdem gemacht. Weniger Spaß hingegen macht der Anblick des Motorrads – wenn ich ganz ehrlich bin, dann ist das schon eine stinkende Dreckskarre. Auch vom Sound her reicht es gerade mal für das Prädikat „muffige Zwiebacksäge“. Aber so schnell gebe ich nicht auf. Als nächstes besorge ich mir von Götz Motorsport noch weitere Ersatzteile, die sich als defekt herausgestellt haben, verbaue diese und danach geht es dann erstmal zum TÜV.
Notwendige Ersatzteile
Vernünftigen Benzinschlauch und Filter
Linke Lenkerarmatur (Fernlichtschalter defekt)
Bremsscheibenabdeckung (Braucht man nicht, sagt der Götz-Kundenberater)
Kettensatz (25% Rabatt bei Götz – bei dem Preis ist „Haben besser als Brauchen“)
Neue (Carbon-)Membranblättchen (Machen mehr Probleme als Freude für die Straße, sagt der Götz-Kundenberater)
Optische Aufwertung
schwarze Verkleidungsschrauben
Sitzbankbezug (hat meine Freundin beanstandet, weil hinten aufgerissen)
Soziusfußrasten
Wie geht es weiter?
Gemischaufbereitung einstellen
Reifen aufziehen lassen
Ersatzteile verbauen
TÜV
Tank (selbst)lackieren
Probefahrt und eventuell weitere Maßnahmen planen
Nachdem ich beim TÜV war, schaue ich mir nochmal Auspuffanlage, Luftfilter und Vergaser an… irgendwie lässt mir das so keine Ruhe.
Nachtrag 25.11.2009, 18:54 Uhr:
Nach der kurzen Probefahrt und einem eingehenden Gespräch mit einem Zweiradmechaniker (der auch TÜV-Abnahmen macht) hab ich es trotz aller guten Vorsätze doch getan. Ich habe einen offenen Luftfilter und eine komplette Athena Auspuffanlage gekauft. Nach der HU/AU am Montag beantrage ich Zulassungspapiere und lasse die Leistungssteigerung (21-24 PS) eintragen.
Knapp 4 Wochen sind nun vergangen, seitdem ich das letzte Mal in der Garage an der DT 125 geschraubt habe. In der Zwischenzeit ist ein Paket mit Ersatzteilen von Polo eingetroffen, neue Continental TKC 80 Twinduro Reifen stehen zum Aufziehen bereit und der Vergaser ist auch generalüberholt. Trotz des schlechten Wetters* habe ich mich daher knapp 3 Stunden mit dem Einbau der Neuteile und dem Zusammenbau der gereinigten Einzelteile befasst.
Die alten Griffgummis konnte man prima mit einem Cutter aufschlitzen, entfernen und durch die neuen ersetzen. Die neuen Brems-/Kupplungshebel haben auch einwandfrei gepasst und machen einen soliden Eindruck. Nachdem ich Öl- und Kühlwassertank verbaut, neue Schläuche gezogen und alte Schrauben ausgetauscht habe, sieht das Motorrad schon wieder ganz passabel aus. Bei der Montage des Auspuffs ist mir aufgefallen, dass das Gewinde für die Befestigung des Krümmerendstücks kurz vor dem Endschalldämpfer von einer abgerissenen Schraube blockiert wird – genauso wie die Befestigung der Heckverkleidung auf der rechten Seite. Also Akkubohrer und einen kleinen Metallbohrer geschnappt, Schrauben ausgebohrt, Metallreste entfernt und Gewinde nachgeschnitten. Danach habe ich die Schwinge abgeschmiert, Bowdenzüge mit WD40 geölt und die neue Zündkerze eingesetzt. Letzeres natürlich mit Kupferpaste auf dem Gewinde – wenn schon penibel, dann auch richtig.
Wie geht es weiter?
Vergaser einbauen und Gemischaufbereitung einstellen
Wartungsarbeiten rund um die Bremsanlage – danach entscheiden, ob die Bremsscheiben erneuert werden müssen
Reinigen und Fetten der Antriebskomponenten – danach entscheiden, ob Kettenblatt/Ritzel/Kette erneuert werden müssen
Betriebsflüssigkeiten wechseln
Reifen aufziehen lassen
Tank (selbst) lackieren
Soziusfußrasten reparieren
Fernlichtschalter ersetzen
TÜV, Leistungssteigerung & Co.
Nachdem die erste Euphorie verflogen ist, habe ich mich nun auch emotional auf den Einsatz der DT 125 als reines Wintermotorrad eingestellt. Es war schon ein bißchen Disziplin nötig, um nicht doch die ein oder andere Investition aus Leidenschaft zu tätigen. Mittlerweile sehe ich aber auch das Thema Leistungssteigerung rational – ich werde nach Erledigung der letzten Arbeiten erstmal den Segen vom TÜV einholen und die DT 125 eine Zeit lang fahren. Danach entscheide ich, inwiefern Optimierungsbedarf besteht. Mein Kopf sagt mir, dass das jetzige Setup (110km/h und knapp 17 PS) für den Winter und Fahrzeugtyp absolut ausreichend ist und ich mir die Kosten und Nerven in Bezug auf die Eintragung einer Leistungssteigerung auf mehr als 24 PS sparen sollte. Das Argument, die dadurch gesparten Kosten in mein Café-Racer Projekt investieren zu können, hab ebenfalls dazu geführt, dass ich die Erneuerung von Bremsscheiben, Kettenblatt, Ritzel und Primärkette nochmal kritisch betrachten werde. Solange der Zustand die Betriebssicherheit und Zuverlässigkeit im Rahmen des Einsatzwecks nicht gefährdet, verzichte ich darauf.
* Leider habe ich in der Garage derzeit weder Licht noch Heizung – Katalytofen mit entsprechender Abluftvorrichtung und Anschluß an das Stromnetz stehen aber ganz oben auf der Wunschliste.
Ich habe Urlaub. Das Wetter ist schlecht, es regnet und in der Garage ist es dunkel, kalt und ungemütlich. Genau richtig, um in aller Ruhe die Einkaufsliste für das Wintermotorrad-Projekt mit gespitztem Bleistift zu kontrollieren, Preise zu vergleichen und das ein oder andere (nicht bei Polo, Louis oder Götz-Motorsport erhältliche Ersatzteil) beim Yamaha-Händler zu bestellen. Besonders hilfreich dabei ist der Original Yamaha Teilekatalog, der mir soeben von einem Forumsmitglied des DT125-Forums zur Verfügung gestellt worden ist. Den Katalog (2,3 MB) könnt ihr euch hier herunterladen.
Nach 5 Monaten Wartezeit hielt ich endlich ein Paket aus Viersen in der Hand. Nach dem Öffnen war klar: Das Warten hat sich gelohnt.
Wulf Peppmöller, für seine Handwerkskunst bekannt und längst kein Geheimtipp mehr, fertigt individuelle Einzelstücke nach Maß aus VA an. Für mein Café-Racer-Projekt sollte es ein Nachbau im Stil der Norton Commando werden. Dank eingeschlagener Typenkennzeichnung, des Kammersystems und der Verwendung mit einem Rahmen aus dem Jahre 1979 ist sogar eine TÜV-Eintragung möglich. Wulf Peppmöller gibt zudem eine Garantie auf Passgenauigkeit und Rostfreiheit. Mit 360,00 € für Endschalldämpfer, Krümmer und Flansch liegt man natürlich das ca. 7-fache über den optisch ähnlichen Krawalltüten, die es bei Louis & Co. gibt – aber ich denke nicht, dass ich den Unterschied in Bezug auf Rostanfälligkeit, Verarbeitung, Passgenauigkeit und vorallem „vernünftigem Sound“ und Leistung näher erläutern muß.
Jetzt stellt sich abschließend die Frage, ob ich den Auspuff in der Edelstahloptik belasse, oder…
(Schwarz-)Verchromen?
Binden?
In dieser Hinsicht bin ich mir noch unsicher, daher stelle ich die Entscheidung erstmal zurück. Nächster Meilenstein im Projekt ist ohnehin erstmal die Motorrevision und im Anschluß das Rolling Chassis.
Wir alle kennen das übliche Anmelde-Prozedere bei praktisch allen Web-Applikationen, die mit individuellen Benutzerdaten arbeiten. Am Anfang steht die Registrierung, bei der wir mindestens einen (hoffentlich noch verfügbaren) Benutzernamen, ein (möglichst sicheres) Passwort und unsere E-Mail-Adresse angeben müssen. An letztere wird üblicherweise im Anschluß ein Bestätigungslink versendet, um sicherzustellen, dass wir auch Inhaber des Postfaches sind. Nach erfolgreicher Bestätigung steht dann einem ersten Login-Versuch nichts mehr im Wege: anhand der von uns vergebenen Kombination aus Benutzername und Passwort können wir uns jederzeit an der Web-Applikation anmelden und auf persönliche Daten und individuelle Einstellungen zugreifen.
Das, was für den Benutzer der Web-Applikation mittlerweile obligatorisch ist, stellt den Entwickler derselben jedoch vor eine Vielzahl von zu bewältigenden Aufgaben und bringt nicht zuletzt auch eine Menge Pflichten mit sich. Denn immerhin obliegt es der Sorgfalt des Entwicklers, dass vertrauliche Daten vor unbefugtem Zugriff Dritter geschützt sind und im Falle einer Kompromittierung der Web-Applikation der Schaden so gering wie möglich gehalten wird.
Das RESTful Authentication Plugin des Ruby on Rails Core Members Rick Olson galt lange Zeit als etablierter De-facto-Standard zur Implementierung eines Authentifizierungs-Features. RESTful Authentication besteht dabei im wesentlichen aus einem Generator nebst Templates und einem Authentifizierungsmodul. Die vermeintlichen Vorteile dieses Ansatzes sind nicht nur die Erzeugung aller relevanten Komponenten innerhalb einer Rails-Applikation, sondern auch die Integration des Authentifizierungssystems in zentrale Bestandteile wie Routing, Helper & Co. Diese vermeintlichen Vorteile kehren sich jedoch schnell zu erheblichen Nachteilen um, sofern man selbst Anpassungen an der Authentifizierungsroutine vornehmen möchte. Spätestens dann ist man mit den über die Applikation verteilten Code-Fragmenten konfrontiert, sodass unterm Strich fast schon mehr Aufwand entsteht, als eine vollständige Implementierung „from scratch“ in Anspruch nähme.
Authlogic und der Grund, warum wir Rails lieben
Einer der vielen Gründe, die für die Entwicklung mit Ruby on Rails sprechen, ist die vorgegebene, klare (MVC-)Struktur einer typischen Applikation und die Integration bewährter Entwicklungsparadigmen. Besonders das „Convention over Configuration“-Paradigma schafft eine sinnvolle Grundlage, sodass sich der Entwickler auf das Wesentliche der Applikation konzentrieren kann. Authlogic folgt diesen Grundgedanken des „RailsWay“ und macht sie zu seinen Erfolgsprinzipien.
„A code example can replace a thousand words“ (Ben Johnson)
Ausgehend von einem frisch erzeugten Applikationsgrundgerüst muß zunächst das Plugin installiert werden:
Für diesen Artikel verwende ich der Einfachheit halber die Installation des Plugins. Alternativ kann aber natürlich auch das RubyGem verwendet werden:
$ gem sources -a http://gems.github.com
$ sudo gem install binarylogic-authlogic
Bei der Verwendung des RubyGems empfiehlt es sich zudem, in der config/environment.rb eine entsprechende Abhängigkeit zu definieren:
config.gem ‘binarylogic-authlogic’
Im Anschluß können wir bereits direkt ein Model erzeugen, welches von der Klasse Authlogic::Session::Base abgeleitet wird.
$ script/generate session user_session
Das besondere an diesem Model ist, dass es sich um das gesamte Session-Management kümmert und wie ein ActiveRecord-Model verwendet werden kann. Uns hindert also nichts daran, einen REST-konformen Controller (Listing 1) zu erzeugen, wie wir es auch für ein ActiveRecord-Model tun würden.
$ script/generate controller user_sessions
Listing 1
class UserSessionsController < ApplicationController
before_filter :require_no_user, :only => [:new, :create]
before_filter :require_user, :only => :destroy
def new
@user_session = UserSession.new
end
def create
@user_session = UserSession.new(params[:user_session])
if @user_session.save
flash[:notice] = 'Hi, you are logged in!'
redirect_back_or_default account_url
else
render :new
end
end
def destroy
current_user_session.destroy
flash[:notice] = 'Goodbye, you are logged out!'
redirect_back_or_default new_user_session_url
end
end
Das Routing für diesen Controller wird ebenfalls, wie gewohnt, in der config/routes.rb definiert.
map.resources :user_sessions
Die Views sind äußerlich nicht von denen zu unterscheiden, die via Controller mit ActiveRecord-Objekten interagieren (Listing 2). Im Gegensatz zu RESTful Authentication stehen daher auch die gewohnten Methoden zur Darstellung von etwaigen Fehlern zur Verfügung.
Nützliche (und für dieses Beispiel auch notwendige) Methoden, z.B. das sich selbst erklärende redirect_back_of_default, werden zentral im ApplicationController definiert (Listing 3).
Listing 3
class ApplicationController < ActionController::Base
protect_from_forgery
helper :all
helper_method :logged_in?, :current_user_session, :current_user
filter_parameter_logging :password, :password_confirmation
protected
def store_location
session[:return_to] = request.request_uri
end
def redirect_back_or_default(default)
redirect_to(session[:return_to] || default)
session[:return_to] = nil
end
def current_user
@current_user ||= current_user_session and current_user_session.user
end
def current_user_session
@current_user_session ||= UserSession.find
end
def logged_in?
not current_user.nil?
end
def require_user
unless logged_in?
store_location
flash[:notice] = 'Please login in to access this page!'
redirect_to new_user_session_url
return false
end
end
def require_no_user
if logged_in?
store_location
flash[:notice] = 'Please logout to access this page!'
redirect_to account_url
return false
end
end
end
Damit ein Benutzer nach einem erfolgreichen Login auf seine persönliche Seite weitergeleitet wird, definieren wir noch einen AccountsController (Listing 4) und eine Route für die dazugehörige, singuläre Resource in der config/routes.rb:
class AccountsController < ApplicationController
before_filter :require_user
def show
@account = current_user
end
end
Der AccountsController kann später natürlich noch um weitere Methoden zum Bearbeiten des Profiles erweitert werden. Um jedoch unbefugten Zugriff auf fremde Benutzerdaten zu verhindern, sollte das Basisobjekt ausschließlich mittels der Methode current_user geladen werden. Es sei denn, man implementiert z.B. eine rollenbasierte Autorisierung, bei der ein Zugriff auf alle Benutzerobjekte durch Superuser vorgesehen ist. Wie das funktioniert, schreibe ich in einer der nächsten Ausgaben der RailsWay.
Bitte registrieren Sie sich!
Eine Benutzerauthentifizierung ist jedoch nichts ohne die zugrundeliegenden Benutzer. Und diese sollen sich selbstständig registrieren können. Dazu erzeugen wir zunächst das Model User:
$ script/generate model user
Für eine sinnvolle Minimalkonfiguration, bei der wir die E-Mail-Adresse für den Login verwenden, genügt es, in der dazugehörigen Migration die Attribute email, crypted_password und persistence_token zu definieren (Listing 5). Es sei jedoch bereits jetzt schon erwähnt, dass Authlogic eine Vielzahl von „MagicColumns“ beinhaltet, auf die wir später noch zurückkommen werden.
Listing 5
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :email, :null => false
t.string :crypted_password, :null => false
t.string :persistence_token, :null => false
t.timestamps
end
end
def self.down
drop_table :users
end
end
Wir führen nun die Migration aus:
$ rake db:migrate
…und teilen dem Model User mit, dass wir es zur Authentifizierung von Benutzerdaten verwenden möchten:
class User < ActiveRecord::Base
acts_as_authentic
end
Technisch gesehen haben wir bereits jetzt eine vollständige Benutzerauthentifizierung. Beeindruckend einfach, oder? Damit sich Benutzer nun selbstständig registrieren können, müssen wir natürlich auch ein entsprechendes Registrierungsformular bereitstellen. Wir möchten zudem, dass ein Benutzer sich erst dann einloggen kann, wenn er durch Anklicken eines Aktivierungsschlüssels bestätigt hat, dass die zur Registrierung verwendete E-Mail-Adresse auch wirklich ihm gehört. Dieses Bestätigungsprozedere bilden wir in einem endlichen Automaten ab.
Oh, Du Zustandmaschine, Du endlicher Automat!
Beim Schlagwort „Endlicher Automat“ werden bei dem ein oder anderen Leser mit akademischem Hintergrund Erinnerungen an Vorlesung zur Theoretischen Informatik und Automatentheorie wach. Ein endlicher Automat („engl. Finite State Machine“), um den es uns nun geht, beschreibt ein Verhalten bestehend aus Zuständen, Zustandsübergängen und Aktionen. Am Beispiel der Benutzerregistrierung erklärt, gibt es zwei Zustände: bestätigt (confirmed) und unbestätigt (pending). Um nun vom Zustand unbestätigt in den Zustand bestätigt zu wechseln (Zustandsübergang) ist eine Aktion notwendig – nämlich das Klicken des per E-Mail zugestellten Aktivierungsschlüssels. Aber keine Panik – so kompliziert es für manchen auch klingen mag, so einfach kann man es Dank des acts_as_state_machine-Plugins (mittlerweile umbenannt in AASM) in einer Rails-Applikation anwenden. Wir installieren das Plugin wie folgt:
Alternativ kann auch hier wieder das RubyGem verwendet werden:
$ sudo gem install rubyist-aasm
…welches dann wiederum konsequenterweise auch als Abhängigkeit in config/environment.rb definiert werden sollte:
config.gem 'rubyist-aasm'
AASM speichert den aktuellen Status eines Objektes in der Datenbank. Dazu erweitern wir das dem Automaten zugrundeliegende Model User um das Attribut status:
Bevor wir die Migration anwenden, sollten wir noch einen Standardwert für das Attribut definieren. Das ist zwar nicht zwingend notwendig – gehört aber meines Erachtens nach zu einem sauberen Stil und trägt zur Wahrung der logischen Integrität der Daten bei.
class AddStatusToUsers < ActiveRecord::Migration
def self.up
add_column :users, :status, :string, :default => 'pending'
end
def self.down
remove_column :users, :status
end
end
$ rake db:migrate
Die eigentliche Definition des Automaten erfolgt im Model User (Listing 6).
Listing 6
class User < ActiveRecord::Base
acts_as_authentic
include AASM
attr_protected :status
aasm_column :status
aasm_initial_state :pending
aasm_state :pending
aasm_state :confirmed
aasm_event :confirm do
transitions :to => :confirmed, :from => :pending
end
end
assm_state definiert die beiden Zustände, die eine Registrierung haben kann. assm_event erzeugt automatisch die Instanzmethode :confirm!, die wir später aufrufen, wenn ein Benutzer den Bestätigungslink aufruft, um den gewünschten Zustandsübergang auszulösen. An dieser Stelle möchte ich auf die vielen zusätzlichen Funktionen des AASM-Plugins hinweisen, die u.a. neben der automatischen Bereitstellungen von zustandsspezifischen named_scopes auch die Ausführung bestimmter Aktionen beim Verlassen oder Eintreten eines bestimmten Zustands ermöglichen. Eine Vielzahl von zustandsorientierten Vorgängen lässt sich so in Web-Applikation hervorragend abbilden und sorgt auf diese Weise für gut lesbaren und sicheren Code.
„MagicColumns“, „MagicStates“ – nur Harry Potter fehlt
Authlogic verfügt über sog. „MagicColumns“ und „MagicStates“ – letzere sorgen auf magische Weise dafür, dass Authlogic bereits jetzt ohne unser Zutun mit dem endlichen Automaten zusammenarbeitet. Authlogic fragt bei jedem Login die Methoden active?, approved? und confirmed? ab – sofern sie existieren. Durch die Einführung unseres endlichen Automaten mit dem Zustand confirmed haben wir automatisch auch die Instanzmethode confirmed? erhalten. Bei unbestätigten Registrierungen gibt diese den Wert false zurück und veranlasst Authlogic, eine passende Fehlermeldung anzuzeigen. So wird verhindert, dass sich ein Benutzer ohne vorherige Bestätigung mit seinen Zugangsdaten anmelden kann.
Für die Erzeugung eines Aktivierungsschlüssels verwenden wir die „MagicColumn“ perishable_token, was übersetzt sinngemäß mit „temporäres Merkmal“ übersetzt werden kann. Temporär deswegen, weil Authlogic dieses Attribut bei jeder Aktualisierung des Benutzerobjektes verändert. Die Erweiterung erfolgt wie gewohnt mit einer Migration:
Vor Anwendung dieser Migration passen wir auch hier die Migration noch einmal an, sodass das Vorhandensein eines Wertes für das neue Attribut forciert wird.
class AddPerishableTokenToUsers < ActiveRecord::Migration
def self.up
add_column :users, :perishable_token, :string, :null => :false
end
def self.down
remove_column :users, :perishable_token
end
end
$ rake db:migrate
Da es sich bei der Benutzerregistrierung zunächst um nichts anderes als die Erzeugung und Speicherung eines ActiveRecord-Objektes handelt, können wir wieder zu bekannten Mitteln greifen. Ein REST-konformer Controller (Listing 7):
$ script/generate controller users
…mit entsprechendem Eintrag in der config/routes.rb:
map.resources :users
…und einem dazugehörigen Formular (Listing 8) reichen schon aus – denn um die Validierung kümmert sich in der Standardkonfiguration bereits Authlogic.
Listing 7
class UsersController < ApplicationController
before_filter :require_no_user
def new
@user = User.new
end
def create
@user = User.new(params[:user])
if @user.save
flash[:notice] = 'Thanks for signing up. We just sent you a confirmation email!'
redirect_back_or_default root_url
else
render :new
end
end
def confirm
@user = User.pending.find_using_perishable_token(params[:confirmation_code])
unless @user
flash[:error] = 'Sorry, your activation code is invalid!'
else
@user.confirm!
@user.reset_perishable_token!
flash[:notice] = 'Great, your registration has been confirmed successfully!'
end
redirect_back_or_default root_url
end
end
Um die Zustellung der Bestätigungsmail müssen wir uns allerdings selbst kümmern. Dazu erzeugen wir zunächst die ActionMailer-Klasse UserMailer (Listing 9):
$ script/generate mailer user_mailer
Listing 9
class UserMailer < ActionMailer::Base
include ActionController::UrlWriter
def confirmation_code(user)
from 'Foo Bar '
recipients user.email
subject 'Please confirm your registration'
body :user => user
sent_on Time.now
end
end
Wichtig ist dabei, dass wir das Modul ActionController::UrlWriter inkludieren und eine Domain in config/environment.rb als Grundlage für die UrlWriter-Methoden konfigurieren, damit wir den Bestätigungslink für das Mailer-Template (Listing 10) erzeugen können:
class ActionMailer::Base
default_url_options[:host] = 'example.org'
end
Diese Notwendigkeit lässt sich mit der Tatsache erklären, dass der Prozess des E-Mail-Versands in einer MVC-Applikation keinen Zugriff auf einen Request (ActionController::AbstractRequest) hat, um Informationen über den aktuellen Hostnamen der Applikation zu bekommen. Wer möchte, kann daher für die verschiedenen Environments die passenden URLs in den dazugehörigen, separaten Konfigurationsdateien (z.B. config/environments/production.rb) konfigurieren.
Dem aufmerksamen Leser ist sicherlich die Methode confirm im UsersController (Listing 7) aufgefallen, die ein Benutzerobjekt anhand des Attributs perishable_token aus dem Pool der unbestätigten Benutzer lädt. Damit ein Benutzer also später nach Klicken des Aktivierungslinks auf diese Methode geroutet wird, benötigten wir noch einen passenden Eintrag in der config/routes.rb:
Bleibt nun noch der Versand der Bestätigungs-E-Mail nach Erzeugung eines Benutzerobjektes. Um diesen auszulösen, bedienen wir uns eines ActiveRecord-Observers (Listing 11):
$ script/generate observer user
Listing 11
class UserObserver < ActiveRecord::Observer
def after_create(user)
UserMailer.deliver_confirmation_code(user) if user.pending?
end
end
Der UserObserver muss wie üblich in der config/environment.rb aktiviert werden:
config.active_record.observers = :user_observer
Wenn wir nun unsere Applikation starten und alles richtig gemacht haben, können sich neue Benutzer unter dem Menüpunkt Register (Abb. 1) selbstständig registrieren, bekommen nach Registrierung eine Bestätigungs-E-Mail (Abb. 2) und können sich nach erfolgreicher Aktivierung (Abb. 3) einloggen (Abb. 4), um ihre persönlichen Daten einzusehen (Abb. 5).
Abb.1
Abb.2
Abb.3
Abb.4
Abb.5
Where Is My Mind?
Twitter, YouTube, Flickr & Co. – wenn es schon schwer fällt, eine vollständige Liste aller etablierten Onlinedienste wiederzugeben, dann ist es kein Wunder, dass der ein oder andere Benutzer gelegentlich Schwierigkeiten hat, sich an die richtige Kombination aus Benutzername und Passwort für die jeweilige Plattform zu erinnern. Dieses Problem wird zudem dadurch verstärkt, dass einige Applikationen bei der Anforderung eines vergessenen Passworts (phpBB & Co.) selbst ein zufälliges Passwort generieren und es per E-Mail versenden. Genauso zweifelhaft wie das Versenden jeglicher Zugangsdaten per E-Mail in Bezug auf Sicherheit ist, so wenig benutzerfreundlich sind auch die meisten Mechanismen, mit denen man diesen Vorgang zunächst auslösen muß.
Dank der Freiheit, die Authlogic bietet, kann man selbst entscheiden, wie man diesem Problem begegnen möchte. Ich habe sehr gute Erfahrung damit gemacht, einem Benutzer an seine E-Mail-Adresse einen Link zu senden, mittels dessen er sein Passwort selbst neu vergeben kann. Und genau das werden wir jetzt implementieren, indem wir zunächst einen PasswortResetRequestsController (Listing 12) generieren:
class PasswordResetRequestsController < ApplicationController
before_filter :require_no_user
def create
@user = User.find_by_email(params[:email])
if @user
@user.reset_perishable_token!
UserMailer.deliver_password_reset_instructions
flash[:notice] = 'Please check your email to get further information on resetting your password'
redirect_to root_url
else
flash[:notice] = 'Sorry, there is no user with that email address'
render :new
end
end
end
Auch hier benötigen wir wieder ein Formular (Listing 13), damit der Benutzer seine E-Mail-Adresse angeben kann.
Zum Versand der E-Mail erweitern wir den bestehenden UserMailer um folgende Methode…
def password_reset_instructions(user)
from 'Foo Bar '
recipients user.email
subject 'How to reset your password'
body :user => user
sent_on Time.now
end
…und fügen folgenden Inhalt für das zugehörige Template in die Datei app/views/user_mailer/password_reset_instructions.erb ein:
Hi,
you may reset your password by clicking the follwing link:
< %= edit_password_reset_request_url @user.perishable_token %>
Thanks!
Nun kann der Benutzer nach Klicken des Reset-Links eines neues Passwort vergeben (Listing 14). Und damit dieser Wunsch nicht unerfüllt bleibt, müssen wir zum Abschluß im Controller natürlich noch die Methoden edit und update implementieren (Listing 15). Nach erfolgreicher Aktualisierung des Passworts ist der Benutzer automatisch eingeloggt und wird auf seine persönliche Seiten weitergeleitet. Bequemer geht es nicht.
# app/controllers/password_reset_requests.rb
def edit
@user = User.find_by_perishable_token(params[:id])
end
def update
@user = User.find_by_perishable_token(params[:id])
unless params[:user][:password].blank?
@user.password = params[:user][:password]
@user.password_confirmation = params[:user][:password_confirmation]
if @user.save
flash[:notice] = 'Your password has been updated. Your are logged in.'
redirect_to account_url
else
render :edit
end
else
flash[:error] = 'Please enter your new password!'
render :edit
end
end
OpenID, OAuth & Co – die Authlogic Add-Ons
Es gibt verschiedene Gründe, keinen eigenen Datensatz zur Authentifizierung etablieren zu wollen. Vielleicht möchte man auf eine bestehende LDAP-Infrastruktur aufsetzen, im Rahmen eines Lazy-Registration-Patterns eine Alternative in Form von OpenID zur Verfügung stellen oder aber eine der zahlreichen Authentifizierungs-APIs der Social-Networks (z.B. Facebook Connect, Twitter’s OAuth) verwenden. Authlogic ermöglicht diese und zukünftige Erweiterungen in Form von Add-Ons, die auf einer Public API aufsetzen.
Authlogic ist Kosmopolit!
Authlogic unterstützt die Rails Internationalization-API vollständig. Für diesen Artikel habe ich mich aus Gründen der Übersichtlichkeit gegen die Übersetzung ins Deutsche entschieden. Der Vollständigkeit halber möchte ich dennoch die verfügbaren Schlüssel zur Übersetzung, so wie sie im Plugin-Ordner unter lib/authlogic/i18n.rb beschrieben sind, aufzählen:
authlogic:
error_messages:
login_blank: can not be blank
login_not_found: is not valid
login_invalid: should use only letters, numbers, spaces, and .-_@ please.
consecutive_failed_logins_limit_exceeded: Consecutive failed logins limit exceeded, account is disabled.
email_invalid: should look like an email address.
password_blank: can not be blank
password_invalid: is not valid
not_active: Your account is not active
not_confirmed: Your account is not confirmed
not_approved: Your account is not approved
no_authentication_details: You did not provide any details for authentication.
models:
user_session: UserSession (or whatever name you are using)
attributes:
user_session: (or whatever name you are using)
login: login
email: email
password: password
remember_me: remember me
Whatcha Gonna Do when they come for you?
Brute-Force, Session-Fixation & Co. gehören zum Standardrepertoire der bösen Jungs. Authlogic ist sich der Gefahren bewusst und stellt dem Entwickler probate Mittel gegen diese Angriffsmuster zu Verfügung. Eine Diskussion und nähere Erläuterung würde den Rahmen des Artikels endgültig sprengen, weswegen ich an dieser Stelle auf das Studium der Sources verweisen möchte. Besonders von Interesse sind dabei z.B. lib/session/brute_force_protection.rb und die Dateien in lib/authlogic/crypto_providers. In jedemfall empfehle ich aber, die zusätzliche „MagicColumn“ password_salt für unsere Beispielapplikation zu erzeugen – diese erschwert das Entschlüsseln der Passwörter für den Fall, dass ein Angreifer Zugriff auf die Datenbanktabelle users erhält. Ebenfalls einen Blick Wert ist das SslRequirement Plugin von David Heinemeier Hansson, um sensible Benutzerinformationen ausschließlich über eine verschlüsselte und verifizierte Verbindung zu übertragen.
„Wandel und Wechsel liebt, wer lebt.“ – ob Richard Wagner auch an dieser Weisheit festgehalten hätte, wenn er Software-Entwickler geworden wäre? Ein Wechsel einer (funktionierenden) Komponente innerhalb einer Applikation bringt oftmals erheblichen Aufwand und nicht selten auch Ärger mit sich, weshalb sich in dieser Hinsicht der gutgemeinte Ratschlag „Never change a running system“ schon eher etabliert hat. Wer doch den Schritt von restful_authentication zu Authlogic in einer produktiven Applikation wagen möchte, dem sei der Artikel des Authlogic-Urhebers Ben Johnson zu diesem Thema ans Herz gelegt.
