今回は Textual Modeling Framework を使って DSL エディタを実装します。

最初に DSL の仕様を以下のように定めておきます。

• Windows の INI ファイルなどで利用されている name = value 形式のテキストフォーマットであること
• value には文字列または他の name の参照を記述できること
• + 演算子によって複数の要素を連結できること

この DSL の使用例は以下のようになります。

foo = "AAA"
bar = "BBB"
baz = "CCC"
qux = foo + bar + baz   // "AAABBBCCC"

Xtext プロジェクトの作成

それではプロジェクトを作成してみましょう。新規作成ウィザードで [Xtext Project] を選択し、作成するプロジェクトの情報を以下のように入力します。

作成されるプロジェクトと役割は以下のとおりです。

DSL のグラマーを定義する

続いて DSL のグラマー (文法) を定義します。Textual Modeling Framework (以下、TMF) はグラマーの定義を起点としてレキサやパーサ、エディタといったさまざまな種類のコードを生成します。

グラマーは jp.iteman.mydsl/src/jp.iteman/MyDsl.xtext で定義します。今回の DSL のグラマーは以下のとおりです。

jp.iteman.mydsl/src/jp.iteman/MyDsl.xtext

grammar jp.iteman.MyDsl with org.eclipse.xtext.common.Terminals

generate myDsl "http://www.iteman.jp/MyDsl"

Ini :
    (configurations+=Config)+;

Config :
    name=ID '=' value=Expression;

ConfigRef :
    ref=[Config] | value=STRING;

Expression :
    TerminalExpression ({Operation.left=current} op='+' right=Expression)?;

TerminalExpression returns Expression:
    '(' Expression ')' | {MethodValueLiteral} value=ConfigRef;

ノート: グラマー言語については「Xtext User Guid」の「2. The Grammar Language」をご覧ください。

DSL エディタを生成する

以上でグラマーの定義が完了し、エディタを生成できるようになりました。TMF は Modeling Workflow Engine (MWE) を使用してコード生成を行います。jp.iteman.mydsl/src/jp.iteman/GenerateMyDsl.mwe はコード生成のための MWE の定義ファイルです。

jp.iteman.mydsl/src/jp.iteman/GenerateMyDsl.mwe を右クリックし、[Run As] -> [MWE Workflow] をクリックすることでコード生成が行われます。このときコンソールビューにはコード生成の進行状況が表示されます。

DSL エディタを実行する

それではエディタを動かしてみましょう。最初に [Run] メニュー -> [Run Configurations...] をクリックします。次に Eclipse Application を作成し、[Run] ボタンで実行します。以上の操作で現在開発しているプラグインの実行用 Eclipse が起動します。

起動した Eclipse で適当なプロジェクトを作成し、拡張子が .mydsl のファイルを作成すると、自動生成されたエディタが起動します。

スクリーンショットからは、文字列の強調表示、入力の補完、アウトラインビューといったエディタに必要な機能が一通り揃っていることがわかります。もちろん、追加のコードを書くことでエディタの振る舞いを拡張することも可能です。

言語ワークベンチとしての TMF

筆者は Eclipse でテキストエディタを実装したことがありますが、これだけの機能を持つエディタを実装するのは簡単ではありません。TMF はグラマーを定義するだけでそれを生成することができます。TMF は外部 DSL エディタの実装コストを大幅に下げることができるものである、と言えるでしょう。

では、TMF を 言語ワークベンチ として評価するとどうでしょうか？

Martin Fowler 氏は記事「言語ワークベンチ」で 言語ワークベンチ の必要条件を以下のようにまとめています。

• ユーザが自由に新しい言語を定義できる。言語はそれぞれ完全に統合可能である。
• 一次情報ソースは、永続化された抽象形(persistent abstract representation)である。
• 言語設計者は、スキーマ、エディタ、ジェネレータの3つの部分に分けてDSLを定義する。
• 言語ユーザは、投影エディタ(projectional editor)でDSLを操作する。
• 言語ワークベンチは、不完全だったり矛盾だったりする情報を抽象形に永続化できる。

これらのうち 一次情報ソースは、永続化された抽象形(persistent abstract representation)である。 という点を TMF は明らかに満たしていません。

TMF の 1 次情報ソースは、テキスト表現の DSL スクリプトそのものであり、永続化された抽象形ではありません。言語ワークベンチ のスキーマはこの抽象形に対するグラマーを指しますが、TMF のスキーマはテキスト表現の DSL スクリプトに対するグラマーです。

ノート: ここでいう抽象形とは、DSL の AST あるいはセマンティックモデルを指していると考えられます。なお、TMF の抽象形は EMF モデルです。

ノート: JetBrains の Meta Programming System (最近 1.0 がリリースされました！) に関する記事 InfoQ: JetBrains のメタプログラミングシステムは言語指向プログラミングと DSL をサポート で、1 次情報ソースが永続化された抽象形でないことの欠点について、開発チームを率いている Konstantin Solomatov 氏の見解を読むことができます。

よって、TMF は 言語ワークベンチ の定義を満たしているとは言えません。これは大きな欠点でしょうか？

幸いにも Eclipse にはモデリングフレームワーク Eclipse Modeling Framework (EMF) と、それを基盤とするグラフィカルなモデリングフレームワーク Eclipse Graphical Modeling Framework (GMF) があります。

GMF は、グラフィカルな DSL エディタを作成するために使うことができますが、ここで中心となるのは DSL の抽象形であるセマンティックモデル (ドメインモデル) となります。GMF でエディタを生成するためのワークフローを見てください。

ノート: Piece Framework のプロダクト Piece_IDE にはグラフィカルなエディタでページフローを編集する機能があります。これは GMF ベースの DSL エディタの実例です。

GMF では抽象形および保存形として EMF モデルが使用されます。よって、GMF の 1 次情報ソースは永続化された抽象形です。そして TMF (Xtext) には EMF のリソース API が実装されており、動的または静的にテキストモデルと EMF モデルを相互変換することができます。

このことは TMF 単体では言語ワークベンチを構成できませんが、EMF モデルを起点にすることで GMF と TMF を統合できる可能性を示しています。

これが可能だとしたら TMF + GMF で言語ワークベンチを構成することができるでしょう。例えば、永続化された EMF モデルを TMF ベースのエディタで編集したり、GMF ベースのグラフィカルなエディタで編集する、そしてお互いの変更をリアルタイムに反映する、といったことが可能になるでしょう。

アイテマンでは、これらを実現するための具体的なアーキテクチャに関する調査を続けています。何か進展がありましたらブログでお伝えしたいと思います。

おわりに

DSL はドメインの可変点を表現し、具体的なシステムを発注するための指示書です。DSL のための環境である 言語ワークベンチは、ビジネスの現場で求められる継続的で進化的なプログラミングプラットフォームとして大きな可能性を秘めています。これは、従来のシステム開発のあり方を大きく変えるものになるかもしれません。TMF (そして GMF) を使うことで、そのような新しい世界の一端を垣間見ることができるでしょう。

使用したソフトウェアのバージョン

参考文献

• Martin Fowler's Bliki in Japanese - 言語ワークベンチ
• Xtext User Guide
• Xtext

今回は 言語ワークベンチ として Textual Modeling Framework を使って DSL エディタの実装にチャレンジします。

DSL は特定の知識分野 (ドメイン) 向けに設計されたコンピュータ言語であり、日本語では「ドメイン特化言語」あるいは「ドメイン固有言語」と呼ばれています。

DSL の熱心な支持者である Martin Fowler 氏は記事「言語ワークベンチ」で、DSL を 外部 DSL と 内部 DSL に分類しています。

外部 DSL はアプリケーションを書くためのプログラミング言語 (ホスト言語) とは異なる言語で書かれた DSL です。これに対して、内部 DSL はホスト言語と同じ言語で書かれた DSL です。

同記事に書かれているように、外部 DSL と内部 DSL には長所と短所があります。筆者なりに以下にまとめてみました。

内部 DSL はホスト言語の制約を受けるため表現力には限界がありますが、ホスト言語とリンクしており言語設計にホスト言語の機能を活用することができます。これによって DSL 処理系の実装を低コストで行うことができます。しかし、DSL 処理系の実装が不要になるわけではありません。内部 DSL は DSL なのでホスト言語および周辺ツールはその DSL のことを知りません。よってそのサポートは限定的です。

ノート: 流れるようなインターフェイス はツールによるホスト言語用のサポートを最大限に活用するための内部 DSL といえます。

外部 DSL には表現上の制約がないため、そのドメインに最適な言語を提供できる可能性があります。内部 DSL と比較すると処理系の実装は高コストです。ツールによるサポートは絶望的であり、この部分の開発は間違いなく高コストになるでしょう。

しかし、言語ワークベンチ の登場によりこの状況に変化が生まれています。言語ワークベンチ は DSL の処理系の大部分を自動生成することができます。同時に DSL エディタの自動生成により手厚いツールサポートの提供を可能にします。

今回は Eclipse の Textual Modeling Framework による DSL エディタの実装を通して、言語ワークベンチ がもたらすものを体験したいと思います。

DSL 処理系のプロセスフローを知る

DSL エディタの実装に入る前に、DSL 処理系のプロセスフローを見てみましょう。

DSL はコンピュータ言語なので、プログラムから利用できる形である 抽象構文木 (AST: Abstract Syntax Tree) に変換しなければなりません。これは レキサ (字句解析器) と パーサ (構文解析器) の仕事です。

レキサとパーサによって変換された AST は ジェネレータ によって、セマンティックモデル のオブジェクトやクラスなどに変換されます。セマンティックモデルは ドメインモデル でありそのオブジェクトやクラスはそれぞれ DSL の動的および静的な表現です。

DSL のグラマー (文法) を読み込んで パーサ を生成するのは パーサジェネレータ の仕事です。

ノート: パーサジェネレータにはレキサを生成するものがあります。今回使用する ANTLR もそのひとつです。

以下は DSL 処理系の実装プロセスの例です。

1. ホスト言語から使うことができるパーサジェネレータを選定する
2. DSL のグラマーを設計する
3. パーサジェネレータでパーサ (およびレキサ) を生成する
4. ジェネレータ、セマンティックモデルを実装する

TMF

TMF は Eclipse Modeling Project 傘下のプロジェクトのひとつで、テキストベースのモデリングフレームワークです。TMF の根幹となるフレームワークは Xtext です。この Xtext はもともと openArchitectureWare で開発されていましたが、Eclipse に寄贈され、現在は TMF のプロジェクトの一環として開発が進められています。

ここで、先ほどの図に TMF を加えて、一般的な DSL 処理系と TMF を加えた処理系を比較してみましょう。

TMF の最大の特徴は Xtext ファイルから DSL 専用のエディタを生成できることです。また、パーサも自動生成されるため、DSL 処理系の実装コストは大幅に削減されます。つまり、これらの特徴は外部 DSL の問題を解消します。

Xtext ファイルはエディタのための文法ファイルであり、このファイルを起点として、いろいろなプログラムが生成されます。

パーサジェネレータは自由に選択することができますが、実際にはインタフェースが用意されている ANTLR か PackratParser がよいでしょう。Xtext では ANTLR が推奨されています。

また、ジェネレータも生成されます。これは一見すると便利ですが、生成されたコードは EMF や Xtext に依存しているため、Java 以外のホスト言語で DSL 処理系を構築する場合に応用が難しいという問題があります。

TMF のインストール

それでは TMF をインストールしましょう。TMF は Eclipse Modeling Tools に含まれているので、以下のサイトからダウンロードして利用することにします。

http://www.eclipse.org/downloads/

tar xvzf eclipse-modeling-galileo-incubation-linux-gtk.tar.gz

次にパーサジェネレータである ANTLR と、ANTLR を Xtext から利用するためのプラグインをインストールします。これらは以下の更新サイトからインストールすることができます。

http://download.itemis.com/updates

おわりに

今のところ TMF はインキュベーションの段階であり、まだまだこれからのプロジェクトです。しかし、グラマーを定義するだけで専用のエディタを生成できることに、筆者は大きな魅力と可能性を感じています。

次回は、TMF を使って、DSL を定義し、その DSL 専用のエディタを生成したいと思います。

使用したソフトウェアのバージョン

参考文献

• Martin Fowler's Bliki in Japanese - 言語ワークベンチ
• Martin Fowler's Bliki in Japanese - ドメイン特化言語
• 第9章 速習yacc
• Xtext User Guide

ポテトバーガー注文アプリケーションが RESTful であれば、サーバの実装を変更することなくクライアントの実装が行えるはずです。このことを確認するために今回は JavaScript によるクライアントを実装したいと思います。

まず、実装するクライアントの仕様を考えます。1 から実装するのは大変なので、基本的にユーザインタフェースはこれまでに実装したものを流用し、最後の確認を JavaScript の confirm 関数で行うことにします。具体的な仕様は以下のとおりです。

• ユーザインタフェースはポテトバーガー注文アプリケーションの HTML を流用する
• 確認は JavaScript の confirm 関数を使用する
• 各メニューの表現として マイクロフォーマット を使用する
• JavaScript のライブラリとして jQuery を使用する

ファイル構成は以下のとおりです。

マイクロフォーマット

これまでに実装したビューにはメニューの ID や名称に対して明確なマークアップがなされておらず、このままではクライアントからの操作は困難です。この問題を解決するために マイクロフォーマット を使うことができます。

マイクロフォーマット とは人が読んで理解できる情報にマークアップを付加する手段です。マイクロフォーマット を使用することにより、ドキュメントに埋め込まれたデータに対するソフトウェアからの操作がより簡単になります。

カレンダーや住所など扱う情報の種類毎に マイクロフォーマット の仕様が策定されています。今回はメインメニューとサイドメニューの商品を表現するために、製品情報用の マイクロフォーマット である hProduct を採用することにします。

それでは hProduct に従って、メインメニュー、サイドメニュー、確認ページのテンプレートを変更しましょう。

app/views/orders/main_menu.html.erb

<span id="content">
  <h3>ご注文は何になさいますか？</h3>
  <%= error_messages_for :order %>
  <ul class="hlisting">
    <li class="hproduct">
      <div class="fn" style="display: none">ジャーマンポテトバーガー</div>
      <div class="price" style="display: none">650</div>
      <div class="identifier" style="display: none">
        <span class="type">model</span>
        <span class="value">1</span>
      </div>
      <%= link_to 'ジャーマンポテトバーガー (650円)', "#{orders_path}/order/side_menu?main=1", :class => 'url' %>
    </li>
    <li class="hproduct">
      <div class="fn" style="display: none">ポテトコロッケバーガー</div>
      <div class="price" style="display: none">600</div>
      <div class="identifier" style="display: none">
        <span class="type">model</span>
        <span class="value">2</span>
      </div>
      <%= link_to 'ポテトコロッケバーガー (600円)', "#{orders_path}/order/side_menu?main=2", :class => 'url' %>
    </li>
    <li class="hproduct">
      <div class="fn" style="display: none">肉じゃがバーガー</div>
      <div class="price" style="display: none">700</div>
      <div class="identifier" style="display: none">
        <span class="type">model</span>
        <span class="value">3</span>
      </div>
      <%= link_to '肉じゃがバーガー (700円)', "#{orders_path}/order/side_menu?main=3", :class => 'url' %>
    </li>
  </ul>
</span>

app/views/orders/side_menu.html.erb

<span id="content">
  <h3>サイドメニューは何になさいますか？</h3>
  <%= error_messages_for :order %>
  <ul class="hlisting">
    <li class="hproduct">
      <div class="fn" style="display: none">フライドポテト</div>
      <div class="identifier" style="display: none">
        <span class="type">model</span>
        <span class="value">1</span>
      </div>
      <%= link_to 'フライドポテト', "#{orders_path}/order/confirmation?main=#{@order.main}&side=1", :class => 'url' %>
    </li>
    <li class="hproduct">
      <div class="fn" style="display: none">ポテトサラダ</div>
      <div class="identifier" style="display: none">
        <span class="type">model</span>
        <span class="value">2</span>
      </div>
      <%= link_to 'ポテトサラダ', "#{orders_path}/order/confirmation?main=#{@order.main}&side=2", :class => 'url' %>
    </li>
    <li class="hproduct">
      <div class="fn" style="display: none">スイートポテト</div>
      <div class="identifier" style="display: none">
        <span class="type">model</span>
        <span class="value">3</span>
      </div>
      <%= link_to 'スイートポテト', "#{orders_path}/order/confirmation?main=#{@order.main}&side=3", :class => 'url' %>
    </li>
  </ul>
</span>

app/views/orders/confirmation.html.erb

<h3>注文内容は以上で宜しいですか？</h3>
<ul class="hlisting">
  <li id="main" class="hproduct">
    <div class="fn"><%=h @main %></div>
    <div class="identifier" style="display: none">
      <span class="type">model</span>
      <span class="value"><%=h @order.main %></span>
    </div>
  </li>
  <li id="side" class="hproduct">
    <div class="fn"><%=h @side %></div>
    <div class="identifier" style="display: none">
      <span class="type">model</span>
      <span class="value"><%=h @order.side %></span>
    </div>
  </li>
</ul>
<div>小計： <%=h @price %>円</div>

<% form_for(@order) do |f| %>
  <%= f.hidden_field :main %>
  <%= f.hidden_field :side %>
  <%= link_to_function 'OK', "document.forms[0].submit()" %> 
  <%= link_to '選びなおす', "#{orders_path}/order/main_menu" %>
<% end %>

各 HTML 要素に追加された class 属性によって商品の名称や価格が定義されているのがおわかりいただけると思います。これらのテンプレートに加えられた変更はポテトバーガー注文アプリケーションのビューに何ら影響を与えていないことに注意してください。

クライアントの実装

続いて、クライアントを実装しましょう。今回は public/order.html に直接実装を行うことにします。

public/order.html

<!DOCTYPE html "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type" content="text/html; charset=utf-8"/>
  <title>ポテトバーガー注文アプリケーション</title>
  <script type="text/javascript" src="javascripts/jquery/jquery-1.3.2.js"></script>
  <script type="text/javascript" src="javascripts/jquery/jquery.order.js"></script>
  <script type="text/javascript" src="javascripts/jquery/jquery.hproduct.js"></script>
  <script type="text/javascript">

$(document).ready(function() {
  $.ajaxSetup({
    error: function(xhr) {
      if (xhr.status != '400') {
        alert('予期しないエラーが発生しました');
      }
      show(xhr.responseText);
    }
  });

  $.getMainMenu({
    url: '/orders/order/main_menu',
    success: show
  });
});

function show(html) {
  $('#content').remove();
  $(html).appendTo('body');

  $('.hlisting .hproduct .url').each(function() {
    $(this).click(selectMenu);
  });

  $('a').each(function() {
    $(this).click(function() {
      if (this.href.match(/.+main_menu/)) {
        location.reload();
        return false;
      }
    });
  });
}

function selectMenu() {
  if (this.href.match(/.+side_menu.+/)) {
    $.getSideMenu({
      url: this.href,
      success: show
    });
  } else if (this.href.match(/.+confirmation.+/)) {
    $.isValid({
      url: this.href,
      success: confirmOrder
    });
  }

  return false;
}

function confirmOrder(html) {
  if (confirm("注文内容は以上で宜しいですか？\n" +
              "メインメニュー : " + $(html).find('#main').getProductName() + "\n" +
              "サイドメニュー : " + $(html).find('#side').getProductName()
              )) {
    $.order({
      authenticityToken: $(html).getAuthenticityToken(),
      main: $(html).find('#main').getProductId(),
      side: $(html).find('#side').getProductId(),
      success: show
    });
  }
}

  </script>
</head>
<body>
</body>
</html>

Ajax による通信や hProduct で表現された情報にアクセスする部分は jQuery のプラグインとして実装しているため、order.html にはページで実行されるコードのみを配置しています。

最初に order.html がロードされると $(document).ready が実行されます。ここで Ajax 通信のエラー処理を設定し、メインメニューを取得しています。

show 関数はそれぞれのビューを正常に取得できた時に実行されます。取得した HTML を表示し、各商品のリンクがクリックされたときに実行されるイベントをフックします。今回はユーザインタフェースを流用しているので、このような処理を行っていますが、クライアントを 1 から実装する場合には独自のリンクやボタンを用意することになるでしょう。

selectMenu 関数はメインメニュー、サイドメニューが選択されたときに実行される関数です。リンクの URI から次に行う処理を判断しています。

confirmOrder 関数は confirm 関数による最終確認と注文のリクエストを送信しています。

次に jQuery を使ったサーバとの通信部分を見てみましょう。この部分は jQuery のプラグインとして実装しています。

public/javascripts/jquery/jquery.order.js

getHTML = function(config) {
  config = $.extend({
    url: null,
    success: null
  }, config);

  $.ajax({
    url: config.url,
    type: 'GET',
    dataType: 'html',
    success: config.success
  });
}

jQuery.extend({
  getMainMenu: getHTML,
  getSideMenu: getHTML,
  isValid: getHTML,
  order: function(config) {
    config = $.extend({
      authenticityToken: null,
      main: null,
      side: null,
      success: null
    }, config);

    $.ajax({
      url: '/orders',
      type: 'POST',
      data: {
        'authenticity_token' : config.authenticityToken,
        'order[main]': config.main,
        'order[side]': config.side
      },
      dataType: 'html',
      success: config.success
    });
  }
});

jQuery.fn.extend({
  getAuthenticityToken: function() {
    var authenticityToken;
    $(this).find('input').each(function() {
      if (this.name == 'authenticity_token') {
        authenticityToken = this.value;
        return false;
      }
    });
    return authenticityToken;
  }
});

getMainMenu, getSideMenu, isValid メソッドはすべて getHTML 関数を呼び出しています。order.html から getHTML を直接呼び出しても動作しますが、「何を取得しているのか」という意図を明確にするためにあえてメソッドを用意しました。

最後に hProduct で表現された情報へアクセスする部分を見てみましょう。この部分も jQuery のプラグインとして実装しています。これらのメソッドは自身を起点に製品の ID または名称をそれぞれ取得します。

public/javascripts/jquery/jquery.hproduct.js

jQuery.fn.extend({
  getProductId: function() {
    return $(this).find('.identifier').find('.value').text();
  },
  getProductName: function() {
    return $(this).find('.fn').text();
  }
});

以上で実装は完了です。http://localhost:3000/order.html にアクセスして、正常に動作することを確認しましょう。また、http://localhost:3000/orders/order/main_menu にアクセスして、これまでの実装も変わりなく動作することも確認しましょう。

Rails の CSRF 対策

CSRF (Cross Site Request Forgeries) は、正規のアカウントを保持するユーザに、仕掛けを埋め込んだ Web ページを閲覧させ、掲示板の書き込みやショッピングサイトでの購入といったユーザが意図しない処理を実行させる攻撃手法です。CSRF に対して、Rails はどのような対策を行っているのでしょうか？

Rails のドキュメント「Ruby On Rails Security Guide」の「3.1 CSRF Countermeasures」の最初の一文には W3C が提案する CSRF 対策が書かれています。

-- First, as is required by the W3C, use GET and POST appropriately. Secondly, a security token in non-GET requests will protect your application from CSRF.

これによると、HTTP メソッドの適切に利用し、GET (情報の取得) 以外の処理ではセキュリティトークン (ワンタイムトークン) を利用することが推奨されています。

HTTP メソッドの適切な利用については REST アーキテクチャスタイルに従って実装することで対応できるため、ここではセキュリティトークン (ワンタイムトークン) について考えてみたいと思います。

Rails は、自動的にセキュリティトークン (ワンタイムトークン) の発行・処理を行います。以下は確認ページのテンプレートのフォームと実際にブラウザで表示されたフォームです。

app/views/orders/confirmation.html.erb

...
<% form_for(@order) do |f| %>
  <%= f.hidden_field :main %>
  <%= f.hidden_field :side %>
  <%= link_to_function 'OK', "document.forms[0].submit()" %> 
  <%= link_to '選びなおす', "#{orders_path}/order/main_menu" %>
<% end %>

ブラウザで表示されたフォーム

...
<form method="post" id="new_order" class="new_order" action="/orders">
  <div style="margin: 0pt; padding: 0pt;">
    <input type="hidden" value="ppxvv0wTBg0UZXerjs0nm30yeLmMuhObFhbHZImiGMI=" name="authenticity_token"/>
  </div>
  <input type="hidden" value="2" name="order[main]" id="order_main"/>
  <input type="hidden" value="3" name="order[side]" id="order_side"/>
  <a onclick="document.forms[0].submit(); return false;" href="#">OK</a> 
  <a href="/orders/order/main_menu">選びなおす</a>
</form>
...

authenticity_token フィールドがランダムな値で自動的に生成されていることがわかります。他のフィールドといっしょにこの値が POST されなければ、Rails は以下のエラーを出力します。

ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):

REST の観点から見た場合、このような対策は問題ないでしょうか？

セキュリティトークン (ワンタイムトークン) は複数のリクエストにまたがって管理されなければならないためステートレスな振る舞いとはいえません。Rails はこの点について、セッションをクッキーに保存することで折り合いを付けているように思えます。リクエストごとにクッキーに保存されたセッションが送信されるため、各リクエストは独立している、つまりステートレスであるというわけです。

セッションの保存先を ActiveRecord にした場合はこの理屈は通らなくなりますが、Rails のソリューションは CSRF 対策と REST との間で適切なものだと思います。

Rails を使ってみて

今回はポテトバーガー注文アプリケーションのクライアントを JavaScript で実装しました。ユーザインタフェースを流用したため、テンプレートは変更しましたが、コントローラやモデルは一切変更する必要がありませんでした。従って、ポテトバーガー注文アプリケーションは RESTful な Web アプリケーションとして実装できたのではないかと思います。

最後に Rails に対する筆者の感想をまとめます。

わかりやすい規約

Convention Over Configuration (CoC) による規約は違和感のない非常にわかりやすいものでした。始めて使うフレームワークなので、どういったメソッドを使えば良いかという点ではいろいろ悩みましたが、意図が断絶していてわかりにくい部分はありませんでした。

データベースマイグレーションは便利

アプリケーションの開発・運用においてデータベースの変更は避けては通れません。データベースに対して行った履歴を保存することができ、変更をロールバックできるこの機能はプロジェクトに従事する者に心強い味方になるでしょう。

Scaffolding は便利

初学者にとって Scaffolding は非常に便利な機能でした。Scaffolding が作成するコードは実際に動作するリファレンスとしても価値があると思います。

「設計の可視化」という観点がない

「設計の可視化」は主に IDE がカバーする領域ですが、フレームワーク側にこれを意識した実装があることが前提となります。Rails の IDE としては RadRails が有名ですが、残念ながら Rails にも RadRails にも「設計の可視化」には重点がおかれていないようです。

今回で Rails のチャレンジは終了です。Rails を中心に REST や マイクロフォーマット などさまざまな技術を見ることができ、今までのチャレンジの中で一番濃い内容になったのではないかと思います。

使用したソフトウェアのバージョン

参考文献

• Ruby On Rails Security Guide
• Microformatsの手引き
• hProduct · Microformats Wiki
• クロスサイトリクエストフォージェリ