Sails.js のService クラスの使いどころについて

イシュー

  • コントローラに記載している処理を共通処理として外出ししたい。
  • デフォルトで Services フォルダが作成されているので、きっとここに格納するのがよいのだろう。
  • Service クラスの使いどころについて確認する。

参考

イシュー2

  • アクセストークンを取得する処理をサービス化したい
  • コールバックURLが固定のサービスの場合に、アクセストークンの取得を共通化するには?
    • 必要なURLは3つ
      • auth url
      • callback url
      • access token 取得url
  • 問題点
    • リダイレクトされるタイプの Web API の場合に、callbackの受け取りが別メソッドになってしまい、関数の戻り値を元のメソッドに返せない。

参考

(案1)サービス化する

  • たしかにアクセストークンの取得をサービス化してしまえば、データ取得側でコールバックを待つことができる。(同期的にアクセストークンが取得できるかどうかは、あきらめる?)
  • AuthService.getAccessToken() とかでトークンストリングを取得したいんだが、、

(案2)lazy-proxy

  • module "lazy-proxy" より

    lazy is meant to be a very simple proxy route for node.js, in particular to be used with express as middleware. The idea is to make it easy to add multiple outbound routes by adding "/abbreviation/json/and-then-my-path-here" or "/abbreviation/view/page/and-then-my-path-here" - where abbreviation could be say "fb" to mean "Facebook" and then "json" would return the raw JSON (for use with client side AJAX calls) and "view" would then also append server-side view to have the data rendered on to "page".

    遅延は、Node.js、特にespressのミドルウェアとして使用されるNode.js用に、非常に単純なプロキシ経路となることを意味しています。 アイデアは、"/abbreviation(略語)/json/and-then-my-path-here(そして自分のパスをここに)" や、"/abbreviation/view/page/and-then-my-path-here"を追加することで、 複数のアウトバウンドルートを簡単に追加できるようにすることです。 ここでいう略語とは「Facebook」を意味する「fb」であり、 それに続く"json"は(クライアントサイドのAJAX呼び出しで使用するために)生のJSONを返します。 また「view」は、「page」にレンダリングされたデータを持つサーバサイドのビューが追加されます。

  • Using Passport for OAuth with Force.com より

    Basically there I’m just detecting that a URL with “fdc” is being called, and redirecting the request over to Force.com. As you can see, Passport makes it easy to handle authentication with the platform, and also flexible since if you need to add different strategies like Facebook – it’s as simple as you see above. If you want to see a more complete example, I’ve got one semi-working over at github, but I don’t have the Twitter loop working quite yet. However, in the spirit of social coding – always willing to accept merge requests…

    基本的にはそこでは「fdc」を使用したURLが呼び出されていることを検出し、Force.com経由でリクエストをリダイレクトしているだけです。ご覧のように、Passportを使用すると、プラットフォームで認証の扱いを簡単することができます。そしてFacebookのような異なるStrategyを追加する必要があったとしても柔軟に対応できます。それはあなたが上で見たのと同じぐらい簡単です。 もし、より完全な例を見たい場合は、私はgithubに片手間に作ったものを持っているが、私はまだTwitterで継続的に動いているものを持っていません。しかしながら、ソーシャルコーディングの精神で、常にマージリクエストを受け取ることを楽しみにしています。

参考

(案3)コールバック後のリダイレクトをしない

  • コールバック後のリダイレクトはhome(/)に返して、再リクエストあったらトークンを持っているかどうかを判断して処理する(いやー、ユーザは手間でしょ)

(案4)リファラーをつかう

1つずつ考える

  • 2つのリクエストがある。
    • コードを取得するリクエスト(リクエストしたら、callbackにリダイレクトされる。リクエストメソッド内でコールバックを処理できない)
    • 認証トークンを取得するリクエスト(リダイレクトされない。リクエストメソッド内でコールバックを処理できる)
  • callbackにリダイレクトされたら、何をすべきかを考える。
    • リダイレクトされる前のリクエストURLにリダイレクトするのが良さげ
    • どうやったら、リダイレクトされる前のリクエストURLを取得できるか?
    • リダイレクト前のURLをsessionに保存しておけば取得できそう。

日本語版はこちら