4

だから私は、いくつかのリモートタッチスクリーン以外に、他の1つのレールアプリケーションとのみ通信するアプリを作成しています。このアプリは、これらのタッチ スクリーンのいずれかを所有する個人と管理者のみが利用できます。したがって、Twitter、Facebook などでサインインできることの意味がわかりません。ただし、1. ユーザーを認証し、2. できるようにするために、リクエスト/アクセス トークンを使用したある種の http 認証が必要です。どのユーザーがサーバーと通信しているか (およびいつ) を取得します。私は約 1 週間 (私は Rails の初心者です) Oauth や omniauth などの調査に費やしましたが、次の 2 つのことを尋ねています。

  1. 私は自分の 2 つのアプリ セット間で認証を行っているため、どの gem が私の状況に最適でしょうか?

  2. リクエスト/アクセス トークンのロジックはどこに記述しますか?

私は本当にこれのための良いチュートリアルを見つけることができません

4

1 に答える 1

13

既存の ID プロバイダーとの統合が必要ない場合は、Deviseで十分です。ユーザー アカウントを管理するための簡単な方法を提供し、ユーザーは電子メール アドレスとパスワードを使用してログインします。

別のアプリに対して認証するのは難しくなります。

方法 1

2 つのアプリ間の通信があまり必要ない場合は、ユーザーをメイン アプリにログインさせてから、ユーザーがセカンダリ アプリで使用できる一時トークンを生成できます。最後に、セカンダリ アプリに、メイン アプリとのすべての通信にこの文字列を含めるようにします。実際の例には、GitHub の Web フックで使用できる API キーをユーザーに提供する Pivotal Tracker が含まれます。

些細な例

  1. ユーザーは Main.com にアクセスし、電子メールとパスワードを使用してログインします。
  2. Main.com は、ユーザーの一時的なトークンを生成します。
  3. ユーザーは Sub.com にトークンを渡します。
  4. Sub.com は Main.com に連絡します。<user>:<token>@main.com/some/path?some=query

これには多くのセキュリティ上の問題がありますが、重要でないユース ケースには十分です。SSL を使用してトークンを保護することもできます。

方法 2

ただし、方法 1 はあまり安全ではありません。より堅牢で安全なソリューションは、メイン アプリを OAuth プロバイダーにし、OAuth を使用してメイン アプリに対してセカンダリ アプリを認証させることです。これは、 DoorKeeperでそれを行う方法を説明するRailscastです。セカンダリ アプリで OmniAuth を使用できます。

于 2013-08-14T20:27:50.043 に答える