Rapid Prototyping einer Web-Anwendung mit Ruby on Rails

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Rapid Prototyping einer Web-Anwung mit Ruby on Rails im Rahmen des Seminars Software Engineering im Wintersemester 2008/2009 Thomas Jansing Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Dipl.-Wirt. Inform. Christian Hermanns Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einleitung Grundlagen von Ruby on Rails Allgemeine Konzepte und Ziele Die Skriptsprache Ruby Das Web-Framework Rails Eigenschaften und Besonderheiten Aufbau des Frameworks RESTful Web-Services Eingesetzte Entwicklungsumgebung Entwurf der Anforderungen Rapid Prototyping mit Ruby on Rails Vorstellung der Web-Anwung Erstellung des Rails Projekts Testen der Funktionalität Web-Services und Routing Erweiterung des Projektes Session-Handling und Benutzerverwaltung Validierung in Modellen Templates und Layout AJAX und Web Versand durch ActionMailer Sicherheitsaspekte Zusammenfasse Betrachtung A Quelltexte Literaturverzeichnis II

3 Kapitel 1: Einleitung 1 Einleitung Die vorliege Ausarbeitung soll eine Einführung in das Web-Framework Rails geben, welches auch synonym als Ruby on Rails bezeichnet wird, da es auf der Skriptsprache Ruby aufbaut. Anhand der Entwicklung einer Beispiel-Web-Anwung sollen die wesentlichen Elemente, sowie deren Vor- und Nachteile vorgestellt werden. Als Beispiel hierfür wurde ein Pizza-Bestell-Service ausgewählt. Die Fokussierung auf Ruby on Rails wurde gewählt, da es sich um ein relativ neues Framework handelt, welches durch die Kombination verschiedener Ansätze versucht das Agile Web Development und speziell das Rapid Prototyping zu unterstützen. Obwohl Ruby on Rails erst 2005 veröffentlicht wurde, wird es bereits in vielen produktiven Umgebungen (z. B. XING.com, Qype.com und Eins.de) eingesetzt und erfreut sich nicht nur aufgrund seiner intuitiven Syntax großen Interesses. Dank der Datenbank- und Plattform-Unabhängigkeit und der Kompatibilität zum Apache- und lighttpd Webserver gewährleistet Ruby on Rails Interoperabilität für alle relevanten Web-Umgebungen. Die zugrunde liege Sprache Ruby ist sowohl Programmier- wie auch Skriptsprache und kann daher die Vorteile von eher prozeduralen/imperativen Skriptsprachen wie dem weit verbreiteten PHP nutzen und dabei trotzdem die Vorteile der Objektorientierung nutzen, da jedes Element in Ruby ein Objekt ist. Ruby positioniert sich technologisch zwischen PHP/Perl auf der einen Seite und Java und C# auf der anderen. Demnach ist Ruby ist vergleichbar mit Python. Das folge Kapitel 2 erläutert die Grundlagen von Ruby on Rails, wie die allgemeinen Konzepte und Ziele (Kap. 2.1), die Sprache Ruby (Kap. 2.2) und das Framework Rails (Kap. 2.3) genauer. Kapitel 2.4 beschreibt die eingesetzte Entwicklungsumgebung, woraufhin in Kapitel 2.5 schließlich die Anforderungen an die Beispiel-Web- Anwung kurz erläutert werden. Kapitel 3 beschäftigt sich mit dem Thema Rapid Prototyping und beginnt nach einer kurzen Beschreibung der Anwung (Kap. 3.1) mit der Erstellung des Beispiel-Projektes (Kap. 3.2). Nachdem die Funktionalität in Kapitel 3.3 gezeigt wurde, wird direkt die einfache Bereitstellung als Web-Service demonstriert (Kap. 3.4). Der erstellte Prototyp wird in Kapitel 4 um Funktionen erweitert, wie ein Login-System (Kap. 4.1), Validierung (Kap. 4.2), angepasste Layouts und Templates (Kap. 4.3), sowie eine AJAX-Live-Suche (Kap. 4.4). Das Kapitel schließt mit der Betrachtung einiger Sicherheitsaspekte in Kapitel 4.6. Die Ausarbeitung et mit einer kritischen Zusammenfassung in Kapitel 5. 1

4 Kapitel 2: Grundlagen von Ruby on Rails 2 Grundlagen von Ruby on Rails 2.1 Allgemeine Konzepte und Ziele Das Web-Framework Ruby on Rails wurde speziell darauf ausgerichtet, den Programmierer beim Rapid Development und im speziellen beim Rapid Prototyping zu unterstützen. Kapitel 3 wird dies exemplarisch zeigen. Ziele des Rapid Development sind u. a. die Entwicklungsdauer und die dabei entstehen Kosten zu senken. Die Programmierer können sich auf die Implementierung der Geschäftslogik konzentrieren und den Nutzern schneller ein lauffähiges System demonstrieren. Dieses soll durch kürzere Entwicklungs-Zyklen erreicht werden und dafür sorgen, dass das Feedback der Nutzer schneller in die Entwicklung einfließt. Dieser Ansatz verspricht mehr Agilität und Flexibilität bei der Entwicklung von Web-Anwungen. Ruby on Rails unterstützt somit das Extreme Programming (XP), indem es erlaubt die gesamte Web-Anwung in kleinen, iterativen Schritten zu entwickeln. So sind jederzeit Änderungen am Datenmodell möglich, ohne die Lauffähigkeit der Anwung zu gefährden [WK07, S. 29]. Weiterhin unterstützt Ruby on Rails Test-driven development (TDD), indem es neben dem lauffähigen Prototyp auch Tests für Modellklassen, Kontroller und Views, sowie eine Fixture-Datei mit Testdaten generiert. In [WB06, Kap. 14] wird dieses ausführlicher besprochen. Beim Anlegen neuer Kontroller werden z. B. automatisch funktionale Tests generiert, so dass bereits vor der ersten Anpassung des Codes die Funktionalität getestet werden kann [WK07, S. 30]. Hierdurch kann mit dem Testen begonnen werden, bevor der erste eigene Code implementiert wird. Ein wichtiger Vorteil der hieraus erwächst ist die Möglichkeit durch das Testen ganz genau das gewünschte Verhalten der Anwung zu spezifizieren und zu verifizieren [WK07, Kap ]. Ruby on Rails folgt strikt dem Model-View-Controller (MVC) Architekturmuster, welches 1979 von Trygve Reenskaug vorgestellt wurde. Dieses Muster hat sich seit langem bewährt und verlangt eine strikte Trennung des Datenmodels (Model), der Präsentationsschicht (View) und der Steuerungsschicht (Controller) voneinander. Die Ziele hierbei sind die Web-Anwung flexibel zu gestalten, um Wiederverwung zur ermöglichen und einen möglichst geringen Pflegeaufwand zu haben, was zu einer geprüften und stabilen Software beitragen soll [Wa08, Kap. 4.3]. Die genaue Umsetzung des MVC-Musters in Rails wird in Kapitel näher vorgestellt. 2

5 Kapitel 2: Grundlagen von Ruby on Rails 2.2 Die Skriptsprache Ruby Die Open-Source Programmiersprache Ruby wurde 1995 von dem Japaner Yukihiro Matsumoto entwickelt und wird bis heute von ihm betreut. Ruby ist eine moderne Objekt-orientierte Skriptsprache und bietet daher Vorteile wie z. B. Modularisierung/Kapselung von Objekten, Vererbung/Spezialisierung und Polymorphismus. Im Gegensatz zu anderen rein Objekt-orientierten Programmiersprachen wie z. B. Smaltalk bietet Ruby darüber hinaus auch Unterstützung für Prozedurale und Funktionale Programmierung. So ist es bspw. nicht notwig seine Programme explizit in einer Klasse zu definieren. Ein Ruby-Programm kann auch lediglich aus Prozeduren oder Funktionen bestehen. Sie unterstützt die dynamische Typisierung währ der Laufzeit (Duck- Typing) und folgt dem sogenannten Principle of least surprise, d. h. dass die Programmiersprache den Programmierer möglichst wenig überraschen sollte und sie intuitiv verstanden werden sollte. Maßstäbe hierfür waren Matsumoto s eigene Erwartungen und Bedürfnisse. Ein positiver Aspekt von Ruby ist daher die gute Lesbarkeit des Codes. Ruby-Syntax ist gut verständlich, da die Programmiersprache sehr an die natürliche menschliche Sprache angelehnt ist. Beispiele hierfür werden in Kap. 3 gegeben. Als ausführliches Nachschlagewerk und Referenz für Ruby sei auf [CR2006] verwiesen. 2.3 Das Web-Framework Rails Eigenschaften und Besonderheiten Rails ist ein Open-Source Projekt und steht unter der MIT-Lizenz [Op08] zur Verfügung. Sie erlaubt eine absolut freie Verwung von Rails. Das Framework wurde von David Heinemeier Hansson entwickelt und, nachdem es 2004 bereits vorgestellt wurde, Ende 2005 in der Version 1.0 freigegeben. Auffällig hierbei ist die Praxisnähe von Rails, da es nicht als theoretisches Framework von Grund auf neu konzipiert wurde, sondern aus den Erfahrungen, Mustern und Teilen der Implementierung der Projektmanagement-Software Basecamp zusammengestellt wurde. Daher berücksichtigt es konkrete Lösungen und erfolgreiche Muster aus einem Praxisprojekt, was wohl auch zu der schnellen Verbreitung von Rails beiträgt [WK07, S. 21]. Eine Besonderheit von Rails ist sicherlich das Paradigma Konvention über Konfiguration, welches immer wieder am laufen Fall-Beispiel verdeutlicht wird. Rails erwartet 3

6 Kapitel 2: Grundlagen von Ruby on Rails vom Entwickler, dass er sich an Namenskonventionen hält, die eine spätere Konfiguration überflüssig machen. Beispielhaft sei aufgeführt, dass Klassennamen immer im Singular erwartet werden, währ die Tabellennamen den Pluralnamen tragen. Sämtliche generierten Dateien folgen diesem Schema. Rails bietet aber auch die Möglichkeit von den Default-Einstellungen abzuweichen [WB06, S. 7 f.; WK07, S.28 f.]. Ein zweites Paradigma von Rails ist das DRY-Prinzip, welches von [TH04] geprägt wurde. DRY steht für Don t repeat yourself und baut auf dem Grundsatz auf, dass Wissen jeweils nur eine einzige und eindeutige Repräsentation in einem Informationssystem haben sollte. Daher sollen weder Daten noch Funktionen redundant gespeichert werden, um den Pflegeaufwand zu reduzieren und mögliche Probleme zu vermeiden. Ein Beispiel hierfür sind die Getter- und Setter-Methoden, welche nicht implementiert werden müssen, da sie gleichartig sind und daher generiert werden können [Vgl. WB06, S. 8]. Besonders erwähnenswert ist die eigentliche Stärke von Rails, die Meta Programmierung. Die automatische Generierung von Programmcode wird bei Ruby on Rails Scaffolding genannt. Mit Hilfe von Scaffold-Generatoren wird direkt zu Beginn ein lauffähiges Gerüst erzeugt, welches bereits grundlege Funktionen zum Erstellen, Anzeigen, Updaten und Löschen von Modellen (CRUD-Funktionen) implementiert. Zusätzlich werden auch die Views erzeugt, die eine Webbrowser-basierte Umsetzung der CRUD-Funktionen ermöglichen. Somit kann sofort ein lauffähiger Prototyp erzeugt werden, welcher als Grundlage für die weitere Entwicklung dient (Rapid Prototyping). Ein Vorteil von Rails ist die Integration und besonders einfache Nutzung des Objektrelationen Mappings (ORM). Im Gegensatz zu anderen Frameworks wie z. B. MyFaces ist bei Rails nur sehr wenig Aufwand hierfür nötig, da durch die Namenskonventionen eine Konfiguration überflüssig ist. Nur Assoziationen zwischen Objekten müssen (noch) manuell implementiert werden. Im Zusammenhang mit dem ORM sind die Datenbank-Migrationsskripte zu nennen. Diese automatisch generierten Skripte gewährleisten eine Kompatibilität zu allen verbreiteten Datenbanken und gestatten somit den Betrieb von Rails mit einer Vielzahl an Datenbanken. Die Migrationen bieten darüber hinaus den Vorteil, dass eine Versionierung von Datenbank-Schemata möglich ist. Es können neue Schemata migriert oder auch auf ältere zurückgekehrt werden. Rails bietet drei verschiedene Umgebungen mit jeweils eigenen Datenbanken. Standard ist die Development-Umgebung, wohingegen die Production-Umgebung für den Produktiv-Einsatz vorgesehen ist. Alle Tests werden in der Test-Umgebung mit Test-Daten 4

7 Kapitel 2: Grundlagen von Ruby on Rails ausgeführt. Diese Trennung der Daten erlaubt bspw. das Testen von Änderungen am Datenbank-Schema, ohne auf Daten der Produktiv-Umgebung zuzugreifen und diese möglicherweise zu verändern oder zu löschen Aufbau des Frameworks Abbildung 1 zeigt die Komponenten von Rails und deren Interaktion sowie die konkrete Umsetzung des MVC-Musters. Der Ruby-Dispatcher im Zentrum erhält vom Web- Server die Anfrage des Clients. Der Dispatcher lädt daraufhin anhand des Routings (config\routes.rb) den entsprechen Controller des ActionController Moduls. Der Controller verwaltet die Anfrage und ruft die entsprechen Methoden des ActiveRecord oder ActiveRessource Moduls auf. ActiveRecord interagiert mit der Datenbank als OR-Mapper und enthält die Logik zur Verwaltung der Daten. ActiveRessource (ab Rails Version 2.0) hingegen ist für RESTful Web-Service-Anfragen und nutzt ActiveRecord als ORM. Die Ergebnisse der Aufrufe werden an den Controller zurückgeschickt und dann vom Controller an das ActionView Modul geset. Das ActionView Modul rert die Ergebnisse und liefert sie an den Client zurück. Abbildung 1: Komponenten von Rails (ab Version 2.x) Zusätzlich können ActionController, ActiveRecord und -Ressource auf ActiveSupport zugreifen, welches Erweiterungen und Hilfsmethoden für Rails implementiert. Daneben 5

8 Kapitel 2: Grundlagen von Ruby on Rails gibt es das ActionMailer Modul, welches den -Versand übernimmt. Alle Action Module werden auch unter dem Begriff ActionPack zusammengefasst RESTful Web-Services Das Representational State Transfer (REST) Architektur-Muster wurde von [Fi00] für verteilte Hypermedia-Systeme, wie z. B. das World Wide Web, beschrieben und wird ausführlich in [Fi00, Kap. 5] behandelt. In den Versionen 1.x von Rails wurde das Modul Action Web Service als Standard für die Bereitstellung von Web-Services vorgesehen. Das Modul bietet Unterstützung für SOAP- und XML-RPC-Zugriffe. Mit der Rails Version 2.0 wurde das Modul durch ActiveRessource ersetzt, welches Web-Services über REST unterstützt. Eine ausführliche Behandlung des Themas ist in [RR07] nachzulesen. Action Web Service kann über RubyGems nachinstalliert werden, aber die Rails Entwickler empfehlen SOAP nicht mehr einzusetzen und REST zu nutzen. Rails 2.0 ist bereits RESTful konzipiert, was bereits beim Prototyping deutlich wird. 2.4 Eingesetzte Entwicklungsumgebung Für die Entwicklung der Beispiel-Web-Anwung wurde als Betriebssystem Windows XP benutzt, so dass bei allen folgen Befehlen in der Eingabeaufforderung ein \ anstelle eines / als Pfadtrenner benutzt wurde. Entsprech der Empfehlung der rubyonrails.com Webseite wurde das Ruby-Paket in der Version RC 1 [Ruby08a] verwet. Nach erfolgter Installation von Ruby ( RubyGems Support und European Keyboard müssen aktiviert werden) wurde mit Hilfe der mitgelieferten RubyGems Paket-Verwaltung das Rails-Paket (Ver ), der SQLite3 Adapter (Ver ) und der Mongrel Web-Server (Ver ) heruntergeladen: gem install rails --version gem install sqlite3-ruby --version gem install mongrel --version Die vorliege Rails Version besitzt leider eine bekannte Inkompatibilität unter Windows XP mit allen MySQL-Servern, daher wurde SQLite3 als Datenbank benutzt. Um SQLite3 zu installieren wurden die Precompiled binaries für Windows heruntergeladen (sqlite-3_6_4.zip und sqlitedll-3_6_4.zip [Sqlite08]) und anschließ in das \bin Verzeichnis der Ruby-Installation extrahiert, damit sie über die PATH- Variable in allen Verzeichnissen ausführbar sind. Für die Integration anderer Datenban- 6

9 Kapitel 2: Grundlagen von Ruby on Rails ken wird jeweils ein Adapter benötigt, welcher auch in der DB-Konfiguration des Projekts angegeben werden muss (config\database.yml). Ausführliche Hinweise zur Installation und Konfiguration von Datenbanken bietet das offizielle Ruby on Rails- Wiki [Ruby08b]. 2.5 Entwurf der Anforderungen Mit Fokus auf das Extreme Programming wird hier auf eine Analyse- und Spezifikations-Phase sowie auf ein Pflichten- und Lastenheft im Sinne des klassischen Software Engineering verzichtet. Es wird direkt mit einer textuellen Formulierung der Anforderungen begonnen, auf deren Basis ein UML-Diagramm (Vgl. Abbildung 2) erstellt wird. Das Projekt pizza-service soll einen Pizza-Bestellservice implementieren. Es soll eine Pizza-Verwaltung (Klasse: Pizza) für einen Admin (Klasse: User), sowie eine grundlege Bestell-Funktionalität (Klasse: Order) für alle Kunden (Klasse: User) erstellt werden. Kunden sollen sich nach einer Registrierung einloggen können, um nicht zu jeder Bestellung nochmals ihre Adresse angeben zu müssen. Außerdem können sie ihr Profil jederzeit ändern. Ein Admin soll sich über einen Login autorisieren und die Pizzen verwalten können. Bestellungen von Kunden werden per an den Lieferservice geset. Weiterhin soll eine Suchfunktion implementiert werden, um nach Pizzen mit bestimmten Zutaten zu suchen. Diese Suchfunktion wird einerseits als RESTful WebService und zusätzlich als AJAX-Live-Suche implementiert. Abbildung 2: Vereinfachtes UML-Diagramm der Beispiel-Web-Anwung Einem User können mehrere Bestellungen zugeordnet werden. Eine Bestellung ihrerseits wird genau einem User zugeordnet und kann aus mehreren Pizzen bestehen. Pizzen können in mehreren Bestellungen enthalten sein. Diese n:m Beziehung wird hierbei durch die Assoziationsklasse Orders_Pizzas abgebildet. Get- und Set-Methoden, sowie IDs und Timestamps sind nicht angegeben, da sie automatisch generiert werden. Die Attribute werden als SQLTypes definiert. 7

10 Kapitel 3: Rapid Prototyping mit Ruby on Rails 3 Rapid Prototyping mit Ruby on Rails 3.1 Vorstellung der Web-Anwung Im Rahmen dieses Kapitels wird das Rapid Prototyping mit Rails verdeutlicht. In diesem Kontext werden Klassen synonym als Modelle und Methoden als Aktionen bezeichnet. In einem ersten Schritt sollen die Modelle erstellt und deren Verwaltung (CRUD-Operationen) in Views ermöglicht werden. Außerdem sollen die Assoziationen der Modelle berücksichtigt werden. Die Funktionalität wird anhand der Ruby-Konsole überprüft. Anschließ wird eine einfache Suchfunktion als WebService implementiert (Kapitel 3). Als zweiter Schritt soll der Prototyp um eine Benutzerverwaltung erweitert werden, um die Bestellung für registrierte Kunden zu vereinfachen und nur einem Admin die Verwaltung von Pizzen zu gestatten. Nachdem die Validierung und das Arbeiten mit Templates gezeigt werden, werden die AJAX-Live-Suche und ein automatischer -Versand implementiert und Sicherheitsaspekte besprochen (Kapitel. 4). Da sich die Ausarbeitung auf die Umsetzung der Anwung konzentriert, wird hier teilweise auf eine komplette Auflistung der Änderungen an den View-Templates verzichtet und auf den Anhang verwiesen. 3.2 Erstellung des Rails Projekts Nachdem die Entwicklungsumgebung in Kapitel 2.4 eingerichtet wurde, wird als erster Schritt das neue Rails Projekt pizza-service erstellt. Dieses geschieht über folgen Befehl in der Eingabeaufforderung in einem beliebigen Verzeichnis: rails pizza-service cd pizza-service Rails erstellt automatisch im Verzeichnis pizza-service eine festgelegte Verzeichnisstruktur (Vgl. Tabelle 1) und erzeugt alle benötigten Dateien, wodurch der grundsätzliche Aufbau der Web-Anwung bereits vorgegeben ist. Dieses reduziert den Einarbeitungsaufwand bei zukünftigen Projekten. Jede Rails-Anwung verwet die gleiche Struktur, wodurch eine spätere Konfiguration, wie im J2EE-Bereich üblich, vermieden wird. Hierbei wird nochmal das Prinzip Konvention statt Konfiguration deutlich. Verzeichnis app Inhalt Alle wichtigen Bestandteile des MVC-Musters: Hilfs-, Kontroller- 8

11 Kapitel 3: Rapid Prototyping mit Ruby on Rails config db doc lib log public script test tmp vor und Modell-Klassen, sowie sämtliche Views (*.html.erb) Konfigurationsdateien (z. B. database.yml) DB-Migrationsskripte, SQLite3 Datenbank-Datei (nach Anlegen) Dokumente, die mit rdocs erstellt wurden Zusätzliche Ruby-Bibliotheken/Erweiterungen Logfiles des WEBrick/Mongrel-Servers Öffentliches Wurzel-Verzeichnis des Web-Servers mit statischen Dateien (z. B. Bilder, JavaScript, CSS,...) Start-Skripte (z. B. Server-Start, DB-Konsole, Generatoren) Test-Skripte, Unit-Tests, Funktionale Tests sowie Integrationstests Temporäre Dateien (z. B. Session-Dateien, Cache-Dateien) Plug-Ins und andere Erweiterungen Tabelle 1: Verzeichnisstruktur einer Rails-Anwung Nun wird das UML-Diagramm (Vgl. Abbildung 2) mit Hilfe des Scaffold-Generators umgesetzt. Die drei Modelle Pizza, Order und User werden erstellt, wobei Rails automatisch sämtliche Controller, Views, Tests und DB-Migrationsskripte erzeugt. Die Assoziationsklasse Orders_Pizzas wird nicht als Modell umgesetzt, sondern später nur als SQL-Tabelle. Die Attribute werden aus dem UML-Diagramm übernommen: ruby script\generate scaffold pizza name:string price:decimal ingredients:string ruby script\generate scaffold order delivery_wish:text ruby script\generate scaffold user name:string address:string zip_code:integer city:string login:string password:string In der eingesetzten Rails-Version ist es (noch) nicht möglich, Assoziationen automatisch zu berücksichtigen. Dazu werden die leeren generierten Klassen wie folgt ergänzt: class Pizza < ActiveRecord::Base # Einer Pizza werden 0..* Bestellungen zugeordnet has_and_belongs_to_many :order Listing 1: app\models\pizza.rb class Order < ActiveRecord::Base # Einer Bestellung werden 0..* Pizzen zugeordnet has_and_belongs_to_many :pizza # Eine Bestellung wird genau einer Person zugeordnet belongs_to :user Listing 2: app\models\order.rb class User < ActiveRecord::Base # Einem User werden 0..* Bestellungen zugeordnet has_many :order Listing 3: app\models\user.rb 9

12 Kapitel 3: Rapid Prototyping mit Ruby on Rails Als nächster Schritt muss das OR-Mapping konfiguriert werden. Durch den Scaffold- Generator sind bereits die DB-Migrationsskripte (db\migrate\*.rb) erstellt worden und beinhalten bereits alle oben angegeben Attribute. Daher müssen sie nur noch an die Assoziationen angepasst werden. Um die Zuordnung der Bestellung zu genau einem User zu ermöglichen, wird deren Primärschlüssel als Fremdschlüssel in der orders- Tabelle gespeichert. Um die many-to-many-beziehung zwischen Bestellung und Pizza abbilden zu können, muss eine neue Tabelle orders_pizzas angelegt werden. Diese Tabelle braucht keinen eigenen Primärschlüssel und beinhaltet nur die beiden Fremdschlüssel, um die Relation abzubilden. Als Konvention für den Namen einer zusätzlichen Tabelle einer many-to-many-beziehung gilt, dass beide pluralisierten Tabellennamen alphabetisch angeordnet und durch einen Unterstrich verbunden werden. class CreateOrders < ActiveRecord::Migration def self.up # Neues Schemata wird migriert create_table :orders do t t.text :delivery_wish t.integer :user_id # Fremdschlüssel wird ergänzt t.timestamps # Hilfstabelle wird angelegt. Keine eigene id. create_table :orders_pizzas, :id => false do t t.integer :order_id # Fremdschlüssel der Bestellungen t.integer :pizza_id # Fremdschlüssel der Pizzen def self.down # Alte Tabellen/Schemata werden gelöscht drop_table :orders drop_table :orders_pizzas # Hilfstabelle entfernen Listing 4: db\migrate\timestamp_create_orders.rb Da die anderen Migrationen nicht geändert werden, kann jetzt die Datenbank aktualisiert werden. Weil SQLite 3 als Datenbank benutzt wird, muss keine Änderung an der Datei config\database.yml vorgenommen werden. Mit dem Rake-Tool können vordefinierte Aufgaben, wie z. B. die Datenbank-Migration ausgeführt werden. Eine komplette Übersicht ist unter [MO08, Kap. 7.11] zu finden. Rake ist daher mit den Tools ant bzw. make zu vergleichen [St08, S. 138]. Folger Befehl migriert das Schemata in die Datenbank: rake db:migrate Die Development-Datenbank-Datei db\development.sqlite3 wird erstellt und vier neue Tabellen werden angelegt. 10

13 Kapitel 3: Rapid Prototyping mit Ruby on Rails 3.3 Testen der Funktionalität Für einen direkten Test der Funktionalität werden die Ruby-Konsole und die Views benutzt. Für das Testen mit Hilfe von Testfällen und Testskripten sei hier auf [WB06, Kap. 14] verwiesen. Als Webserver für die Entwicklung kann der integrierte WEBrick- Server verwet werden. Eine bessere Performance bietet Mongrel, welcher in Produktiv-Umgebungen eingesetzt wird. Das Server-Start-Skript überprüft ob Mongrel installiert ist und startet standardmäßig diesen (andernfalls wird WEBrick gestartet): ruby script\server Unter der URL kann die Startseite des Web-Servers erreicht werden. Da Ruby on Rails als CRUD-Framework ausgelegt ist, sind durch das Scaffolding bereits alle nötigen Views und die gesamte Logik vorhanden, um die drei Modelle zu verwalten. Die Index-Seite für deren Verwaltung ist nach folgem Schema aufgebaut: Als hilfreich zum Testen der der generierten Namen hat sich der Pluralizer [Nu08] erwiesen. Es ist jeweils möglich Instanzen der Modelle anzulegen, anzuzeigen, zu editieren und zu löschen. Über die Ruby-Konsole werden Instanzen von Modellen angelegt, die durch Zuweisungen miteinander assoziiert werden, um die Funktionalität der Assoziationen zu demonstrieren. Zuerst werden über die Konsole drei Pizzen und zwei Kunden angelegt: ruby script\console pizza1 = Pizza.new(:name => "Pizza Margherita", :price => 4.95, :ingredients => "Tomaten, Kaese") pizza2 = Pizza.new(:name => "Pizza Salami", :price => 5.45, :ingredients => "Tomaten, Kaese, Salami") pizza3 = Pizza.new(:name => "Pizza Tono", :price => 5.95, :ingredients => "Tomaten, Kaese, Thunfisch") user1 = User.new(:name => "Max Mustermann", :address => "Hansaring 55", :zip_code => 48143, :city => "Muenster") user2 = User.new(:name => "Peter Muster", :address => "Wolbecker Str. 55", :zip_code => 48143, :city => "Muenster") pizza1.save pizza2.save pizza3.save user1.save user2.save Listing 5: Eingaben in der Ruby-Konsole (1/3) Eine Kontrolle im Webbrowser zeigt, dass alle Instanzen angelegt wurden. Nun wird eine Bestellung erzeugt, die Kunde 1 zugeordnet wird und Pizza 2 & 3 enthält: 11

14 Kapitel 3: Rapid Prototyping mit Ruby on Rails order1 = Order.new(:delivery_wish => "Bitte noch 1 Liter Cola") user1.order << order1 # Bestellung wird User zugeordnet (1:m). order1.pizza << pizza2 #.pizza ist ein Array, wg. n:m Beziehung order1.pizza << pizza3 order1.save Listing 6: Eingaben in der Ruby-Konsole (2/3) Eine Kontrolle der DB-Datei bspw. durch den SQLite3 Manager zeigt, dass die Tabelle oders_pizzas korrekt beide Pizzen der Bestellung zuordnet. Auch der Fremdschlüssel user_id in der Tabelle orders zeigt korrekt die Assoziation mit dem Kunden. Ein letzter Beweis geben folge Ruby-Konsolen-Befehle: bestellung = Order.find(:first) # Suche nach der 1. Bestellung bestellung.user.name # Gibt den Namen des Kunden aus # Alle Pizzen werden ausgelesen und deren Namen angezeigt bestellung.pizza.each { pizza puts pizza.name } Listing 7: Eingaben in der Ruby-Konsole (3/3) Das Anlegen der Pizzen und Kunden ist vollständig im Webbrowser möglich, lediglich bei der Bestellung kann nur der delivery_wish angegeben werden. Damit eine Zuweisung einer Bestellung zu einen Kunden und mehrerer Pizzen zu einer Bestellung möglich wird, werden der OrdersController und die beiden Order-Views new.html.erb und index.html.erb überarbeitet (Vgl. Anhang A). 3.4 Web-Services und Routing Wie in Kapitel bereits erläutert bietet Rails ab der Version 2.0 eine Unterstützung für RESTful Web-Services. Für die Kommunikation zwischen Anwungen wird hierbei das XML-Format unterstützt. Bei dem REST-Architektur-Muster stehen anstelle von Services Ressourcen im Vordergrund, welche durch URLs adressiert und durch HTTP-Requests kontrolliert werden. Ein paar Beispiele zur Verdeutlichung: GET #XML-Darstel. aller Pizzen POST #Erstellt neues Objekt GET #Liefert XML-Objekt(id 1) PUT #Ändert Objekt (id 1) DELETE #Löscht Objekt (id 1) Mit Hilfe der vier HTTP-Requests (POST, GET, PUT, DELETE) können somit CRUD-Operationen durchgeführt werden. Zum Testen der REST-Anfragen empfiehlt sich das Firefox-Plugin RESTTest [Xu08]. Dazu wird die protect_from_forgery Methode im ApplicationController temporär auskommentiert, welche sonst nur 12

15 Kapitel 3: Rapid Prototyping mit Ruby on Rails GET und POST-Anfragen zulässt und PUT und DELETE blockiert. Die durch den Scaffold-Generator erzeugten Controller implementieren RESTful Web-Services bereits über das Routing. Die Datei config\routes.rb ist dabei zentral für das Routing, welches für einen HTTP-Request den verantwortlichen Controller und die auszuführe Aktion auswählt. Die Bereitstellung als Ressource ist bereits über den Eintrag (map.resources :pizzas) implementiert. Der Aufruf ( wird wie (PUT an den PizzasController weitergeleitet und ruft die Aktion edit für das Objekt mit der ID 1 auf. Bei der Erstellung komplexerer RESTful Web-Services sollte auf konsistente Adressierung geachtet werden. Das Projekt wird nun um einen RESTful Web-Service search_all erweitert, der die Zutaten-Spalte der Pizza-Tabelle durchsucht und im PizzasController implementiert wird. Gleichzeitig wird das Routing um den neuen Web-Service ergänzt: # GET /pizzas/search_all # GET /pizzas/search_all.xml def search_all #Suchbegriff wird für die SQL Abfrage mit % = "%#{params[:term]}%" #Suchanfrage wird ausgeführt. SQL-Injection wird = Pizza.find(:all, :conditions => ["ingredients ]) #Rert das Ergebnis nur als XML, kein HTML, kein AJAX respond_to do format format.xml { rer :xml } Listing 8: Neue Methode in: app\controllers\pizzas_controller.rb # map.ressources :pizzas wird geändert in: map.resources :pizzas, :collection => {:search_all => :get} Listing 9: Erweiterung von: config\routes.rb Folge GET-Anfrage eines Webbrowsers bspw. liefert eine XML-Liste aller Pizzen, die Salami als Zutat haben (Web-Server muss neu gestartet werden): SQL-Injection (Vgl. Kap. 4.6) ist hierbei nicht möglich, da die Binding-Funktionalität benutzt wird. Da REST-Anfragen stark sicherheitsrelevant sind, ist eine ausführliche Beschäftigung mit [Ruby08d] anzuraten. 13

16 Kapitel 4: Erweiterung des Projektes 4 Erweiterung des Projektes 4.1 Session-Handling und Benutzerverwaltung Mit Hilfe der Attribute login und password des User-Modells wird nun eine einfache Benutzerverwaltung implementiert. Weiterhin wird dazu der Session-Hash und Flash-Hash benutzt. Der Session-Hash speichert Objekte über mehrere Requests hinweg, und wird als Speicher für den angemeldeten User (bzw. User-Objekt) benutzt. Auf die Objekte wird hierbei mit der session Variable zugegriffen. Der Flash-Hash hingegen speichert Objekte hingegen nur für zwei aufeinander folge Requests und wird für Fehlermeldungen sowie Hinweise und Warnungen verwet. Die Informationen werden hierbei in der flash Variable gespeichert [St08, S.180]. Für die Benutzerverwaltung (Vgl. [St08, Kap ]) wird ein neuer LoginController mit den Aktionen login und logout generiert und angepasst: ruby script\generate controller Login login logout class LoginController < ApplicationController def login session[:user] = nil # User-Objekt und Werte löschen session[:user_id] = nil session[:user_login] = nil # Login-Button löst POST-Request aus if request.post? # Authentifiziere User -> app\models\user.rb user = User.authenticate(params[:login], params[:password]) # Konnte User-Objekt erfolgreich geladen werden? if user!= nil # Wenn ja setze neues Objekt und Werte session[:user] = user session[:user_id] = user.id session[:user_login] = user.login # Hinweis und Redirect flash[:notice] = "Successfully logged in!" redirect_to :controller => "pizzas", :action => "index" else # Fehler bei der Authentifizierung flash[:error] = "Login or passwort are incorrect!" def logout reset_session # Löscht alle Session Objekte des Users Listing 10: app\controllers\login_controller.rb 14

17 Kapitel 4: Erweiterung des Projektes Die eigentliche Authentifizierung soll im Modell geschehen. Daher wird das User- Modell um die Methode authenticate erweitert, die das User-Objekt anhand des login Parameters lädt und das übergebene Passwort mit dem gespeicherten vergleicht: def self.authenticate(login, password) user = self.find_by_login(login) # Lade User-Objekt if user # User-Objekt erfolgreich geladen, prüfe Passwort if user.password!= password user user = nil # Passwort falsch. Gib Fehler zurück (NIL) # Passwort richtig. Gib User-Objekt zurück Listing 11: Neue Methode in: app\models\user.rb Nun kann der Zugriff auf die einzelnen Aktionen der Controller geschützt werden. Dazu werden die Controller um Filter erweitert, die vor (before_filter) oder nach (after_filter) jeder Aktion ausgeführt werden: # Delete ist admin-geschützt, Anzeigen und Anlegen nicht before_filter :admin_logged_in, :only => [:delete, :destroy] # User dürfen nur ihre eigenen Profile ändern before_filter :logged_in, :own_profile,:only =>[:edit, :update] Listing 12: Erweiterung von: app\controllers\users_controller.rb # Delete/Edit sind admin-geschützt, Anzeigen nicht before_filter :admin_logged_in, :only => [:delete, :destroy, :edit, :update] # Um Bestellungen anzulegen muss User eingeloggt sein before_filter :logged_in, :only => [:create, :new] Listing 13: Erweiterung von: app\controllers\orders_controller.rb # Create/Edit/Delete sind admin-geschützt, Anzeigen und Suchen nicht before_filter :admin_logged_in, :except => [:index, :list, :show, :search_all] Listing 14: Erweiterung von: app\controllers\pizzas_controller.rb Die Methoden admin_logged_in, logged_in und own_profile werden im ApplicationController als Private-Methoden implementiert, damit sie über die Vererbung allen Controllern zur Verfügung stehen: private # Überprüft ob User eingeloggt ist def logged_in if session[:user] == nil flash[:error] = "You need to login first!" redirect_to(:action => 'index') 15

18 Kapitel 4: Erweiterung des Projektes private # Überprüft ob User sein eigenes Profil editiert def own_profile if session[:user].id.to_s!= params[:id] flash[:error] = "You can only edit your own profile." redirect_to(:action => 'index') private def admin_logged_in # Überprüft ob user.login = admin logged_in if session[:user]!= nil if session[:user].login.to_s == "admin" flash.now[:notice] = "You have admin rights." else flash[:error] = "You need to have admin rights to use this function." redirect_to(:action => 'index') Listing 15: Neue Methoden in: app\controllers\application.rb Nachdem die generierten Views für den Login und den Logout angepasst wurden (Vgl. Anhang A), steht die Benutzerverwaltung zur Verfügung: # Pizza-Service Startseite # Anmeldeseite # Abmeldung # Registrierung neuer User 4.2 Validierung in Modellen Die Validierungsfunktionalität ist fester Bestandteil von ActiveRecord und findet somit auf Modellebene statt. Es kann entweder eine Klassen-Methode validate in die Modell-Klasse eingefügt werden, um eigene Validierungen zu implementieren, oder auf Standard-Methoden von ActiveRecord zurückgegriffen werden, die als Klassen- Methoden eingefügt werden. Nachfolg wird das Pizza-Modell um verschiedene Validierungen erweitert: # Alle drei Attribute müssen angegeben werden validates_presence_of :name, :price, :ingredients # Das Attribut Name der Pizza soll eindeutig sein validates_uniqueness_of :name # Das Attribut Preis soll positiv sein validates_numericality_of :price, :on => :create, :greater_than => 0, :message => "Price must be > 0." Listing 16: Erweiterung von: app\models\pizza.rb 16

19 Kapitel 4: Erweiterung des Projektes Der Parameter :on definiert wann die Validierung durchgeführt werden soll (hier beim Anlegen) und :message überschreibt die eventuell ausgegebene Fehlermeldung (vor allem bei numerischen Prüfungen wichtig). Als Standard werden die Validationen bei jedem Ändern (:save) des Objekts ausgeführt. Standard-Fehlermeldungen sind bereits definiert. Die Modelle User und Order werden ebenfalls um sinnvolle Validationen erweitert (Vgl. Anhang A). Eine gute Übersicht und Beschreibung aller vorhandenen Standard-Validationen bieten [MR06, Kap ]. 4.3 Templates und Layout Rails verfügt über drei eingebaute Template-Engines, die Teil des ActionView-Moduls sind (ERb-, XML- und Ruby JavaScript-Templates). Anhand der Dateiung erkennt Rails, welche Engine zu wählen ist. Ab Rails 2.0 werden als Standard ERB-Templates (app\views\*\*.html.erb) vom Scaffold-Generator erzeugt. Embedded Ruby (ERb)-Templates sind einfache HTML-Templates mit über Tags eingebettetem Ruby- Code. Tabelle 2 gibt hierüber einen Überblick (Vgl. [MO08, Kap. 8]). Tag Beschreibung <% RUBY_CODE %> Code wird ausgewertet, keine Ausgabe <%- RUBY_CODE -%> Code wird ausgewertet, keine Ausgabe, unterdrückt <br> <%= RUBY_CODE %> Code wird ausgewertet und als String ausgegeben <%=h RUBY_CODE %> Code wird ausgewertet, Resultat wird durch html_escape gefiltert (Vgl. Kap.4.6) <%# RUBY_CODE %> Code wird nicht ausgewertet (Kommentar) Tabelle 2: Tags zum Einbinden von Ruby-Code in ERb-Templates Da nach dem MVC-Muster die Controller die Views steuern, muss zum Rern der Views innerhalb einer Aktion eines Controllers die rer-funktion aufgerufen werden, der als Parameter der Name des Templates übergeben wird. Aufgrund der Namenkonvention wird Rails die Endung.html.erb hinzufügen. Allgemein: Rer :action => Template_name Bei :action stehen dem Controller nur Templates aus dem eigenen Unterordner zur Verfügung. Über :template kann ein relativer Pfad und über :file ein absoluter Pfad zu anderen Templates angegeben werden [MR06, S. 68]. Im Ordner app\views\layouts befinden sich spezielle Templates, die nach dem DRY-Prinzip als gemeinsames Layout für alle Seiten eines Controllers dienen (controller.hmtl.erb). Wird die Datei application.html.erb angelegt, dient diese als 17

20 Kapitel 4: Erweiterung des Projektes Layout für alle Seiten der Anwung. Das Projekt wird um ein gemeinsames Layout erweitert, dass alle Funktionen und Seiten zusammenführt (Vgl. Anhang A). 4.4 AJAX und Web 2.0 Asynchronous JavaScript and XML (AJAX)-Funktionalität ist fester Bestandteil von Ruby on Rails. Hierfür wurden die beiden AJAX-Frameworks Prototype und Script.aculo.us integriert. Eine ausführliche Darstellung von AJAX und den beiden Frameworks wird in [Ga07, Kap.6 & 7] gegeben. Die JavaScript Dateien befinden sich unter public\javascripts und werden in den Views wie folgt eingebunden: <%= javascript_include_tag :defaults %> Dadurch werden alle relevanten JavaScript-Dateien geladen (Prototype, Script.aculo.us, sowie application.js, die selbst erstellte JavaScripts enthält). Diese Skripte können nun in den Views verwet werden um AJAX zu realisieren, wodurch aber eine Vermischung von HTML, Ruby und JavaScript auftritt. Um diese zu vermeiden und einheitlich nur HTML und Ruby-Code zu schreiben, kann der Ruby JavaScript (RJS)- Generator benutzt werden. Dieser übersetzt Ruby-Code zur Laufzeit in JavaScript und ermöglicht eine einheitliche Programmierung in Ruby. Da JavaScript zum View im MCV-Muster gehört, ist es besser, den RJS-Code in Templates auszulagern, die den Namen der aufzurufen Action und die Endung.js.rjs tragen. Nachdem die search_all Methode in Kap. 3.4 bereits als WebService über XML realisiert wurde, wird diese nun um einen HTML-View mit Live-Search-Funktion erweitert, um die einfache Einbindung von AJAX zu demonstrieren: <%# Die AJAX-Suche wird als Partial-View eingebunden %> <%= rer :layout => false, :partial => 'live_search' unless request.xhr? %> <%# Namenskonvention: _live.search.html.erb%> <%# Bei Ergebnisse erzeuge Tabelle%> <div id="live_results"> <% %> <h3>search results</h3> <table width="500" > <tr><th width="200">name</th> <th width="100">price</th> <th width="200">ingredients</th></tr> <% for pizza %> <tr><td><%=h pizza.name %></td> <td><%=h pizza.price %></td> <td><%=h pizza.ingredients %></td></tr> <% %> </table> 18

21 Kapitel 4: Erweiterung des Projektes <% else %><%# Wenn keine Ergebnisse vorliegen %> <h3>no matches found.</h3><% %></div> Listing 17: app\views\pizzas\search_all.html.erb <%# Alle JavaScripte einbinden %> <%= javascript_include_tag :defaults %> <%# Suchfeld %> <% form_tag({:action => 'search_all'}, :method => 'get') do %> <label for='term'>live-search query:</label> <%= text_field_tag :term %> <% %> <%# Währ der Live-Suche erscheint Grafik %> <%= image_tag 'ajax-loader.gif', :id => 'loading', :style => 'display:none' %> <%# Observer überwacht das Suchfeld und führt action aus %> <%= observe_field('term', :url => {:action => 'search_all'}, :with => 'term', :frequency => 1, :update => 'live_results', :before => "Element.show('loading'); Element.hide('live_results')", :complete => "Element.hide('loading');" + visual_effect(:appear,:live_results )) %> Listing 18: app\views\pizzas\_live_search.html.erb def search_all [...] #Rert das Ergebnis respond_to do format if request.xhr? # AJAX Anfrage? -> Layout nicht neu rern rer :layout => false and return format.html # Rert views\pizzas\search_all.html.erb # Falls XML-Anfrage rere XML-Antwort format.xml { rer :xml } # Rert XML Listing 19: Aktualisierte Methode in: app\controllers\pizzas_controller.rb Das zentrale Element hierbei ist der Observer, der bei Änderungen im Suchfeld die Aktion search_all neu ausführt und den DIV-Container live_results aktualisiert Versand durch ActionMailer Damit die Bestellungen auch Beachtung finden, werden sie nach ihrem erfolgreichen Anlegen mit Hilfe des ActionMailer-Moduls per an den admin (bspw. thomas@jansing.de) versandt. Hierzu wird das Model order_mailer generiert: ruby script\generate mailer order_mailer order_ class OrderMailer < ActionMailer::Base # Erbt von ActionMailer def order_ (order, sent_at = Time.now) # Order als Param. 19

22 Kapitel 4: Erweiterung des = 'New = = = = {:order => order} # Order-Objekt wird übergeben Listing 20: app\models\order_mailer.rb respond_to do format # Schicke Bestellung als OrderMailer.deliver_order_ (@order) [...] Listing 21: Erweiterung der Create-Methode in: app\controllers\orders_controller.rb Beim Ausführen der create-methode in OrdersController wird die deliver_order_ -methode von OrderMailer aufgerufen und ihr das Order-Objekt übergeben. Durch die steht es im Template des -Body wieder zur Verfügung, so dass alle Werte der Bestellung eingetragen werden können. Das Template views\orders\order_ .erb befindet sich im Anhang A. Standardmäßig verset ActionMailer s über einen SMTP-Server, dessen Zugangsdaten in der Datei config\environment.rb hinterlegt werden müssen [Ruby08e]. Auch das Versen über smail wird unterstützt. Zum Testen kann aber auch ohne Konfiguration das Versen der im Server-Log überprüft werden. 4.6 Sicherheitsaspekte Nach [Or07, Kap. 11] ist Sicherheit insbesondere bei Web-Anwungen von großer Bedeutung, da diese über das Internet stets öffentlich zugänglich sind. Da der öffentliche Zugang zu bestimmten Dateien auf dem Webserver zwing notwig ist, kann nicht verhindert werden, dass potentielle Angreifer versuchen die Web-Anwung auf Schwachstellen und Sicherheitslücken zu untersuchen. Diese Attacken können auch automatisiert von Skripten durchgeführt werden und versuchen dabei bekannte Sicherheitslücken auszunutzen. Die zwei größten sicherheitskritischen Bereiche sind einerseits SQL-Injection sowie cross-site scripting (XSS). Dazu ergänzen [WB06, Kap. 11.1] noch die für Ruby on Rails-Anwungen kritischen Batch-Updates von Modellen, mögliche unsichere Dateiownloads durch die s_file() Methode und die Direkteingabe einer URL mit ID. Grundsätzlich sollten alle möglichen Benutzer-Eingaben 20

23 Kapitel 4: Erweiterung des Projektes gefiltert und validiert werden und der Output auf unsichere und ungültige Zeichen und oder Informationen überprüft werden ( escape output ). Zur Vermeidung von SQL-Injection sollte nach [WB06, S. 234] bei Datenbankabfragen in der Geschäftslogik nicht der Ruby-Ersetzungsmechanismus #{code} benutzt werden, da dieser die Benutzereingaben ungeprüft in die SQL-Abfrage einsetzen würde: Person.find(:first, :conditions => user = #{params[:user]} + and pw = #{params[:password]} ) Die Eingabe 'OR 1 --' als Passwort, ergibt die SQL-Abfrage: SELECT * FROM persons where user = anyone and pw = 'OR 1 --' Da der letzte Teil des Ausdrucks immer wahr ergibt, liefert die Abfrage immer einen Benutzer zurück, wodurch ein potentieller Angreifer Zugang erhält. Daher sollte entweder die Binding-Funktionalität von Active Record: Person.find(:first, :condition => [ user=? and pw=?, user, pw]) oder die automatisch generierten dynamischen Finder verwet werden: Person.find_by_name_and_pw(user,pw) Zur Vermeidung von XSS empfiehlt [Or07, S. 369 f.] die konsequente Benutzung der html_escape() Methode von Ruby für alle Variablen, die erst bei der Generierung der Views ausgewertet werden. Dadurch werden alle potentiellen tainted variables ausgewertet, bevor der HTML-View gerert wird. Somit kann kein Skript eingeschleust werden. Daher sollten in allen *.html.erb Dateien (View-Vorlagen) die Ruby Variablen %> mit <%= html_escape(@einwert) %> oder kurz %> umschlossen werden (Vgl. Kap. 4.3). Wenn Instanzen von Modellen in Rails erzeugt oder geändert werden, bspw. bei der Registrierung eine Instanz eines neuen User-Modells, sollte immer darauf geachtet werden, dass über den Parameter-Hash params nicht zusätzliche Daten übertragen werden, die nicht explizit im View vorgesehen sind, wie z. B. ein admin-attribut, welches nur in der Logik gesetzt wird. Im entsprechen User-Model können zu schütze Attribute durch attr_protected :attribut gekennzeichnet werden. Diese werden bei Batch-Updates wie new() oder create() nicht aktualisiert, sofern sie nicht explizit in der Geschäftslogik gesetzt wurden [WB06, S. 234 f.]. Einen guten Überblick aller sicherheitsrelevanten Aspekte von Rails 2.0 bietet [We08]. 21

24 Kapitel 5: Zusammenfasse Betrachtung 5 Zusammenfasse Betrachtung Nachdem zuerst die Grundlagen von Ruby on Rails erläutert wurden, wurde im Hauptteil dieser Ausarbeitung gezeigt, wie einfach sich ein Prototyp einer Web-Anwung entwickeln lässt. Im Vergleich zu anderen Web-Frameworks fällt hierbei positiv auf, dass das Paradigma Konvention über Konfiguration viel Konfigurationsaufwand ersparte. Angefangen bei der Entwicklungsumgebung, die schnell aufgesetzt war, wurde dieses insbesondere beim Prototyping sehr deutlich. Das ORM war sofort ohne Anpassungen nutzbar und es müssten nur die Assoziationen eingefügt werden. CRUD- Operationen konnten sofort sowohl im HTML-View als auch als RESTful Web- Services ausgeführt werden. Ein nicht zu unterschätzer Vorteil sind die Namenskonventionen, die dafür sorgen, dass Rails bspw. automatisch die richtigen Templates benutzt oder automatisch dynamische Methoden bereitstellt, wie z. B. die Finder- Methoden (find_by_attribut). Die intuitive Syntax von Ruby erleichtert das Verstehen des Quellcodes enorm und sieht sehr aufgeräumt aus. Grundsätzlich haben Parameter sinnvolle Default-Werte, weswegen sie nicht angegeben/geändert werden müssen. Ruby on Rails ist ein sehr umfangreiches Framework geworden und hat speziell durch die Version 2.0 viele sinnvolle Veränderungen erfahren. Die Validierung im Modell ist einfach und effektiv zugleich, ohne sich um die Darstellung zu sorgen. Nicht unwichtig ist die gute AJAX-Einbindung oder der leichte Versand. Wenn einige sicherheitsrelevante Aspekte beachtet werden kann mit Ruby on Rails eine produktive Umsetzung erfolgen. Als Kritikpunkt ist die fehle eingebaute Lokalisierung anzusehen, die eine Internationalisierung schwierig gestaltet, da diese selbst implementiert werden muss. Ab der Version 2.2 soll Rails eine einfache Lokalisierung enthalten. Außerdem fehlt es im Vergleich zu J2EE-Umgebungen dem Rails Framework sicherlich an Unterstützung durch Hersteller und entsprechen Erweiterungen. Eine Betrachtung des Aspekts Performance überstieg den Umfang dieser Ausarbeitung. Allgemein kann aber die Aussage getroffen werden, dass die Performance im Vergleich zu Java- Umgebungen schlechter ist, da Rails auf einer Interpreter-Sprache basiert. Die Performance ist aber vergleichbar oder sogar besser als bei anderen etablierten Web- Frameworks wie Django (basiert auf Python) oder Symfony (basiert auf PHP). Für eine ausführliche Betrachtung der Performance von Rails sei auf [OR07, Kap 12] verwiesen. Problematisch sind jedoch die schlechte Performance von Rails mit einer Oracle DB [Ruby08c], sowie die Inkompatibilität mit MySQL unter Windows XP (Vgl. Kap 2.4). 22

25 Anhang A: Quelltexte A Quelltexte Um die Umsetzung des Projektes zu dokumentieren, werden hier anhand der Reihenfolge der Ausarbeitung die Quelltexte zu den einzelnen Kapiteln angegeben. Es werden nur veränderte Dateien gelistet, andere nicht gelistete Dateien blieben unverändert. Da einzelne Dateien im Laufe der Ausarbeitung mehrfach verändert wurden, wird jeweils die komplett neue Datei gelistet. Falls nur kleinere Änderungen an großen Dateien vorgenommen wurden wird der unveränderte Teil der Datei mit [...] abgekürzt. Die kompletten Quelltexte und alle Dateien des Projektes sind in dem Archiv RoR_Kapitel4.zip enthalten und stellen die letzte Version des Projekts am Ende des 4. Kapitels dar. Zum Testen der Quelltexte muss eine Entwicklungsumgebung, wie in Kapitel 2.4 beschrieben, eingerichtet werden. Kapitel 3.2: class Pizza < ActiveRecord::Base # Einer Pizza werden 0..* Bestellungen zugeordnet has_and_belongs_to_many :order Listing 22: app\models\pizza.rb class Order < ActiveRecord::Base # Einer Bestellung werden 0..* Pizzen zugeordnet has_and_belongs_to_many :pizza # Eine Bestellung wird genau einer Person zugeordnet belongs_to :user Listing 23: app\models\order.rb class User < ActiveRecord::Base # Einem User werden 0..* Bestellungen zugeordnet has_many :order Listing 24: app\models\user.rb class CreateOrders < ActiveRecord::Migration def self.up # Neues Schemata wird migriert create_table :orders do t t.text :delivery_wish t.integer :user_id # Fremdschlüssel wird ergänzt t.timestamps # Hilfstabelle wird angelegt. Keine eigene id. create_table :orders_pizzas, :id => false do t t.integer :order_id # Fremdschlüssel der Bestellungen t.integer :pizza_id # Fremdschlüssel der Pizzen 23