去年の12月にLet’s Encryptがパブリックベータ版に移行したというのがニュースになったとき、管理しているサイトの1つ（stingrays.tokyo）を使って試してみようかなぁと思ったものの、いろいろ忙しかったのもあり早2ヶ月が経ってしまったが、FacebookのTLでちょうど環境が一致するチュートリアルのブログポストを見つけたので、本家のドキュメントを読みつつ手を動かしてみた。

結論を先に言うと、ちょっとつまづいたけど簡単にできた。

まず、サーバー環境に関して前提条件がいくつかある。

1. サーバーに非root権限でターミナルに接続（SSHなど）できること
2. sudoなどでroot権限での実行が可能であること
3. インターネット上に公開されている（DNSで名前解決できる）稼動中のWebサーバーであること

上記の質問で1つでも答えがノーならば、ここでおしまい。
基本的に共用レンタルサーバーとかでは使えない。

ちなみに今回使った環境は、さくらVPS上のUbuntu Server 14.04.3 LTS + Apache 2.4.7で、証明書がなかったのでHTTPだけで運用していたサーバー。

では早速Let’s Encryptをインストールしてみよう。と言っても、apt-get installでのインストールではなく、単にGitHubからソースをgit cloneするだけ。

$ sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

インストール先は/optにしたが、好みの問題でもあるので、別に/usr/localの下とかでも構わない。
Let’s EncryptはGitHub上で開発途上なんで、直近のリリースタグで固定しておいた方が安心かも。

$ cd /opt/letsencrypt
$ sudo git co -b v0.3.0 v0.3.0

続いてLet’s Encryptクライアントを介してサーバー証明書のインストールをする。

$ ./letsencrypt-auto --apache -d stingrays.tokyo

が、エラー発生…。

Domains: stingrays.tokyo
Error: The server could not connect to the client for DV

ネットで同じエラーを探してみたら、「Let’s EncryptのCAが証明書のインストール先になるWebサーバーの名前解決できてないんじゃね？」という回答が多かったが該当せず。

HTTPのみで運用しているというのが原因で、自己署名証明書でもいいからとりあえずHTTPSでアクセスできるようにしておかないといけなかった。

$ sudo a2enmod ssl
$ sudo a2ensite default-ssl
$ sudo service apache2 restart
$ curl -kI https://localhost
HTTP/1.1 200 OK
(略)

HTTPSでのアクセスはOK！
気を取り直してletsencrypt-autoを再実行するも失敗…ここがつまづいた部分。

curlだけでHTTPSにつながることを確認したけど、手元のブラウザで確認するのを怠っていた。ブラウザからHTTPSでつながらない…ってことは、今までHTTPオンリーで運用していたからiptablesで穴が開いてなかったというオチ。

改めてletsencrypt-autoを再実行！通った！

letsencrypt-autoは非root権限で実行しているのに、rootじゃないと編集できない/etc/apache2配下の設定ファイルが書き換わるのはなぜだろう？直近でsudoしてたからプロンプトしなかっただけ？
Let’s Encryptがどう設定を書き換えるのか気になる人は、/etc/apache2配下をgitで管理するといいでしょう。

$ cd /etc/apache2
$ sudo git init
$ sudo git add .
$ sudo git ci -m 'Initial config'

letsencrypt-autoの実行後にgit diffすれば変更点が一目瞭然。

ちなみに、Apache2の場合、/etc/letsencrypt/options-ssl-apache.confというファイルができあがり、mod_ssl用の推奨設定みたいなのが含まれているので、実際に運用している設定で欠けている部分があったらコピペして補完しとくといいでしょう。

これでLet’s Encryptの無料SSL証明書を使ってHTTPSがサービスできるようになったわけだ。

SSL Reportでも正常なHTTPS通信ができているという確認ができる（自分のサイトで試してください）。

めでたしめでたし…ではなく、Let’s Encryptの証明書の有効期間は90日しかないので、証明書が期限切れになる前に都度更新（Renew）しなければならない。現時点ではLet’s Encryptから証明書を自動更新する仕組みは提供されていないようだが、冒頭で紹介したブログポストで便利なシェルスクリプトを公開してくれていた。

$ sudo curl -L -o /usr/local/sbin/renew-letsencrypt http://do.co/le-renew
$ sudo chmod +x /usr/local/sbin/renew-letsencrypt

短いスクリプトなので、中で何をやっているのかザッと目を通しておくといいだろう。
最後に、このスクリプトをcronで定期実行するように設定すればおしまい。

$ sudo crontab -e
# 以下の1行を追記
0 3 1 */2 * /usr/local/sbin/renew-letsencrypt stingrays.tokyo >> /var/log/renew-letsencrypt.log

有効期間は90日だがバッファを設けて、偶数月の1日、つまり約60日間隔で更新処理が実行されるように仕込んでおいた。これで完全放置プレイで無料SSLが実現できたわけである。

The post Let’s Encryptで無料SSL証明書をインストールしてみた first appeared on Inhale n' Exhale.

function updateQuery(query)
{
  var form = document.forms[0]
    , action = document.createElement('a')
  ;

  // オリジナルの送信先URLからパス部分を切り出して、クエリーストリングだけを書き換える。
  action.href = form.getAttribute('action');
  form.setAttribute('action', action.pathname+'?'+query);
}

しかし、

• フォームを表示しているページのURLがWebサイトのルート直下ではない
• オリジナルのフォームの送信先URLが絶対パスで書かれている

という条件下では、フォームを送信した時にIEでだけ「404 Not Found」になってしまった。

例えば http://yourdomain.com/welcome/form.htmlというページにフォームがあって、formタグのaction属性値が/app/updateだったとすると、updateQuery('xxx')が実行された後にフォームを送信すると、http://yourdomain.com/welcome/app/updateにリクエストが飛んでしまう。

どうやらHTMLAnchorElementの実装がIEだけ違うみたいで、pathnameプロパティの先頭にスラッシュが付いていない。

試しに、JSFiddleにテストコードを書いてみたところ、IEだけ「path/to/resource」となってしまう。他のブラウザはみんな「/path/to/resource」になる。

IEは常に混乱をもたらしてくれる…。

ということで、クロスブラウザ対応するには

function updateQuery(query)
{
  ...（略）...
  form.setAttribute('action', (action.pathname.charAt(0) == '/' ? '' : '/')+action.pathname+'?'+query);
}

と書いてやらなければならない。

location.pathnameはIEでもちゃんとスラッシュが先頭に付いているのにね…やれやれ。

The post IEのHTMLAnchorElement.pathnameの実装 first appeared on Inhale n' Exhale.

Webアプリではお決まりのユーザー管理機能なんだが、話を単純にするためにやりたいことだけに焦点を当てるために、以下のようなrolesテーブルとusersテーブルがあるとしよう。

CREATE TABLE roles (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255) NOT NULL UNIQUE
);

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255) NOT NULL UNIQUE
  role INT FOREIGN KEY REFERENCE
);

ユーザーにロールを割り当てる典型パターン。
で、やりたいことは、

ロールの一覧表示をする際に、そのロールが割り当てられているユーザー数も出したい！

もちろん、SQL一発で簡単に取得できる。

SELECT roles.*,count(users.role) AS users
FROM roles,users
WHERE roles.id = users.role
GROUP BY roles.id;

このSQLをZend_Db_Selectで実装しようと思って、FROM句に2つのテーブルを並べるために

$select = $db->select();
$count = new Zend_Db_Expr('count(users.role)');
$select->from('roles')
       ->from('users', array('roles.*', 'users' => $count))
       ->where('roles.id = users.role')
       ->group('roles.id');
var_dump($select->__toString()); 

とやってみたが…

SELECT roles.*,count(users.role) AS users
FROM roles INNER JOIN users
WHERE roles.id = users.role
GROUP BY roles.id;

と、2つのテーブルがINNER JOINで結合するようなSQL文ができてしまった。

SQLを実行しても

ERROR:  syntax error at or near "WHERE"
LINE 3: WHERE roles.id = users.role
        ^

とエラーになってしまう（ちなみにRDBにはPostgreSQLを使っている）。

INNER JOINじゃなくてカンマでテーブル名を並べる方法はないものかとZend_Db_Selectのコードも調べてみたが

public function from($name, $cols = '*', $schema = null)
{    
    return $this->_join(self::FROM, $name, null, $cols, $schema);
}

となっているので、JOINする以外、選択の余地がないようで…。

最終的には、それぞれのテーブルに対応するZend_Db_Tableクラスを作って、それぞれのテーブルからfetchAll()して、PHP上で結合させるという方法に落ち着いた。SQLが2発実行されるのが嫌だけど、パフォーマンスがシビアになるWebアプリでもないので、コードの可読性を重視して。

class RolesController extends Zend_Controller_Action
{
  public function indexAction()
  {
    $table = new DbTable_Roles;
    $roles = array();
    $users = $this->_getRefUsers();
    foreach ($table->fetchAll($table->select()) as $row) {
      $role = (object)$row->toArray();
      $role->users = array_key_exists($role->id, $users) ? $users[$role->id] : 0;
      $roles[] = $role;
    }
    $this->view->roles = $roles;
  }

  private function _getRefUsers()
  {
    $table = new DbTable_Users;
    $count = new Zend_Db_Expr('count(role)');
    $select = $table->select()->from($table, array('role', 'users' => $count))->group('role');
    $users = array();
    foreach ($table->fetchAll($select) as $row) {
      $users[$row->role] = $row->users;
    }
    return $users;
  }
}

The post Zend_Db_Selectで複数テーブルからデータを取得したいのだが… first appeared on Inhale n' Exhale.

WordPressの引っ越しの手順はググればいくらでも見つかるが、

1. 旧サーバーでMySQLのバックアップ
2. 旧サーバーでWordPressのバックアップ
3. MySQLのバックアップファイルを調整
4. WordPressのバックアップファイルを調整
5. 新サーバーでMySQLのリストア
6. 新サーバーでWordPressのリストア

というのが大まかな流れ。

今回の引っ越しのポイントとしては

• ブログのURLは同じ
• WordPressがインストールされている物理パスが変わる

という2点。

共用サーバーを使っていると、ホームディレクトリのパスはサーバー業者に割り当てられてしまう宿命なので、2点目のWordPressのインストールパスが変わるというのはよくあることだろう。新旧サーバーで同じホームディレクトリだったら簡単なんだけどねぇ。

ここでは新旧サーバーでのWordPressのインストールパスを

• 旧サーバー：/home/before/public_html/wordpress
• 新サーバー：/home/after/public_html/wordpress

と仮定しましょう。

MySQLのバックアップファイル（mysqldumpで出力されたSQLスクリプト）には、データの一部に物理パスが含まれているので、そいつらを手で全部書き換えてやらなきゃいけない。最初は単純な文字列置換だからsedで一括変換すればいいやと思ってたんだけど、いざリストアしてみるとプラグインのいくつかが動かなくなりハマったわけ。

改めてバックアップしたSQLスクリプトから物理パスを抽出してみると、物理パスが書かれているのはすべてwp_optionsテーブルの中で、

s:83:\"/home/before/public_html/wordpress/wp-content/plugins/wp-dbmanager/wp-dbmanager.php\"

というレコードになっていた。

このs:83って部分が何を意味するのかわからなかったけど、後続の文字列数を数えてみると83文字！他にもi:4とかa:2とかがあるところを見ると、文字列はs:文字列長:"値"、数値はi:値、配列はa:要素数:{値}というルールっぽい。たぶん、WordPressのAPIがシリアライズしてくれてるんだな。

つまり、物理パスを書き換える場合、単純な文字列置換だけじゃなく文字列長を正しく調整する必要があると。新旧サーバーで物理パスの文字列の差分は「before」と「after」で、文字列長は1つ減ることになる。

前述のレコードだと

s:82:\"/home/after/public_html/wordpress/wp-content/plugins/wp-dbmanager/wp-dbmanager.php\"

と書き換えてやればいいわけだ。

コマンドで一括変換できないかとも思ったが、この形式でデータを保存しているプラグインの数が少なかったので、エディタでちまちま調整していった。

WordPressがMySQLに保存する物理パスをインストールパスからの相対パスになるように設計されていれば、こんな面倒なことはしなくて済むんだけど、これだけ世界中で使われているソフトだと現実的に途中で仕様変更はできないんだろうな。

The post WordPressの引っ越しでハマったこと first appeared on Inhale n' Exhale.

例えば、ifupコマンドが実行された場合、/etc/network/if-pre-up.dと/etc/network/if-up.d配下にあるコマンドが、ifupの実行中に呼び出されるようになっている。あるコマンドが実行されていることはログなどからわかっているが、どのような経緯で実行されるに至ったかがわからない、という場合には、そのコマンドの親プロセスを辿っていけば調べることができる。

実行されているコマンドがバイナリだと手も足も出ないかもしれないが、シェルスクリプトであれば、以下のようなスクリプトを使って呼び出し元の親プロセスたちを辿ることができる。

trace_parents()
{
    local pid=$$ cmd
    while true; do
        cmd="$(cat /proc/$pid/cmdline | tr '\0' ' ')"
        echo -e "pid=$pid, cmd=$cmd"
        [ $pid -eq 1 ] && break
        pid=$(awk '/^PPid:/{print $2}' /proc/$pid/status)
    done
}

trace_parents > /tmp/parents.$(basename $0).log

PIDが1、すなわちinitになるまで/proc/pid/statusの中から親プロセスのPIDを辿っていくというものだ。/proc/pid/cmdlineをcatでダンプさせると、コマンドライン引数の間にスペースがないように見えるが、区切り文字はnull文字（\0）になっているので、trでスペースに置換すれば見やすくなる。

The post プロセスのコールスタックを調べるシェルスクリプト first appeared on Inhale n' Exhale.

今使っている環境では、メインのLinuxマシンの上で仮想マシン（Linux）を動かしていて、仮想マシンにSSHで入って開発をしている。gitリポジトリはまた別のサーバーにあって、そこにもSSHでつなぐ必要がある。リモートのgitリポジトリにアクセスする度に、パスフレーズを聞かれるのがウザかったので、仮想マシンにSSHでログインした後、手動でssh-agentを立ち上げてssh-addで秘密鍵を登録（このときパスフレーズを聞かれる）していたのだが、この手作業自体がまた面倒になった。

メインマシン上でターミナルをいくつも立ち上げて、それぞれで仮想マシンにSSHログインしていると、仮想マシン上でssh-agentがポンポン立ち上がることになる。さらに、仮想マシン上で別のシェルを起動させると、またssh-agent/ssh-addを繰り返さなければならない。パスフレーズの入力は、仮想マシンに初めてログインしたときだけにしたいものだ。

ssh-agentを起動する場合に、ssh-agent bashを実行するサンプルをよく見かけるが、これだと子プロセスとして別のbashが立ち上がることになり、仮想マシンからログアウトするのにexitを2回たたく羽目になる。

local$ ssh remote
remote$ ssh-agent bash
remote$ exit # ssh-agent経由で起動したbashを抜けただけ
remote$ exit # ここでSSHから抜ける 
local$

ssh-agentは引数なしで起動すると、ssh-agentに接続するために必要な環境変数を設定するためのスクリプトを吐き出してくれる。

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-lryfV7tY5VHY/agent.26301; export SSH_AUTH_SOCK;
SSH_AGENT_PID=26302; export SSH_AGENT_PID;
echo Agent pid 26302;

手動でssh-agentを起動する場合は、eval "$(ssh-agent)"とするのがいいだろう。

もったいぶってしまったが、~/.bashrcに以下のコードを追記すると、初回ログイン時にだけパスフレーズを聞かれるようになり、仮想マシン上でssh-agentが複数立ち上がることもなくなる。

# Setup ssh-agent
if [ -f ~/.ssh-agent ]; then
    . ~/.ssh-agent
fi
if [ -z "$SSH_AGENT_PID" ] || ! kill -0 $SSH_AGENT_PID; then
    ssh-agent > ~/.ssh-agent
    . ~/.ssh-agent
fi
ssh-add -l >& /dev/null || ssh-add

The post SSHのパスフレーズ入力を省略する方法 first appeared on Inhale n' Exhale.

インストール

通常のNPMパッケージと同じようにnpm installでインストール。

$ npm install exprest

使用方法

exprestが提供するのはconfigure()という関数のみ。

exprest.configure(app [,opts]);

appには、express.HTTPServerオブジェクトかexpress.HTTPSServerを渡すように。もちろん、exprest#configure()を呼ぶ前にexpress-resourceをrequire()で読み込んでおくこと。

一番シンプルな使い方はこんな感じ。

var express = require('express')
  , resource = require('express-resource')
  , exprest = require('exprest')
  , app = express.createServer();

exprest.configure(app);

ルーティングのコードは一切書く必要がない。アプリケーションのルートディレクトリにresourcesというディレクトリを作って、そこに以下のようなresourceモジュールを実装しておけば、ルーティングはexprestが面倒を見てくれるようになっている。

module.exports = {
    index: function(req, res) {
      res.end('index');
    }
  , new: function(req, res) {
      res.end('new');
    }
  , create: function(req, res) {
      res.end('create');
    }
  , show: function(req, res) {
      res.end('show');
    }
  , edit: function(req, res) {
      res.end('edit');
    }
  , update: function(req, res) {
      res.end('update');
    }
  , destroy: function(req, res) {
      res.end('destroy');
    }
};

resourceモジュールのファイル名がREST APIで提供するリソースへのパスを表すようになっている。例えば、resource/users.jsというモジュールを実装したら、exprestが/users/*に対するリクエストをルーティングしてくれる。

オプション

configure()関数の第2引数optsを使って、exprestの振る舞いをカスタマイズすることができる。optsを省略した場合は、以下のデフォルト値が適用される。

{
    basedir: 'resources'
  , root: '/'
  , vars: {}
  , varsKey: 'vars'
  , checkAuth: undefined
  , defaults: {}
}

• basedir（文字列）
  resourceモジュールの配置先となるディレクトリ。
• root（文字列）
  REST APIのルートとなる仮想ディレクトリ。
  例えば、{ root: '/api' }を渡すと/api/users/*へのリクエストはresources/users.jsにマップされる。
• vars（オブジェクト）
  http.ServerRequestを介してAPIに渡す変数。
  このオプションにより、resourceモジュール間で変数を共有することができる。例えば、app.js内でexprest#configure()を呼び出すコードがあって、app.jsのローカル変数をresourceモジュールに引き渡したかったとしよう。グローバル変数（GLOBAL）を使うという手もあるが、どのようなプログラムでもグローバル変数はできるだけ避けたいものである。varsオプションは、このような変数をhttp.ServerRequest経由で引き渡すためのものだ。

  サンプルコードを見るのがわかりやすいだろう。

  // app.js
  var express = require('express')
    , resource = require('express-resource')
    , exprest = require('exprest')
    , mysql = require('mysql').createConnection(...)
    , app = express.createServer();
  
  exprest.configure(app, {
      vars: { mysql: mysql }
  });
  
  // resources/users.js
  module.exports = {
      index: function(req, res) {
        var mysql = req.vars.mysql; // Passed by exprest
        mysql.query('SELECT * FROM users', function(err, users) {
            ...
        });
      }
  };
  

  resourceモジュール（サンプルではusersモジュール）がDB操作を伴うような場合、DB接続を保持するオブジェクト（サンプルではapp.js内のmysqlオブジェクト）をすべてのresourceモジュールで共有したいケースはよくある。resourceモジュールはapp.jsとは別ファイルに実装されているので、mysqlオブジェクトをapp.jsから直接的にresourceモジュールに引き渡すことはできないが、exprest.configure()でvarsオプションにオブジェクトを引き渡すと、resourceモジュールの各アクションメソッドの引数req.varsを介してアクセスすることができるようになる。

• varsKey（文字列）
  varsで渡したオブジェクトを、http.ServerRequestにマップする際のキーを指定する。例えば、varsKeyに"hoge"を指定した場合、resourceモジュールの各アクションメソッドでは、req.hogeを介してアクセスすることになる。
• checkAuth（関数）
  checkAuthオプションを指定すると、exprestはルーティングに先立ってcheckAuthに渡された関数を呼び出すようになる。これにより、APIに対する認証フィルターを設けることができる。checkAuthで指定する関数は、現在のセッションが認証済みかどうかを示す真偽値を返すように実装しなければならない。

  checkAuthがtrueを返した場合、exprestはそのままAPIにルーティングする。falseを返した場合、exprestは何もしない。checkAuthはfalseを返す前に、クライアントにレスポンスを送らなければならない。

  以下はセッションを用いて認証状態を管理するサンプル。

  var express = require('express')
    , resource = require('express-resource')
    , exprest = require('exprest')
    , app = express.createServer();
  
  exprest.configure(app, {
      checkAuth: function(req, res) {
        if(req.session.user_id) {
          return true;
        }
        res.send(403);
        return false;
      }
  });
  

• defaults（オブジェクト）
  express-resourceに引き渡すオプション。

The post exprestをnpmにリリース first appeared on Inhale n' Exhale.

スタート地点はこの段階。

module.exports = function(models) {
  var User = models.user;

  return {
      signup: function(req, res) {
      }

    , login: function(req, res) {
      }

    , logout: function(req, res) {
      }
  };
};

サインアップ

signupメソッドの役割は新規ユーザーを登録すること。リクエストボディからusernameとpasswordの2つのパラメータを読み取って、Userモデルを介して DBにレコードを追加する。

signup: function(req, res) {
  var username = req.body.username || null
    , password = req.body.password || null;

  if(!username || !password) {
    res.statusCode = 403;
    res.end({ error: 'Shortage of params' });
    return;
  }

  User.create({
      username: username
    , password: User.hashPassword(password)
  })
  .success(function(user) {
    user = user.values;
    delete user.password;
    res.end(user);
  })
  .error(function(error) {
    res.statusCode = 500;
    res.end({ error: error });
  });
}

11-14行目：DBにレコードを追加するにはモデルのcreateメソッドを使う。引数は新しいレコードのデータを表すオブジェクトリテラル。リクエストボディから読み取ったpasswordは平文なので、Userモデルのクラスメソッドとして実装したhashPasswordメソッドを使ってハッシュ値に変換している。

15-19行目：レコードの追加が成功するとsuccessメソッドに渡した関数がコールバックされ、追加されたモデルのインスタンスが引数に渡される。追加されたレコードにアクセスするにはvaluesプロパティを使う。例えば、自動連番のインデックスや、現在時刻がデフォルト値になっている時刻データのように、追加時に確定するようなデータもvaluesプロパティには含まれている。passwordカラムはハッシュ化されたパスワードだが、外部に漏らすことはないので、クライアントには送信しないようにしている。

20-23行目：errorメソッドにはレコードの追加に失敗した場合のコールバック（エラーハンドラ）を渡す。

レコードの追加はcreateメソッドを使う以外に、buildメソッドとsaveメソッドを別々に呼び出す方法もある。データの追加前にバリデーションを行うのがよくあるケースだろう。例えば、usernameカラムをメールアドレス形式にするように仕様を変えたとした場合、Userモデルの定義時にバリデーションも含めるようにする。

// models/user.js
module.exports = function(sequelize, DataTypes) {
    return sequelize.define('user', {
        username: {
            type: DataTypes.STRING
          , unique: true
          , validate: { isEmail: true }
        }
      , password: 'char(40)'
    });
};

データ追加前にバリデーションを行うには、先にbuildメソッドでモデルのインスタンスを生成してvalidateメソッドを呼び出す。

  var new_user = User.build({
          username: username
        , password: User.hashPassword(password)
      })
    , invalid = new_user.validate();

  if(invalid) {
    res.statusCode = 403;
    res.end({ error: 'Invalid param', detail: invalid });
    return;
  }

  new_user.save()
  .success(function(user) {
    ...
  })
  .error(function(error) {
    ...
  });

validateメソッドは、モデル定義のvalidateで指定したルールを使ってバリデーションを行い、何もエラーがなければnullが返ってくる。Sequelizeに標準で組み込まれているバリデータがたくさんあるので見ておくといいだろう。

すでに設計編でルーティングは実装しているので、curlを使ってサインアップを実行してみよう。

$ curl -X POST -d 'username=h2plus&password=pass' localhost:3000/auth/signup

ログイン

loginメソッドの役割はユーザーを認証すること。リクエストボディからusernameとpasswordの2つのパラメータを読み取って、Userモデルを介して DBからレコードを検索する。

login: function(req, res) {
  var username = req.body.username || null
    , password = req.body.password || null;

  if(!username || !password) {
    res.statusCode = 403;
    res.end({ error: 'Shortage of params' });
    return;
  }

  User.find({
      where: {
          username: username
        , password: User.hashPassword(password)
      }
  })
  .success(function(user) {
    if(user) {
      user = user.values;
      delete user.password;
      req.session.user_id = user.id;
      res.send(user);
    }
    else {
      res.statusCode = 403;
      res.end({ error: 'Authentication failure' });
    }
  })
  .error(function(error) {
    res.statusCode = 500;
    res.end({ error: error });
  });
}

11-16行目：1件のレコードを検索するにはfindメソッドを使う。引数には検索（SELECT文）の条件などを渡すことができる。今回はユーザー認証が目的なので、ユーザー名とパスワードのハッシュ値をWHERE句に指定して検索している。複数件のレコードを検索する場合は、findAll（またはall）メソッドを使う。

18-23行目：検索を実行した結果、レコードが見つかった場合は、該当レコードのインスタンスがコールバック関数の引数に渡ってくる。サインアップで使ったcreateと同様にデータへのアクセスはvaluesプロパティを使う。レコードが見つかったということは、ユーザー名とパスワードが一致した証なので、セッションにidカラムを保存しておくようにする。

24-27行目：検索の結果、レコードが見つからなかった場合もsuccessメソッドに渡したコールバック関数が呼び出されるが、引数はnullになっている。errorメソッド側のコールバックが呼ばれるわけではないので注意。

先ほどサインアップしたアカウントを使って、curlからログインを実行してみる。セッション管理にはCookieが使われているので、-cオプションでCookieJarに保存するようにしておこう。

$ curl -c ~/.cookies -X POST -d 'username=h2plus&password=pass' localhost:3000/auth/login

ログアウト

logoutメソッドの役割は既存のログインセッションを破棄すること。サインアップ、ログインに比べると、DBアクセスもないので簡素な実装になる。

logout: function(req, res) {
  req.session.destroy();
  res.end();
}

curlでのログアウト実行時は、ログイン時と同じCookieJarを-bオプションで指定する。

$ curl -b ~/.cookies -X POST localhost:3000/auth/logout

The post Sequelizeを使ってユーザー認証／実装編 first appeared on Inhale n' Exhale.

#include <iostream>
#include <sstream>
#include <boost/property_tree/json_parser.hpp>
using namespace std;

int main(int argc, char *argv[])
{
	if(argc < 2)
	{
		cerr << "Usage: " << argv[0] << " message" << endl;
		return 1;
	}

	boost::property_tree::ptree pt;
	pt.put("message", argv[1]);
	boost::property_tree::write_json(cout, pt, false);
	return 0;
}

コマンドライン引数にhelloを渡して出力されたJSONがこちら。

$ g++ -I/usr/include/boost_1_50_0 -o write_json main.cpp
$ ./write_json hello
{"message":"hello"}

では引数に日本語を渡すとどうなるか。

$ ./write_json ほげ
{"message":"\u00E3\u0081\u00BB\u00E3\u0081\u0092"}

シェル実行環境のロケールはen_US.UTF-8。日本語部分は1バイトずつ\u00XXという形にエンコードされている。

このJSONをChrome Development Toolで読み込ませてみる。

素敵に文字化け。

JSONの仕様で文字列型は

A string is a sequence of zero or more Unicode characters, wrapped in double quotes, using backslash escapes.

と定義されているので、UTF-8から一旦Unicodeに変換しなければならない。PHPのjson_encode()なんかは、入力の文字コードがUTF-8に限定しているものの、内部でUnicode化してからJSONエンコードをしてくれているようだ。

ということで、まずはUTF-8からUnicodeへ変換する処理が必要になる。また、マルチバイト文字列（std::string）とワイド文字列（std::wstring）との変換もしなければならない。面倒ではあったが、標準ライブラリのcodecvtを使えばなんとかなりそうだったので、UTF-8からUnicodeへの変換を行うwiden()関数と、その逆変換を行うnarrow()関数（JSON出力の目的ではなくてもいいんだけど対称性のため）を提供するCodeCvtクラスを作ってみた。

#include <iostream>
#include <stdexcept>
#include <vector>
#include <string>
#include <cstring>
#include <locale>
#include <boost/property_tree/json_parser.hpp>
using namespace std;

class CodeCvt
{
public:
	explicit CodeCvt(const char *locale="en_US.UTF-8")
	: locale_(locale), codecvt_(use_facet<codecvt_type>(locale_)) {}

	wstring widen(const string &s)
	{
		const char *fb = s.data();
		const char *fe = fb+s.size();
		const char *fn;
		vector<wchar_t> ws(s.size());
		wchar_t *tb = &ws.front();
		wchar_t *te = tb+ws.size();
		wchar_t *tn;
		mbstate_t st;
		bzero(&st, sizeof(st));

		const codecvt_base::result res = codecvt_.in(st, fb, fe, fn, tb, te, tn);
		assert_result(res, fn, fe);
		return wstring(tb, tn);
	}

	string narrow(const wstring &ws)
	{
		const wchar_t *fb = ws.data();
		const wchar_t *fe = fb+ws.size();
		const wchar_t *fn;
		vector<char> s(ws.size()*4);
		char *tb = &s.front();
		char *te = tb+s.size();
		char *tn;
		mbstate_t st;
		bzero(&st, sizeof(st));

		const codecvt_base::result res = codecvt_.out(st, fb, fe, fn, tb, te, tn);
		assert_result(res, fn, fe);
		return string(tb, tn);
	}

private:
	template<class CharT>
	static void assert_result(codecvt_base::result res, const CharT *fn, const CharT *fe)
	{
		switch(res)
		{
			case codecvt_base::ok:
				if(fn != fe)
				{
					throw invalid_argument("Conversion failure");
				}
				break;
			case codecvt_base::partial:
				throw invalid_argument("partial");
			case codecvt_base::error:
				throw invalid_argument("error");
			case codecvt_base::noconv:
				throw invalid_argument("noconv");
		}
	}

	typedef codecvt<wchar_t, char, mbstate_t> codecvt_type;
	const locale locale_;
	const codecvt_type &codecvt_;
};

mbstate_t型の変数stをbzero()やmemset()などで初期化しておかないと、codecvt_.in()やcodecvt_.out()の中で不測の事態が起こるので注意（実際テスト中に無限ループにハマってデバッガで追いかける羽目になった）。

main()関数側では、ptreeの代わりにwptreeを使い、出力もcoutではなくwcoutを使うようにするだけ。

int main(int argc, char *argv[])
{
	try
	{
		CodeCvt cvt;
		boost::property_tree::wptree pt;
		pt.put(L"message", cvt.widen(argv[1]));
		boost::property_tree::write_json(wcout, pt, false);
		return 0;
	}
	catch(const exception &e)
	{
		cerr << e.what() << endl;
		return 1;
	}
}

さっそく実行してみる。

$ ./write_json ほげ
{"message":"\u307B\u3052"}

ちゃんとUnicodeのバイトシーケンスでエンコードされているのがわかる。

同じようにChrome Development Toolで読み込ませてみる。

今度はちゃんと「ほげ」と表示されるようになった。

CodeCvtクラスのコンストラクタ引数で別の文字コード（例えばja_JP.EUC-JP）を渡せば、UTF-8以外のマルチバイト文字列からでもJSON化することができるはず。

ソースはGistに置いといた。

The post boost::property_treeで日本語を含むJSONが文字化けする first appeared on Inhale n' Exhale.

大まかな流れはこんな感じ。

1. Userモデルを定義する
2. 認証モジュールを設計する
3. リクエストのルーティングを追加する
4. 認証モジュールを実装する

はじめにアプリケーションのディレクトリ構造がどうなっているかおさらい。

myrest/
├── app.js
├── config/
│   └── development.json
├── libs/
│   ├── dbconn/
│   └── models/
├── models/
│   └── user.js
├── node_modules/
├── package.json
└── routes/
    ├── index.js
    └── sync.js

Userモデルを定義する

Userモデルはmodels/user.jsで以下のように定義していた。

module.exports = function(sequelize, DataTypes) {
    return sequelize.define('user', {
        username: DataTypes.STRING
      , password: 'char(40)'
    });
};

ユーザーを認証する際はusernameカラムがキーになるので、UNIQUE制約を追加しておく必要がある。
passwordカラムは40バイトの固定長としているのは、SHA-1のハッシュ値（160bit）を16進数で格納するためだ。平文のパスワードからハッシュ値を計算する関数はいずれ必要になるので、Userモデルのクラスメソッドとして実装しておく。

module.exports = function(sequelize, DataTypes) {
    return sequelize.define('user', {
        username: {
            type: DataTypes.STRING
          , unique: true
        }
      , password: 'char(40)'
    }, // End of table definition
    {
        classMethods: {
            hashPassword: function(pass) {
                var sha1 = require('crypto').createHash('sha1');
                sha1.update(pass, 'utf8');
                return sha1.digest('hex');
            }
        }
    });
};

こうしておくことで、Userモデルを参照できるところでは、User.hashPassword()を呼び出せるようになる。

認証モジュールを設計する

実装する認証機能はサインアップ、ログイン、ログアウトの基本的なものだけにしておく。facebook連携とかパスワードリマインダーとか、認証モジュールの仕事はたくさんあるけどね。

まずroutes/auth.jsに認証モジュールの枠組みだけ作ってしまおう。

module.exports = function(models) {
  var User = models.user;

  return {
      signup: function(req, res) {
      }

    , login: function(req, res) {
      }

    , logout: function(req, res) {
      }
  };
};

routes/authモジュールは、modelsオブジェクトを引数に受け取り、認証機能を提供するオブジェクトを返す関数として実装する。

signupメソッドでusersテーブルに新規データを登録。loginメソッドで認証処理を行いセッションを使ってログイン状態を保存する。logoutメソッドはセッションの破棄を行うだけ。

各メソッドの中身は実装編にて。

リクエストのルーティングを追加する

routes/index.jsでroutes/authモジュールの各メソッドにルーティングするコードを追加する。

module.exports = function(app, config) {

  var sequelize = require('dbconn')(config)
    , models = require('models')(sequelize);

  // Database migration
  app.configure('development', function() {
    var sync = require('./sync');
    app.post('/devel/sync/:table', sync.one(models));
    app.post('/devel/sync', sync.all(sequelize));
  });

  // Authentication
  var auth = require('./auth')(models);
  app.post('/auth/signup', auth.signup);
  app.post('/auth/login', auth.login);
  app.post('/auth/logout', auth.logout);

};

すべてPOSTメソッドのみルーティングして、入力となるデータはexpressが提供するrequest.body経由で取得するようになる。

実装編へ続く…

The post Sequelizeを使ってユーザー認証／設計編 first appeared on Inhale n' Exhale.