タグ「node.js」が付けられているもの

Node.jsで困るのはある機能を満たすためにどのパッケージを使っていいか分からないことです。発展途上ということで納得しましょう。発展途上というか生態系。

今回、Facebook認証をするためのモジュールを探しました。 stackoverflowで色々比較コメントがあり、それらやREADMEを参考にしました。

connect-authというのは名前もいいし、それなりのStar数もあります。シンプルでよさそうなのですが、よく使い方が分かりません。人気があるのは後発のeveryauthのようです。しかし、ドキュメントを読んでみてもどうもピンときません。なにか、感性が合わないような気がしました。

そこで、Passportを試すことにしました。 http://passportjs.org/guide/facebook/にドキュメントがあります。everyauthと比較するとコーディング量は多いかもしれませんが、なんとなくこちらの方が合う気がします。それでも、accessTokenが欲しいだけの場合は、userオブジェクトなんて作らなくてもいいのですけど。これはeveryauthも同じ(?)なので我慢するとします。

簡単に今使ってみた方法を紹介します。

まずは、ライブラリのロードです。サンプルをコピペしただけです。

var passport = require('passport');
var FacebookStrategy = require('passport-facebook').Strategy;

続いて、FacebookStrategyの設定です。accessTokenだけ欲しかったので、それをuserオブジェクトにします。必要であれば、profileとかも入れればよいでしょう。userオブジェクトは、req.userで参照できるので、accessTokenはreq.user.accessTokenになります。

passport.use(new FacebookStrategy({
  clientID: process.env.FACEBOOK_APP_ID,
  clientSecret: process.env.FACEBOOK_SECRET,
  callbackURL: process.env.CALLBACK_URL
}, function(accessToken, refreshToken, profile, done) {
  done(null, {
    accessToken: accessToken
  });
}));

サンプルにあったシリアライザも入れておきます。これは書かなくてもよさそうと思ったのですが、ソースみてもデフォルトがあるように見えず、念のためいれておきます。

passport.serializeUser(function(user, done) {
  done(null, user);
});
passport.deserializeUser(function(obj, done) {
  done(null, obj);
});

強制的にログインさせるmiddlewareです。一度、ログインを促すページを表示するほうが親切かもしれません。

function ensureAuthenticated(req, res, next) {
  if (req.isAuthenticated()) {
    next();
  } else if (req.url.lastIndexOf('/auth/', 0) >= 0) {
    next();
  } else {
    res.redirect('/auth/facebook');
  }
}

expressの設定です。セッションを使うのでその設定が必要です。

var app = express();
app.use(express.cookieParser());
app.use(express.session({ secret: 'foobar' }));
app.use(passport.initialize());
app.use(passport.session());
app.use(ensureAuthenticated);

最後に、expressのルートの設定をします。failureRedirectは暫定です。

app.get('/auth/facebook', passport.authenticate('facebook'));
app.get('/auth/facebook/callback', passport.authenticate('facebook', {
  successRedirect: '/',
  failureRedirect: '/auth/loginfailed'
}));
app.get('/auth/loginfailed', function(req, res) {
  res.send('login failed');
});

以上、こんな感じで使うようです。/auth/facebookのようなルートを設定しなければならないのを面倒と考えるか、分かりやすいと考えるかが、Passportを受け入れられるかの境目かもしれません。

最近、connect-prerendererのIssueを報告してもらって、少しずつ不具合が見つかっては修正しています。

うまく解決したのは、

の二つ。前者は、

<div>
  count={{count}}
  <span>hoge</span>
</div>

のように、TextNodeとHTMLElementが並んでいるときに、 ng-bind-templateで上書きしてしまう問題でした。

<div>
  <span>count={{count}}</span>
  <span>hoge</span>
</div>

とコンパイル時になるように、Angular.jsをいじりました。 ただ、CSSがそれを想定しない書き方だと、表示に不具合がでるかもしれません。

後者は、doctypeがjsdomで消えている問題でした。こっちはすぐに直りました。

https://github.com/dai-shi/connect-prerenderer/issues/3 がなかなか手ごわく、まだ解決の糸口が見つかりません。 以前書いた、jsdomからAngularJSの不具合二つ目の問題です。

なんにしても、興味を持ってくれる人が増えるのはうれしいことです。 connect-prerendererはほとんど宣伝していないのに、Star数が増えてきました。それはそれで不思議。

facebook-node-sdkを使って、簡単なFacebook Graph APIの呼び出しをしていたのですが、不思議なエラーがでてました。

(#5) Unauthorized source IP address

というエラーです。

stackoverflowでも複数のスレッドで話題になっていました。IPが変わってしまっていて、エラーになっているということは分かりました。

herokuを使うと、デプロイしてから何時間か経つとIPアドレスが変わるようです。そこで、access tokenを同じものを使い続けると上記エラーがでるので、access tokenを取得し直す必要があります。

これは、OAuthExceptionのときに再取得するようにすればいいのですが、少しはまりました。access tokenを取得するAPIを呼ぶ時に事前にaccess tokenをクリアしておく必要がありました。そうしないと、access tokenを再取得しようとするときに上記のエラーが出ました。Facebook側の問題か、ライブラリ側の問題か難しいところですが、とりあえずは自分で回避するしかないです。

参考までにサンプルコードを載せておきます。

FB.api('hoge/feed', function(res) {
  if (res && res.error && res.error.type === 'OAuthException') {
    FB.setAccessToken(null);
    FB.api('oauth/access_token', {
      client_id: process.env.FACEBOOK_APP_ID,
      client_secret: process.env.FACEBOOK_SECRET,
      grant_type: 'client_credentials'
    }, function(res) {
      if (!res || res.error) {
        console.log('error occurred when getting access token:', res && res.error);
        cb(res);
        return;
      }
      FB.setAccessToken(res.access_token);
      FB.api('hoge/feed', cb);
    });
  } else {
    cb(res);
  }
});

今回はapplication access tokenを使う時に起こったエラーですが、普通のuser access tokenでも同じかもしれません(未確認)。


5/2追記。

上記のコードでも回避できずにエラーになったことが一度だけありました。再度調査中ですがその後再現しないので解決できないです。

5/6追記。

その後安定して動いています。前回の一度起こったエラーはたまたま別の要因があったと思っておきましょう。

久しぶりにFacebookアプリを作ることにしました。以前作った時から仕様がちょっと変わったので、勉強し直しです。

ちなみに、以前作ったアプリは修正していないので、動かなくなってしまっています。Java & JSPでGAE向けに作ったのであまりやる気が出なくなってしまいました。Node.jsで書き直そうかしらと思いつつも、作り直すならもうちょっと全体設計から見直したいと思って手がつけられていません。

話を戻すと、FacebookのGraph APIを使うためのライブラリを調べました。

http://developers.facebook.com/tools/third-party-sdks/#nodejs

にいくつかリストアップされています。

リポジトリの名前が同じものがあり少しややこしいです。NPMのパッケージ名は違います。Star数が同じなのはたまたまのようです。

さて、少しずつ特徴があります。amachang/facebook-node-sdkとnode-facebook-sdkはオリジナルのFacebook PHP SDKを再現したライブラリになっています。Thuzi/facebook-node-sdkはブラウザ向けのFacebook JavaScript SDKと同じAPIをサーバ側でも実現したものです。これはとてもnode.jsらしいと思いました。fbgraphは、また路線が違ってJavaScriptっぽくJSON APIに書き直したような感じです。

今回はFacebookアプリと言ってもあまり複雑なことをするつもりがなかったのと、以前PHP SDKを見たことがある(そして、わざわざJavaに移植した)ので、PHP SDK互換のものを使おうと思いました。二者択一ならとりあえずStar数を信じてみようということで、amachang/facebook-node-sdkを入れてみました。

ところが、初めに作ったサンプルでつまずきました。applicationのaccess tokenを使ってGraph APIを呼ぶのですが、エラーになるのです。うーん、なぜだ、と思ってソースを眺めると、あれ?application access tokenを取得するAPIが想像していたもの(以前、Rubyのライブラリを使ったことがあった)と違います。こりゃ、動かないわけです。もしかしたら、Facebookの仕様が変わったのかもしれません。深追いするのは止めました。たぶん、user access tokenを使っている範囲では正常なのでしょう。

やはり、Star数の多いものから使おうと、Thuzi/facebook-node-sdkとfbgraphを天秤にかけます。README.mdを読んで比較しました。結果、fbgraphにはapplication access tokenを取得する方法が書いてなく、できるとしてもすっきりしないと予想しました。一方、Thuzi/facebook-node-sdkにはapplication access tokenを取得する方法が書いてありました。application access tokenはサーバ側のコーディングのみで使用可能なため、Facebook JavaScript SDKには入っていないnon-standardな機能です。

作ったサンプルも動作し、満足です。application access tokenを使おうとしている人には参考になるかもしれません。ただし、現時点での話であることをお忘れなく。将来的には状況は変わるかもしれません。

参考までに、コードの抜粋はこちらに。

RSS Pipesは、JavaScriptでフィルターを書く、RSSアグリゲーターです。

フィルターJavaScriptはブラウザ上で誰でも書くことができます。すなわち、バグ入りのコードや、悪意のあるコードも書くことができます。 そのような不正なコードにどう対処するかがポイントになります。

RSS PipesはNode.jsで動いています。Node.jsにはvmというモジュールがあって、サンドボックス環境を作ることができます。 Node.jsを使ったことがある方は分かると思いますが、モジュールを書いてrequireするとexportsしたもの以外は名前が衝突しません。 これはrequireでモジュールをロードする時にサンドボックス環境で評価しているからです。 RSS Pipesでもこの仕組みを使ってJavaScriptのコードを評価しています。 よって、ブラウザ上から入力されたJavaScriptコードによって、サーバ側のNode.jsにアクセスされることはありません。

ところが、vmモジュールのマニュアルをよく読むと書いてあるように、このモジュールを使うことで安全になるわけではありません。安全にコードを走らせるためにはサブプロセスを使うように、と書いてあります。

どういうことかと言うと、Node.jsはシングルスレッドで動作するため、vmでサンドボックス環境を作ったとしてもそこで使用されるリソース(CPUパワーやメモリ)を制限することはできず、リソースを不用意に使われてしまう可能性があります。簡単な例では、

while(true) {}

というJavaScriptを走らせるとNode.js全体が固まってしまいます。 とは言っても、herokuで動いているRSS Pipesでサブプロセスを使うわけにはいきません。(もしかして、使うこと自体はできるのかも?)

そこで、無限ループを判定するような仕組みをいれています。 先ほどの例では、

while(true) {
  counter++;
}

のようにして、counterが一定値を越えた場合に強制的に止めればよいのです。これで、どの程度の危険が回避できたかは定かではありません。正確にCPUの使用率を測っているわけでもありませんし、メモリについてはノータッチです。それでも、無限ループで固まることは回避できているので、少なくとも悪意のないコードでしたら、問題のない範囲と思っています。

将来的に、vmモジュールのサンドボックス環境でリソース制限までしてくれるようにはならないでしょうかね。ちょっと興味あります。

まだ誰にも使われていないRSS Pipesですが、機能を追加しました。

RSS PipesはRSSのアグリゲーターでフィルターをJavaScriptで編集します。編集はWebブラウザ上で行うので、いわゆるWikiのようなシステムです。

誰でも編集できてしまうので、そのうちSPAM行為をする利用者もでてくるかもしれません。まあ、そうなるくらいになったらうれしいわけですが。

SPAM行為をされてから対策すればよいと思っていたですが、SPAM対策がされていないことで、利用者が躊躇してしまうのは本望ではありません。そこで、簡単なロック機能を作りました。

編集するときにロックコードを入力すると、以降そのロックコードを入力しないと更新できなくなります。もちろん、ロックコードを忘れたら、本人でも更新できなくなります。そういうときは、あきらめて新しいフィルターとして再登録しましょう。「複製」ボタンがあるので、簡単です。

http://dai-shi.github.io/rss-pipes/

昨日、見つけてissueの登録をしておいた、connect-offlineの件です。

https://github.com/dustMason/connect-offline/issues/1

早速返事が来ました、Pull Requestにして欲しいと。仕方ないやるかな、と思ってみたものの、やっぱりCoffeeScriptでは書く気になれません。また、パッケージ名も分かりにくいのではないのかと考え、新しく作ることにしました。

初めは、完全互換のパッケージにしようと考えていたのですが、process.cwd()で相対パスを使っているのが気に入らず、__dirnameを使うようにしたかったので、パスの指定の互換性がなくなってしまいました。

作っているうちに他の改善案(ディレクトリの再帰探索)も思いつき、実装方法もだいぶ変わってしまったので、互換の方向性はやめました。とは言っても、基本的には同じように使えるはずです。

https://github.com/dai-shi/connect-cache-manifest

から参照できます。npmにも登録済みです。

express.jsでHTML5のキャッシュマニフェストを使おう考えています。どうせならconnectのmiddlewareにしたら便利だろうと思って調べました。

GitHubでmanifestをキーワードに色々検索したのですが、見つかりませんでした。connect-manifestという空のプロジェクトがあったくらい。

あきらめて、自分で作ろうかと思ったところで、npmで検索してみました。結果、見つけました。

https://github.com/dustMason/connect-offline

offlineという名前だから、GitHubの検索では見つからなかったようです。 Node.jsはパッケージ探しが難しいですね。

このconnect-offlineはStar数が4しかありません。あまり、キャッシュマニフェストをmiddlewareで欲しいと思う人はいないのでしょうか。それとも、名前が悪くてみんな見つけられないのでしょうか。

READMEを読むと、以前のconnectにはcacheManifestというmiddlewareがバンドルされていたようです。connectのリポジトリを探りましたが、確かに、version 1.0より前のタグには存在します。なぜ、やめたのかは分かりませんでした。(消えたファイルのgit logを見ればいいのも)

さて、connect-offlineはちょっと想像していた機能が足りなかったので、自分で修正しようと思ったのですが、ソースがCoffeeScriptだったので手を出しませんでした。(CoffeeScriptはなぜか好きになれないので)

代わりに、issueにしておきました。

https://github.com/dustMason/connect-offline/issues/1

Google Readerがなくなることが第一の理由ではないのですが、RSSってもっと便利にならないかと以前から考えていて、RSS PipesというWebサービスを作りました。

名前が似ているYahoo! Pipesから連想されるとちょっと困るような、困らないような感じですが、いわゆるRSSアグリゲーターです。フィードを表示するUIはなくて、RSSを出力します。 Feedweaver よりは汎用性があって、 Yahoo! Pipes よりは汎用性がないといったところです。

あまり比較することには意味がないですね。 RSS Pipesを作った理由は、

  • ログインせずにRSSを作れるアグリゲーターが欲しかった
  • JavaScriptでフィルターを書きたかった
  • みんなでRSSを作れるようにしたかった
  • 単に作りたかった

からです。まだできたてほやほやで、この段階でどれだけの人にアピールできるか分かりません。もし要望があればお知らせください。

RSS Pipes

上記リンクからどうぞ。

あまり使うことはないかなと思っていたのですが、ちょっと使うことにしました、PostgreSQL。

Rubyにはdata_mapperがありましたが、Node.jsでは何があるんだろうと思って調べてみました。

とりあえず、見つけたのは3つです。

これが現時点でのGitHubでのStar数順です。

でも、JugglingDBを使ってみることにしました。理由は、adapterにRedisやMongoDBなどのNoSQL系が入っていてちょっとわくわくしたからです。もしかして、将来新しいadapterを作れるのかもしれないと思いました。

しかし、このJugglingDBですが、ドキュメントが見つかりません。RailwayJSのサブプロジェクトみたいで、あまり外に目が向いていないのでしょうか。ところで、RailwayJSはcompound.jsに変わったのですね、client-sideで動くと書いてあります。面白そうですね。

さて、READMEを見ながらなんとなくやってみたら動きました。

var Schema = require('jugglingdb').Schema;
var schema = new Schema('sqlite3', { database: 'xxx.db' });
var SomeObject = schema.define('SomeObject', {
  name: {
    type: String
  },
  content: {
    type: String
  },
  flag: {
    type: Boolean
  }
});
schema.autoupdate();
SomeObject.create();

これで合っていますかね。

他の2つとの比較も知りたいですね。探せば誰かがやっているでしょう、きっと。

http://www.sequelizejs.com/はだいぶ詳しく書いてありますね。少し心が揺らぎます。


docsの下に少しドキュメントがありました。しかし、READMEに書いてあるfindOneが載っていなかったりと、網羅されていないようにも見えます。

connect-prerendererが一応完成

  • 投稿日:
  • by

AngularJSのマイルストーンにserver-side prerenderingというのがあるのですが、当分できそうにないので自分で作ってしまっています。

https://github.com/dai-shi/connect-prerenderer

express.jsのmiddlewareで使うことを想定していますが、express.jsには依存しないようにしたので、connect-prerendererです。expressとconnectの違いは、他のブログなどでも説明されていることでしょう。

何をやっているかを一言で言うと、サーバ側でjsdomを使ってJavaScriptを走らせて、レンダリング後のHTMLページをクライアントに返すというものです。

基本的なところはしばらく前にできていて、簡単なテストケースは動いていたのですが、AngularJSを動かすのがなかなか大変でした。結局、angular.jsのソースに手を入れることになりました。

AngularJSを使った簡単なテストケースも動いて、満足です。 もってきてすぐ使えるようなライブラリではないですが、たぶん世界初の取り組みでしょう。

あとははAngulaJS側でもっとうまく取り込んでもらわないとつらいところです。今は決めうち(ng-repeat="..."はOKだが、class="ng-repeat:..."は動かないとか)でやっている部分があるため。

あまり説明できずに意味不明かと思いますが、これにて。

https://github.com/dai-shi/connect-prerendererを開発中に出会った事象について書き留めておきます。

jsdomでAngularJSを使ったテストページにアクセスすることになったのですが、 angularが初期化されなくて困ってました。ぐぐったところ、

AngularJSがIE8で動かないときは

を見つけたのですが、この方法では解決せず。結局、次のようにしたら動きました。

<html ng-app class="ng-app">

id="ng-app"はあってもなくても変わらず。モジュールがある場合は、class="ng-app:<modulename>"でもうまくいくのかもしれません。

angularのソースコードを少し眺めると、

function angularInit(element, bootstrap) {
  var elements = [element],
      appElement,
      module,
      names = ['ng:app', 'ng-app', 'x-ng-app', 'data-ng-app'],
      NG_APP_CLASS_REGEXP = /\sng[:\-]app(:\s*([\w\d_]+);?)?\s/;
//-----snipped-----
  forEach(names, function(name) {
    names[name] = true;
    append(document.getElementById(name));
    name = name.replace(':', '\\:');
    if (element.querySelectorAll) {
      forEach(element.querySelectorAll('.' + name), append);
      forEach(element.querySelectorAll('.' + name + '\\:'), append);
      forEach(element.querySelectorAll('[' + name + ']'), append);
    }
  });

ってな感じで、どんな風に書いても動きそうです。なぜ、id="ng-app"でうまくいかなかったのか疑問が残りますが、追求しないことにします。


追記。

ng-appだけではダメだった理由は、ng-app="ng-app"に展開されてしまうからのようなので、ng-app="<modulename>"にすればうまくいくのかもしれません。

さらに、追記。

結局、ng-app=""で動いたので、ng-appだけだとjsdomでうまくいかないというのは正しそうです。class="ng-app:<modulename>"もうまくいきそう。id="ng-app"で動かなかった理由はおそらく、ng-appが残っていたからでしょう。

JavaScriptのお話です。node.jsに限らない話だと思いますが、node.jsでの動作を説明します。

一言で言うと、"g"オプションをつけたRegExpのtest()の呼び出しはループ(?)します。

説明するよりも、実際の動きを見てみましょう。

% node
> re = new RegExp('xyz', 'g');
/xyz/g
> s = 'aaaxyzbbbxyz';
'aaaxyzbbbxyz'
> re.test(s)
true
> re.lastIndex
6
> re.test(s)
true
> re.lastIndex
12
> re.test(s)
false
> re.lastIndex
0
> re.test(s)
true
> re.lastIndex
6

という感じで、re.lastIndexがマッチを開始するインデックスを保持しているようです。で、最後まで行ったら初めに戻ると。

"g"オプションをつけなければこんなことにはならず、lastIndexも常に0のままです。


ついでに、RegExp.test()とRegExp.exec()とString.match()とString.search()のベンチマークもしておきました。

一つは、node.js用。
https://gist.github.com/dai-shi/5169296

もう一つは、ブラウザ用。自分で作ろうかと思ったら、既にありました。
http://jsperf.com/regex-test-or-exec-or-string-search-or-match

やはり、正規表現のマッチを確認するだけなら、RegExp.test()が一番よさそうですね。

ちょっと面白い結果だったのはFirefoxのケースで、RegExp.test()とRegExp.exec()の速さがほとんど変わりませんでした。つまり、test()の内部でexec()を呼び出しちゃってる感じです。Chromeとnode.jsでは(どちらもv8だけど)差が出ているので、FirefoxのJavaScriptエンジンは改善の余地があるということでしょう。

前から思っていましたが、Chromeの正規表現の処理は速いですねぇ。Firefoxとは比べものにならないです。