RESTful Authentication mit Rails 2.0 Tutorial

Seit dem Ruby on Rails 2.0 im Dezember 2007 erschienen ist, hört man in diesem Zusammenhang immer wieder ein Schlagwort: RESTful. Einer der populärsten Erweiterungen für die Authentifizierung ist das Restful Authentication Plugin von Rick Olson, dass auf “acts as authenticated” basiert. Das Plugin bringt genau das mit, was man sich unter einer vollwertigem Registrierung und Authentifizierung vorstellt: Registrierung mit oder ohne Aktivierung sowie An- und Abmeldung mit Cookie oder ohne. Wie man das Plugin einrichtet und konfiguriert, möchte ich in diesem Tutorial erläutern. Vorweg muss ich allerdings anmerken, dass der Großteil dieses Tutorials nicht auf meinem Mist gewachsen ist, sondern auf einem einem Blogeintrag von Ekerete Akpan basiert. Ich hab seinen Beitrag ins deutsche Übersetzt und einige Erweiterungen hinzugefügt. Da ich derzeit intensiv an einer Benutzer-Authentifizierung arbeite, werde ich das Tutorial sukzessive erweitern.

Voraussetzungen
Für die weitere Vorgehensweise wird vorausgesetzt, dass Rails 2.0 installiert ist, ein Projekt vorhanden ist, und das in der Datenbank keine Tabelle “Users” existiert.

Installation
Zunächst muss das Plugin installiert werden. Dafür öffnen wir die Konsolse und wechseln in unser Projekt. Mit dem folgenden Befehl wird das Plugin installiert:

Generator
Das Plugin bringt einen eigenen Generator mit, welcher den Controller, das Model, die Views und einen Observer erstellt. Darüberhinaus passt der Generator auch die routes.rb an, und fügt entsprechende Einträge für den User und Session Controller ein. Der Session Controller kümmert sich um die An- und Abmeldung, während der User Controller die Registrierung übernimmt. Zwei Generatoren stehen zur Auswahl.

Wollen wir einen Registrierung ohne Aktiverung nutzen ist folgender Befehl zu verwenden:

Für eine Registreriung mit Aktivierung verwenden wir folgenden Befehl:

Migration
Als nächstes müssen wir die Datenbank mit der nötigen Tabelle für die Benutzer füttern. Dafür führen wir eine Migration durch:

Ändern der Routes
Damit alle Actions im richtigen Controller landen, müssen wir als nächstes die Routes anpassen. Wir öffnen die Datei config/routes.rb und fügen unsere benötigten Routes ein:

Hier sieht man, dass für eine Actions, die bereits vorhandenen Controller Users und Sessions wiederverwendet werden. Natürlich hätte man hier auch eigene Controller definieren können.

Observer
Für die E-Mail Aktivierung benötigen wir noch einen Observer. Dafür öffnen wir die config/enviroment.rb und fügen innerhalb des Rails::Initializer.run Block den folgenden Observer ein:

E-Mail Versand konfigurieren
Vor Rails 2.0 konnte man eigene Konfigurationen (z.B. für den E-Mail Versand) direkt in die Datei config/environment.rb einfügen. Mit Rails 2.0 gibt es dafür das Verzeichnis config/initializers, in dem Konfigurationsabschnitte abgelegt werden können. Diese werden dann beim Laden eines Plugins automatisch initialisiert. Dies machen wir uns für die E-Mail Konfiguration zu nutzen. Wir erstellen die Datei mail.rb (kann auch jeden anderen Name haben) mit dem folgenden Inhalt:

Die Einstellungen sind wie folgt definiert:
Address: Adresse des SMTP-Servers.
Port: Port des SMTP-Server (i.d.R. 25)
Domain: Domainame mit dem sich Rails authentifiziert
Authentication: Authentifizierungsmethode am SMTP-Server (i.d.R. ‘login’)
User_name: Benutzername des SMTP-Benutzers
Passwort: Passwort des SMTP-Benutzers

Möchte man nicht SMTP, sondern z.B. Sendmail nutzen, reicht die folgende Befehlszeile:

E-Mail Parameter
Für die abschießende Konfiguration müssen wir noch einige Parameter anpassen. Wir öffnen die Datei config/environments/development.rb und fügen die folgende Zeile ein, bzw. passen diese an:

In der Datei config/environments/production.rb ändern wir diese Zeile wie folgt

Anschließend öffnen wir die Datei app/models/user_mailer.rb und ändern dort folgende Einträge wie folgt ab:

Mit dieser Konfiguration läuft die Registrierung sowohl in der Production, als auch in der Develoment Umgebung. Den Parameter SITE_URL muss man natürlich seinen Gegebenheiten entsprechend anpassen. Die eigentliche Konfiguration ist damit abgeschlossen.

Möchte man Änderungen an den beiden E-Mail Templates durchführen, findet man die Vorgaben in der Datei app/views/user_mailer/activation.html.erb und app/views/user_mailer/signup_notification.html.erb.

Nach der durchgeführten Installation und Konfiguration sollte man auf jeden Fall den Webserver neu starten.

Nach der Installation
Wie geht uns nun weiter? Nach der Installation steht uns unter http://localhost:3000/signup die Registrierung zur Verfügung. Unter http://localhost:3000/login kann sich der registrierte Benutzer anmelden. Mit dem Aufruf von http://localhost:3000/logout meldet sich der Benutzer ab.

Arbeiten mit Authentifizierung
Damit uns die Authentifizierung in unserer gesamten Anwendung zur Verfügung steht, nehmen wir aus der Datei controllers/sessions_controller.rb die Zeile:

und fügen sie in die Datei controllers/application.rb ein. In der Datei controllers/users_controller.rb können wir anschließend den Eintrag ebenfalls entfernen. Damit stehen uns alle Funktionen des Plugins in unserer kompletten Anwendung zur Verfügung. Darin enthalten ist u.a. die Funktion logged_in?, mit der wir prüfen können, ob ein Benutzer eingeloggt ist. So könnte z.B. der Login-Dialog wie folgt aussehen:

Authentifizierung
Der Sinn eines solchen Systems ist ja, bestimmten Content nur authentifizierten Benutzern zugänglich zu machen. Deshalb müssen wir unsere Controller mit entsprechenden Aufrufen ausstatten, so dass sie auch nur angemeldete Benutzer “rein” lassen. Hierfür können wir sog. before_filter benutzten. Wollen wir einen bestimmten Bereich unserer Anwendung schützen, fügen wir einfach den Aufruf

in den Controller ein. Ruft ein nicht angemeldeter Benutzer nun die entsprechende Seite auf, wird er automatisch auf die Login-Seite weitergeleitet.

In einigen Situationen kann es vorkommen, dass nicht alle Actions eines Controllers eine Authentifizierung benötigen. Möchten wir nur bestimmte Actions schützen, können wir diese ebenfalls im before_filter angeben:

In diesem Beispiel benötigen nur die Actions edit und update eine Authentifizierung. Alle anderen Actions können ohne Anmeldung aufgerufen werden.