I’m writing this blog post in english because it seems to me that many developers still run into this issue. So now it’s up to Google to put them out of their misery…
Automatically reload Rails plugins
I just bought the PDF Plugin Patterns Enhancing Rails 2.1 by Andrew Stewart for getting in touch with best practices for writing a Rails plugin. First of all… this book is awesome. I totally agree to Chris O’Sullivan:
“Bought the [Plugin Patterns] PeepCode PDF…and I gotta say I’m loving it. It’s very well written, and you explain complicated nasty stuff with nice simple examples.”
After reading this book within an hour I started to develop my own plugin acts_as_wizard to make ActiveRecord models suitable for multi-step-forms (aka „Wizards“). I immediately noticed that I had to reload Rails manually every time I changed the plugin code because plugin paths are added to the ActiveSupport::Dependencies.load_once_paths by default. Witold Rugowski suggests adding the plugin to ActiveSupport::Dependencies.explicitly_unloadable_constants and deleting the path from ActiveSupport::Dependencies.load_once_paths or force reloading with ActiveSupport::Dependencies.load_file from a controller.
The wonderful Peepcode book offers a quite easier way…
Reloadable Plugins
If you have done any plugin development at all, you’ll know that changes don’t get picked up until you restart the server. It is tedious.
Happily for us, Rails 2.1 introduced the ability for files in plugins to be reloaded like the rest of the application. To make all plugins reload- able, add the following to your application’s configuration:
You can also switch this on and off per plugin. See the commit log (http://github.com/rails/rails/commit/cc2d6a0b93251fce06bab15c52dbe0a5d5a8342c) for details.
I gave it a try and added config.reload_plugins = true to my environments/development.rb.
It worked – but not for my „acts_as_plugin“. So I wrote an email to the author.
I just bought Plugin Patterns Enhancing Rails 2.1 by Andrew Stewart today.
I’ve a question concerning the following statement on page 95.
In fact it seems that config.reload_plugins = true does not work for acts_as-Plugins, which extend ActiveRecord because ActiveRecord won’t be reloaded anyway (because it’s core part of rails).
Maybe the author has a tip… googling around and trying out did not solve my problem. To be honest… I bought the Peepcode book to avoid this ;-)
After two days I got response from Geoffrey Grosenbach, Mr. Peepcode himself. Cool. And it did the trick. Even cooler.
Here’s another strategy that will definitely work, but requires a bit
of initial configuration.
Summary: Use either unicorn or nginx and Phusion Passenger with my
rstakeout script to automatically restart Passenger every time your
plugin changes.
Unicorn (easy, but untested):
Download my rstakeout.rb script. A copy is here:
http://github.com/EdvardM/rstakeout
Install the unicorn server and start it in your Rails app:
unicorn_rails
Note the PID (“spawned pid=15250″)
In a separate terminal window, run rstakeout.rb, telling it to restart
Unicorn by sending USR2 to unicorn whenever a file in your plugin is
saved:
Now, any time you edit a file in your plugin’s directory, Passenger
will be restarted and you’ll be working with the updated code.
Yes, a bit complicated, but I tried something similar here and it did the trick.
Let me know if you try it!
I can confirm that it works. I’m using Passenger and Apache for development on Mac OS X 10.6.2. Great. I just fetched a copy of rstakeout, put it to /usr/local/bin and ran rstakeout.rb “touch tmp/restart.txt” “vendor/plugins/acts_as_wizard/**/*.rb” from my rails application directory. For testing purposes I added a comment to the plugin’s init.rb and rstakeout immediately noticed it. => vendor/plugins/acts_as_wizard/init.rb changed, running ‘touch tmp/restart.txt’
By the way… if you install the ruby-growl gem and Growl you’ll get a Fancy-schmancy notification everytime you change something.
Trabayo bekommt im Rahmen des X-Mas-Sprints ein paar neue Features, u.a. auch die Möglichkeit zur Integration von Fotos in Service-Profilen, um einer Dienstleistung mehr Ausdruck verleihen zu können. Mittels IPTC-NAA-Annotations werden sinnvolle, maschinenlesbare Metainformationen in die Fotos integriert, sodass diese einen semantischen Kontext bekommen und von Suchmaschinen entsprechend erfasst werden können. Aus verschiedenen Gründen ist es daher erstrebenswert, die Fotos mit einem Wasserzeichen zu versehen, sodass der Bezug zu Trabayo auch optisch direkt hergestellt werden kann. Zu diesem Zwecke habe ich einen Paperclip-Prozessor geschrieben, der wie folgt eingebunden wird.
Über die optionalen Konfigurationsparameter (:watermark_[path|position|dissolve|ratio]) können Dateipfad zum Wasserzeichen, Position des Wasserzeichens im Foto, Grad der Überblendung und die maximale Größe, die das Wasserzeichen im Gesamtgrößenkontext des Fotos einnehmen darf, bestimmt werden.
# lib/paperclip_proccessors/watermark.rb
module Paperclip
# Handles watermarking images that are uploaded.
class Watermark < Processor
attr_accessor :current_geometry, :whiny, :watermark_path, :watermark_position, :watermark_ratio, :watermark_dissolve
# Adds a watermark object (+watermark_path+) to the +file+ given.
# It creates a dissolved (+watermark_dissolve+) layer at (+watermark_position+) and
# will attempt to transform the watermark to fit a given ratio (+watermark_ratio+).
# Example: A +watermark_ratio+ of 25 with +watermark_position SouthEast will place the
# watermark to the left bottom of the given file and, if needed, shrinks it to maximum 25% of either
# width or height of the file given by keeping its aspect ratio. So it neither crops the watermark
# nor scales it up. For further positioning details see ImageMagick gravity option.
# Watermark creation will raise no errors unless +whiny+ is true (which it is, by default).
def initialize file, options = {}, attachment = nil
super
@file = file
@current_geometry = Geometry.from_file @file
@whiny = options[:whiny].nil? ? true : options[:whiny]
@current_format = File.extname(@file.path)
@basename = File.basename(@file.path, @current_format)
@watermark_path = options[:watermark_path] || File.join(RAILS_ROOT, 'public', 'images', 'watermark.png')
@watermark_position = options[:watermark_position] || 'SouthEast'
@watermark_dissolve = options[:watermark_dissolve] || 30
@watermark_ratio = options[:watermark_ratio] || 25
end
# Performs the composition of the +file+ with the watermark. Returns the Tempfile that contains the new image.
def make
src = @file
dst = Tempfile.new(@basename)
dst.binmode
command = <<-end_command
#{transformation_command}
"#{File.expand_path(src.path)}[0]"
"#{File.expand_path(dst.path)}"
end_command
begin
success = Paperclip.run('composite', command.gsub(/\s+/, ' '))
rescue PaperclipCommandLineError
raise PaperclipError, "There was an error processing the watermark for #{@basename}" if @whiny
end
dst
end
# Returns the command ImageMagick's +composite+ needs to add the watermark to the image.
def transformation_command
watermark_max_width = (@current_geometry.width.to_i * (@watermark_ratio.to_f / 100)).to_i
watermark_max_height = (@current_geometry.height.to_i * (@watermark_ratio.to_f / 100)).to_i
trans = " -dissolve #{@watermark_dissolve} -gravity #{@watermark_position} \\( '#{@watermark_path}' -resize #{watermark_max_width}x#{watermark_max_height} \\) "
end
end
end
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.
Anfang des Jahres hat mich Thomas von PANORAMA3000 für ein Projekt engagiert begeistert, welches sich langsam aber sicher der Public-Beta-Phase nähert.
Du hast ein Talent, vielleicht ein noch verborgenes, mit dem du etwas verdienen möchtest? Du hast Fähigkeiten, die jemand anders gut gebrauchen kann? Dann hör auf zu kellnern und mach die Cocktails einfach selbst.
Auf www.trabayo.com kannst Du Dich bereits jetzt registrieren, um schon bei den ersten Testläufen aktiv dabei zu sein. Neben der Möglichkeit, das Portal konstruktiv mitzugestalten, wirst Du zusätzlich mit einer lebenslangen Premium-Mitgliedschaft belohnt.
Das Projekt ist auch aus Entwicklersicht ein Leckerbissen – Thomas, Marius und Karolin haben neben einem erstklassigen Konzept und einem frischen Blick auf den Status Quo die dazugehörigen Portion Innovationswillen und Mut, um eine solide Entwicklung im Rahmen eines agilen Entwicklungsmodells zu ermöglichen. Eine umfangreiche Test-Suite und Continous-Integration/Release-Management bilden dabei die technische Grundlage für ein tägliches Deployment in ein Multistaging-Environment auf Basis von Phusion Passenger™ und Ruby Enterprise Edition.
Semantic Web als Bestandteil des technischen Kernkonzeptes verspricht eine Menge Abwechslung und spannende Entwicklungsphasen, die weit über das bloße Anwenden der bewährten Ruby-on-Rails-Pattern hinaus gehen.
Das Trabayo-Weblog informiert dabei regelmäßig über interessante Neuigkeiten rund um das Projekt – es lohnt sich!
