タイトルの通りです。割と遭遇している人いるんじゃないかなと勝手に想像しているんですが、あまり情報ないので書いてみます。

ユースケース的には、WebAPI アクセスで日付を JSON シリアライズしたものを受け取って、input[type=date]の ng−model に直接データバインドするような想定です。



## サンプルコード

(適当に書いているので動かなかったらすみません。雰囲気だけでも。)

WebAPI 側から JSON データ

```json
{
  "id": 1,
  "name": "ググレカス",
  "createdAt": "2015-02-05T00:00:00.000Z"
}
```

AngularJS の DataService 的コード(今回は factory)

```js
angular.module("app").factory("ggrks", function ($resource) {
  return $resource("/api/ggrks");
});
```

AngularJS の Controller

```js
angular.module("app").controller("ggrksController", function ($scope, ggrks) {
  // 初回データアクセス
  ggrks.query(function (data) {
    $scope.ggrks = data;
  });
});
```

AngularJS のテンプレート

```html
<input type="date" ng-model="ggrks.createdAt" />
```

このまま実行すると、このようなエラーが発生します。しょぼーん。

```sh
Error: [ngModel:datefmt] Expected `2015-02-05T00:00:00.000Z` to be a date
 ....
```

## input[type=date]にセットする model は Date 型でなければならない

公式ドキュメントをよく見ると書いてました。有効な ISO-8601 フォーマット(yyyy-MM-dd)と書いてますが、Javascript 的には Date 型に Parse してセットしなければならないようです。

[AngularJS: API: input[date]](https://docs.angularjs.org/api/ng/input/input%5Bdate%5D)

WebAPI から受け取る日付は JSON シリアライズされているので、いちいち Date 型に Perse しなければならないのか。。。本当に面倒くさい。

## 現在のベターな回答

いちいち Controller にて Parse するのはナンセンスなので、DataService(factory)で Parse することにしました。

ビルトインの`$resource`サービスには、受け取ったレスポンスを変形させて後続処理に渡す`transformResponse`があるので、今回はこちらを使ってみました。  
(Backbone.Model や Collection の`parse`相当です。)

変更後の DataService 的コード

```js
angular.module("app").factory("ggrks", function ($resource) {
  return $resource("/api/ggrks", {
    query: {
      transformResponse: transformResponse,
    },
  });

  // 受け取ったJSONをObjectにParseする
  function transformResponse(data) {
    data = angular.fromJson(data);
    data.createdAt = new Date(data.createdAt);
    return data;
  }
});
```

無理やり感がはんぱないですが、、、これで無事、input[type=date]に対して日付型をデータバインドさせることができました。  
[W3C の仕様](http://www.w3.org/TR/html5/forms.html#date-state-(type=date)でも、日付として有効な文字列は自動的にParseされるようですし、できればフレームワーク側で判断してPerseして欲しいところですが。。。

これより良いやり方ご存知の方いらっしゃいましたら、ぜひ教えてください。

### 参考文献

- [javascript - How to set right date format for editable-date - Stack Overflow](http://stackoverflow.com/questions/26825433/how-to-set-right-date-format-for-editable-date)
- [javascript - Why is my date input field in AngularJS throwing type error? - Stack Overflow](http://stackoverflow.com/questions/26853173/why-is-my-date-input-field-in-angularjs-throwing-type-error)
- [Why is my date input field in AngularJS throwing type error? | Arianna](http://hiteshtwo.org/arianna/2015/01/20/why-is-my-date-input-field-in-angularjs-throwing-type-error/)

少し古いですがこちらに書かれている、dateInput 用のカスタム directive を作成する方法が良さそうな気がします。(未検証)

[javascript - Angular.js and HTML5 date input value -- how to get Firefox to show a readable date value in a date input? - Stack Overflow](http://stackoverflow.com/questions/18061757/angular-js-and-html5-date-input-value-how-to-get-firefox-to-show-a-readable-d)

AngularJSでinput[type=date]にデータバインドしようとしてError: [ngModel:datefmt]で怒られて困っている人向けの小ネタ

AngularJS を利用するメリットの 1 つとして、AngularJS が内包している[$resource](https://docs.angularjs.org/api/ngResource/service/$resource)を利用することで、バックエンドが提供する REST API との対話部分が簡潔に記述できることが挙げられます。

ところが、$resource の表面的な振る舞いを理解しただけでは、意外なところにハマりポイントがあるものです。今日はその辺りを少し紹介します。



[AngularJS Advent Calendar 2014 \- Adventar](https://adventar.org/calendars/350)16 日目の記事です。

- 15 日目[AngularJS - Promise を使おう - Qiita(@teyosh)](http://qiita.com/teyosh/items/d7d3c17f954318c88882)
- 17 日目[AngularJS 1.3 へのアップデート(@kon.yuichi)](https://note.mu/konpyu/n/n1eb6c13c69d6)

## $resource の使い方

> $resourceの細かい内容については[本家ドキュメント](https://docs.angularjs.org/api/ngResource/service/$resource)か[Qiita](http://qiita.com/search?utf8=%E2%9C%93&sort=rel&q=angular+%24resource)でググるといいと思います。

$resourceにURLを渡すだけで以下のような基本的なWebAPIが実行できるようになります。$resource を使う場合、`service`か`factory`の中で利用することがほとんどですね。

```
{
  'get':    {method:'GET'},
  'save':   {method:'POST'},
  'query':  {method:'GET', isArray:true},
  'remove': {method:'DELETE'},
  'delete': {method:'DELETE'}
};
```

また、`PUT`や異なるエンドポイント(URL)など、先ほどの基本的な API をカスタムしたい場合は、`actions($resourceに渡す3つめの引数)`で使うことで簡単に API を追加できるので、使いこなすことが出来るとバックエンドとの WebAPI 連携の部分で非常に重宝します。

**user.service.js**

```js
function User($resource) {
  return $resource('/api/user/:id', {
    id: '@id'
  }, {
    //PUT /api/user/:id
    updata: {
      method: 'PUT'
    },
    //GET /api/user/me
    me: {
      url: '/api/user/me'
    }
  });
});

angular.module('app').factory('User', User);
```

## "$resource の戻り値は実際の値ではない、参照である。"というハマりポイント

> し、しらなかったぜ・・・

結論から言うと、$resource の戻り値は**参照**なので、そこから直接プリミティブ型の値を取り出して他で使う場合には、タイミングによって`undefined`になったりならなかったりするということです。  
(ほとんどの場合、Object をデータバインドして参照経由で実際の値を見ているので、あんまり問題にならないと思います。)

このハマりポイント、あまり遭遇するケースはないかも知れませんし、原因がわからないままなんとなく回避している人もいるかと思います。私の場合、ui-router の`resolve`を使って controller で必要な情報を取得することが多かったため、よく遭遇していました。

**app.route.js**

```js
function Router($stateProvider) {
  $stateProvider.state("main", {
    url: "/",
    templateUrl: "app/main/main.html",
    controller: "MainCtrl",
    controllerAs: "vm",
    // ここでUserリストを事前に取得
    resolve: {
      user: function (User) {
        return User.get({
          id: 1, // ✌(-‿-)✌
        });
      },
    },
  });
}

angular.module("app").config(Router);
```

**main.controller.js**

```js
function MainCtrl(user, socket) {
  var vm = this;
  vm.user = user;

  // WebSocketのチャットルームに参加
  // [TODO]タイミングによってuser.roomIdがundefined
  socket.emit("chatRoom:join", {
    id: user.roomId,
  });
}

angular.module("app").controller("MainCtrl", MainCtrl);
```

こちらの Stack Overflow を参考にしたのですが、改めて[公式ドキュメント](https://docs.angularjs.org/api/ngResource/service/$resource#usage_returns)読むと書いてありましたね。

> It is important to realize that invoking a $resource object method immediately returns an empty reference  
> ($resource を実行するとね、すぐに空の参照を返すから、心して使え。このボケがぁ！・・・超約)

[json - AngularJs using $resource service. Promise is not resolved by GET request - Stack Overflow](http://stackoverflow.com/questions/20008244/angularjs-using-resource-service-promise-is-not-resolved-by-get-request/20008380?stw=2#20008380)

## $resource との正しい(安全な)付き合いかた

より安全なコードの書き方は、$resourceが返すpromiseを、次のように`$promise`から取り出して処理すると安全です。

**main.controller.js**

```js
function MainCtrl(user, socket) {
  var vm = this;

  user.$promise.then(function (user) {
    vm.user = user;
    // WebSocketのチャットルームに参加
    socket.emit("chatroom:join", {
      id: user.roomId,
    });
  });
}

angular.module("app").controller("MainCtrl", MainCtrl);
```

各コントローラで promise を処理するのが面倒な場合は、15 日目[AngularJS - Promise を使おう - Qiita(@teyosh)](http://qiita.com/teyosh/items/d7d3c17f954318c88882)で紹介されているような、promise を処理するための factory を作ってラップするといいと思います。  
(たしか、<a target="_blank" href="https://www.amazon.co.jp/gp/product/4873116678/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=4873116678&linkCode=as2&tag=mitsuruog-22&linkId=bdd0c9b0152b6260907ab4e64036c67a">AngularJS アプリケーション開発ガイド</a><img src="//ir-jp.amazon-adsystem.com/e/ir?t=mitsuruog-22&l=am2&o=9&a=4873116678" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />のサンプルもそうなってたはず。)

<iframe style="width:120px;height:240px;" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" src="https://rcm-fe.amazon-adsystem.com/e/cm?ref=tf_til&t=mitsuruog-22&m=amazon&o=9&p=8&l=as1&IS1=1&detail=1&asins=4873116678&linkId=d152ad4c622d40713fb4691ba63bcb90&bc1=000000&lt1=_blank&fc1=333333&lc1=0066c0&bg1=ffffff&f=ifr">
    </iframe>
    
## まとめ

今日は$resource を使うと便利ですが、ちょっとハマるよという話をしました。

AngularJS はフロントエンドの実装を大変楽にしてくれるフレームワークです。しかし同時に、その裏でフレームワークが隠蔽している技術の難しさを軽視することはできないと改めて思い知りました。

今回のようなケースは、Javascript の実装についてある程度の経験がないとあたりがつけにくい問題だったと思います。(ドキュメント読めは置いといて・・・)  
AngularJS に限らず、JS フレームワークを利用する場合は、チームの中に本当の Javascripter(Hacker ともいう)がいるかが、成功の秘訣のような気がします。

AngularJSの$resourceの意外なハマりポイント

AngularJS への改宗が完了した「mitsuruog」です。  
AngularJS に限らず Single page application(以下、SPA)を構築した場合、認証(Authenticate)とその後の WebAPI での証明情報(Credential)の受け渡し方法について最近悩んでいます。  
調べていたら Json Web Token(以下、JWT)を利用した方法が[Cookies vs Tokens. Getting auth right with Angular.JS](https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/)で紹介されていて、試してみると結構使えそうでしたので紹介してみます。



## 目次

## 1.WebAPI での証明情報の受け渡しの重要性

Web アプリケーションのフロントエンドを SPA で構築した場合、バックエンドへのアクセスは通常 WebAPI 経由になります。JSP 時代のようなフロントとバックが密結合した状態ではなく、SPA での WebAPI は一般的に広く公開されているものです。  
URL を知っていれば誰でもアクセスできる性質を持っています。(企業システムは VPN という閉じた世界で利用されることが多いもの事実ですが)

バックエンドではユーザ認証を行い、その証明情報を元に、不正なアクセスを除外したり、正しいアクセスに対して機能に対する認可を行わなければなりません。そのため、SPA での証明情報の受け渡しは非常に重要です。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/JWT2.png)

## 2.Token を利用した証明情報の受け渡し

まず、従来の Cookie を利用したやり方について簡単に説明します。ただし、「Token vs Cookie」のような関係ではなく、両者をうまく組み合わせた方がいいような気が今はしています。(ちょっと、まだ検証が足りてません)

Cookie を利用した証明情報とは「セッション ID」をイメージするいいと思います。この方法の特徴は、認証がバックエンドに依存していることです。つまり、バックエンド側では、認証された個人情報やロールをセッション ID に紐づけて保持する必要がありました。そのため、Web アプリケーションはセッションをどこで保持するかを意識した設計を行う必要がありました。

それに対し、Token を利用した方法では認証はバックンドに依存しません。ここでの「Token」とは「**電子署名**」の一種です。こちらが Token を利用した場合の証明情報の受け渡しフローです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/JWT3.png)

まず認証後に、暗号学的ハッシュ関数(SHA-256 など)を使って暗号化した Token を生成して渡します。このときにロールや個人情報を Token に含めることがポイントです。  
フロントエンドは WebAPI アクセスする際に HTTP ヘッダーに Token を設定します。WebAPI アクセスを受けたバックエンドは Token を秘密鍵を使って復号し、Token が改ざんされていないことを確認することで、正しいアクセスであることを確認します。

Token には個人情報やロールが含まれているため、バックエンドにて認証の状態を保持する必要がありません。**同じ秘密鍵・暗号学的ハッシュ関数があれば異なるバックエンドであっても Token を受け入れることが可能**です。

これは、バックエンドがクラウド・オートスケールアップしていくような流れの中で、従来ようなセッションを意識しない証明情報の受け渡し方法として注目しています。

## 3.実現するためのコア技術、JWT(Json Web Token)とは

JWT とは、Json 形式の claims(※)を暗号化して URL で安全に送れるようにしたものです。

> (※)claims(クレーム)：うーん、いまいちイメージが湧かない。たぶん、上の個人情報とかロールとかそんな印象だと思います。

JWT の構造は JSON Web Signature(JWS)と JSON Web Encryption(JWE)の 2 つ。
(ちなみに上の[Cookies vs Tokens. Getting auth right with Angular.JS](https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/)は JWS です。)
JWS 構造の JWT を簡単に図解すると「ヘッダー」「クレームセット」「署名」の 3 部構成になっています。それぞれ Base64URL エンコードされており、署名はヘッダー・クレームセットから生成します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/JWT1.png)

クレームセット部分には、個人情報やロールなどカスタム項目を設定します。これ以外に JWT の仕様で以下のような項目(クレーム名)が標準で定義されています。

- **iss:** Token 発行者
- **sub:** Token を利用するアプリケーション名など。(iss とセットで発行者側を識別するために使う)
- **aud:** この Token を利用することが想定される対象の識別子。例)このブログでの利用想定の場合は「blog.mitsuruog.info」のようになる(はず)
- **exp:** Token の有効期間
- **jti:** Token の一意性を保証するための ID を設定する

JWT についての詳細は下記のブログを参照してください。おそらく私よりかなり正確な理解をされていると思います。(JWT の日本語情報はかなり希少です)
特に hiyosi’s blog さんの記事は JWT の仕様と JWS 構造の JWT の作成・検証(ただし scala)まで含まれており、非常に有用です。

[JSON Web Token (JWT) - OAuth.jp](http://oauth.jp/blog/2012/10/26/json-web-token-jwt/)
[JWT について簡単にまとめてみた - hiyosi’s blog](http://hiyosi.tumblr.com/post/70073770678/jwt)

## 4.Token を利用した場合の課題など

Token を利用した場合の課題など、列挙しておきます。
私自身、どれだけ理解しているか不安ですので、ご意見いただけると嬉しいです。

### 秘密鍵の管理

JWT を利用した場合、その Token の正当性は暗号化する際の秘密鍵がすべてです。Token がフロントエンドで分散して保持されているため、なんからの方法で秘密鍵が外部に漏れてしまった場合の被害は甚大になると思われます。
スケールアウトしている場合など、秘密鍵の変更を素早く同期できる方法が必要です。

### リフレッシュトークン

おそらく、Token には何らかの有効期限を設けて運用すると思われます。Token の有効期限が切れた場合、Cookie を使っていた場合のセッションタイムアウトと同じ事態になりますので、OAuth2 のリフレッシュトークンのような仕組みが必要になると思います。
これは課題とではなく、やるべきことですね。できればその辺りまでライブラリでカバーして欲しいです。

### セキュリティ

Cookie の場合、CSRF、セッションハイジャックなどセキュリティ脆弱性がありました。Token を使った場合は、Cookie を利用していないため、Cookie の仕組みによる脆弱性はないと思われますが、他にどのような危険性があるかはまだ未知数です。(専門家の人助けてー)

特に、URL パラメータに Token 付与した場合とか、そもそも誤送信した時点でアウトなので、そもそもそのような利用シーンは想定しない方がいいか、などもう少し利用する上で検討しなければならない項目の見落としがありそうです。

## 5.まとめ

JWT を利用した証明情報の受け渡し方法いかがでしたでしょうか。
国内情報が少なくて、正直どこまで信頼できるか手探りの状態です。今後も引き続き WebAPI 周りの認証とか証明情報の受け渡しとか注視していきます。

最近、AngularJS で各ソーシャル対応の Token ベース認証ライブラリが出ましたので、こちらを使ってみるのもいいかと思います。
[sahat/satellizer](https://github.com/sahat/satellizer)

こちらが参考資料です。

- **Blog**
  - [Cookies vs Tokens. Getting auth right with Angular.JS](https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/)
  - [JSON Web Token (JWT) - OAuth.jp](http://oauth.jp/blog/2012/10/26/json-web-token-jwt/)
  - [JWT について簡単にまとめてみた - hiyosi’s blog](http://hiyosi.tumblr.com/post/70073770678/jwt)
- **仕様**
  - [JSON Web Token (JWT) draft25](http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html)
  - [JSON Web Token (JWT) -日本語 draft11-](http://openid-foundation-japan.github.io/draft-ietf-oauth-json-web-token-11.ja.html)
- **ライブラリ**
  - [auth0/express-jwt(nodejs/express ミドルウェア)](https://github.com/auth0/express-jwt)
  - [auth0/node-jsonwebtoken(nodejs/JWS 形式の JWT 作成)](https://github.com/auth0/node-jsonwebtoken)
  - [sahat/satellizer(javascript/AngularJS 用の Token ベース認証ライブラリ)](https://github.com/sahat/satellizer)

Tag: webapi

AngularJSでinput[type=date]にデータバインドしようとしてError: [ngModel:datefmt]で怒られて困っている人向けの小ネタ

AngularJSの$resourceの意外なハマりポイント

JWT(Json Web Token)を利用したWebAPIでのCredentialの受け渡しについて