igaiga diary

2014-03-09 [長年日記] edit

_ パンデミック大会

前回までのとみーるさんに替わり、今回はゆどうふさんが主催のパンデミック（ボードゲーム）大会が開催されました。私は長らく一緒にパンデミックやっている、とみーるさんとちぇりさんとチームを組んで参加しました。場所はIT健保の市ヶ谷健保会館。（同じ場所で懇親会もできて、安いし、ITS素晴らしいですね。）

今回は弊社のサービスtmixを使ってチームパーカーを作成！3人で構想を練って、ちぇりさんがイラスト、とみーるさんがデザイン、私が注文というナイス（？）役割分担で進められた。今回のパーカー、春の新作にしたので、大会の日程にあわせて中のみなさんに実装や追加作業をお願いしたりしました。w その甲斐あってかっこいいチームパーカーができたし、なによりtmixでみんなでデザインするって楽しい作業なんだなーという自社サービスの良さを知る機会にもなりました。（ステマ）

さて、結果はというと、初球は最速でクリアしたものの、中級で手こずりギリギリクリア。これは今年の最優秀プレイなのでは、と思うほどの手応えはあった。しかし上級をクリアできず、優勝も入賞もできないという悔しい結果になりました。これもひとえに、スタッフのナース隊のみなさんが各テーブルへゲーム準備をしに来てくれるという状況の中、うちのチームだけゆどうふさんがセットアップに来たせいでナースさんがこなかったのが敗因に違いありません。（八つ当たり）めちゃめちゃ悔しかったです。（負けたことがです。）帰り道を3人でとぼとぼと帰りました・・・。

しかし負けたことで学ぶことが多々ありました。特に「根絶のメリットと判断」がまったくできていなかったことに気づき。上級だと同じ都市ばかり繰り返しでるので、カードの出具合によっては根絶の効果は絶大。5年以上もパンデミックをやっていてこんな基本的なことに気づいてなかったことにびっくりしつつ、まだまだ成長できるってことは嬉しいことでもあるなと思いました。本当に悔しかったですが。

次回の大会へ向けて、もっと練習と、各プレイのふりかえりをやらないといかんということに、ほろ苦く気づいた1日でした。大会参加も5回目ですが、優勝は遠いです・・・。

http://www.flickr.com/photos/igaiga/13046601623/

[ツッコミを入れる]

2014-03-06 [長年日記] edit

_ omniauth-identity

OmniAuth、twitter認証やfacebook認証が簡単に作れて便利ですね。omniauth-identity gem を使うと自前のパスワード認証も簡単につくれます。AsciiCast に解説もあっていたれりつくせり。

メールとパスワードの入力Webページは omniauth-identity が自動でつくってくれて便利ですが、APIからユーザーを作りたい場合にコントローラでどうすればいいのか調べたのでメモ。難しいことは何もなく、Identityモデルでpassword に代入する際にpassword_digestを計算して入れてるだけだった。

なので、

i = Identity.new(name: "igaiga", email:"igaiga@example.com", password: "igaigapass")

これでpassword_digest が代入されてる。あとは i.save! すればOK。

実際にやってるのは omniauth-identity gemの以下。

OmniAuth::Identity::SecurePassword::InstanceMethodsOnActivation#password=
def password=(unencrypted_password)
  @password = unencrypted_password
  if unencrypted_password && !unencrypted_password.empty?
    self.password_digest = BCrypt::Password.create(unencrypted_password)
  end
end

ところで、saltはないんですね。最近の認証システムにはsaltないなー、と思って調べてみた。

ここに詳しく書いてある。簡単に言うとこんな感じ。

BCrypt::Password.create(unencrypted_password) をつかっている。
これはsaltを保存しなくてよい仕組み。（中で自動生成）
そもそもsalt は何のためにあるかと言うと、攻撃者が総当たりで攻撃したときに時間がかかるようにするため。
- 暗号化された文字列が流出したときの話
- paswordとsaltを1つずつずらして暗号化して・・・を繰り返させる
そこで、攻撃者が計算するときに(saltがあったときよりも)十分に遅ければ、別途saltを保存しなくても良いはず
普通のhash(MD5とか)は遅くは設計されてない。速く計算されてしまう。
bcrypt は暗号化計算が十分に遅い。秒間450個のパスワードしか生成できない。(MD5だと約140,000個)

なるほど。どれどれ。

require 'bcrypt'
start = Time.new
100.times { |i| BCrypt::Password.create(i) }
finish = Time.now
p "#{finish - start} sec"

実行させたら100個暗号化するのに 6.247545 sec だった。確かにかなり遅くできてる。

3/7 追記：
Omniauth-identity、ascii cast に従ってname, emai, password_digestを作ったけど、表示しなければname要らないか。

[ツッコミを入れる]

2014-03-05 [長年日記] edit

_ versioncake gem

APIを提供するアプリをRailsで作るので、APIバージョン管理に versioncake gem を使ってみることにした。(@hsbt さんに教えてもらった。thanks!)バージョンごとに json view ファイルを分割できるので便利。gemを使うほどかなー、とも思ったけど、どのくらい便利か試しに使ってみる。Rails4.1RC1で動作確認済。

https://github.com/bwillis/versioncake

早わかり

こんなURLでアクセスできるようになる（他にもパラメータでバージョン指定したりもできる）
- http://example.com/api/v1/dummy/dummy.json
view 以下にこのようにファイルを置いていく。アクセスされたAPIバージョンview がない場合、自動で最近のものを使う。（＝viewが変更なければ変更不要）
- app/views/api/dummy/index.json.v1.jbuilder
- app/views/api/dummy/index.json.v2.jbuilder
controller は /api 以下に入れて、Api モジュールの中に入れるようにした
- 例： app/controllers/api/dummy_controller.rb , class Api::DummyController < ApplicationController
controller でアクセスされたバージョンを知るには derived_version を使う

Rails.logger.info "upper version v3!" if derived_version >= 3

routes

# for versioncake gem
namespace :api do
  scope 'v:api_version' do # Example: /v1/
    get '/dummy/dummy' => 'dummy#index'
  end
end

controller の中でAPIものはまとめてApiモジュールの中に入れるためにnamespace :api にしている。

config/application.rb

module Appname
  class Application < Rails::Application
    # versioncake gem setting
    config.versioncake.extraction_strategy = :path_parameter # /api/v1/ のようにバージョン情報をパスに入れる設定
    config.versioncake.supported_version_numbers = (1...4) # 古いAPIバージョンを制限する場合などに使う

[ツッコミを入れる]