AngularJS で認証の仕組みをどう扱うのか? これが悩ましい問題。 サンプルのAngularJS の認証の仕組みを見ると、Cookie を使ってサーバとやりとりをしているが、これだと前回紹介した理想的な Rails, AngularJS 環境の構築 - ボクココ のようなAPIとしてのきり分けができず、結局Cookieを使ったWeb用のソースがサーバ側で必要になってしまう。これではスマホアプリを作るときに同じAPIのコードを使えない。
てことで認証はOAuthのみで扱うようにする。Rails にはOAuth用の素晴らしいライブラリ、「Doorkeeper」というのがOSSであるので、これを使う。 Doorkeeperがアクセストークンの発行、アクセストークンのチェック、外部アプリ連携など、一通りのAPIによるOAuth認証の枠組みを提供してくれる。そしてソースは割とよみやすい。 今回はOAuthの中でもResource Owner Password Credentials Grant で認証をする。要はログインIDとパスワードを送って、アクセストークンをもらう方法だ。もちろんDoorkeeper にはAuthorization Code Grantの認証方法も提供されている。 Doorkeeperについてもっと知りたければ、RailsCastsの一読をお勧めする。
DoorkeeperはDeviseやSorceryとの連携が可能だ。Sorceryに関しては前回紹介した。Rails の認証で Devise ではなく Sorcery という選択 - ボクココ
Railsってこういうのがライブラリとして普通にあるのがすごいよね。このレールに乗って最短距離で作りたいものを作れる感、素晴らしい。
アプリの切り分け
しかし、ここで全てをAngularJS, OAuth, JSONレスポンスなフロント・バックエンド構成にすると問題になることがいくつかある。
その他諸々の事情により、機能を切り分けてアプリを作ったほうがいいと考えた。やはりAPIサーバのみのWebアプリ開発は厳しい。 構成としては以下の通り。
従来のRailsアプリで作るページ
- SEO対策としてのトップページ(What is, How to, How muchなページ)
- そのままの流れで新規登録をしてもらう
- パスワード忘れ、退会など
- 「このアプリに以下のアクセスを許していいですか」という外部アプリOAuth認証ページ
- サービスによっては課金
アプリ自体
- HTML/CSS/JavaScript のみの静的ファイル構成。
- ログイン。会員登録されている前提
- Webアプリそのもの
APIサーバの設定でCORS(Cross-Origin Resource Sharing)は必須かな。 取得したアクセストークンは LocalStorage or CookieにJavaScriptで保存する。
アプリを2つに分けるのはちょっと面倒かもしれないけど、考えてみるとGmailなど、Googleアプリも同様の構成になっている。Gmail内で新規登録やユーザ情報変更などはしない。 ということでAngularJS で本格的にサービスを作るなら、この構成が理想的ではないだろうか。