私はこのソリューションをコーディングすることになりました-他の人を助けることができる場合に備えて(または他の人がそれを改善するための提案を持っている場合に備えて)、ここに投稿します.
ロジックの一部を次に示します。
このアプリは元々、認証/承認のために Clearance を使用して構築されていたため、Clearance を使用することで、既存の名前/パスワードと既存の承認コードを引き続き機能させることができます。
ユーザー識別
Clearance は、電子メール アドレスを主要な識別子として使用します。このアプリでは、各ユーザーが他の目的のために電子メール アドレスを持っている必要があるため、引き続き電子メールをプライマリ ユーザー ID として使用します。ユーザーが FB 経由で登録した場合は、登録時に FB から取得します。(omniauth-facebook は設定可能な一連の FB 権限を要求することに注意してください。メール アドレスへのアクセスはデフォルトで含まれています)。
ユーザー登録
新規ユーザーは、電子メール/パスワードの組み合わせを作成するか、FB を通じて登録するかを選択できます。Omniauth-facebook は、FB に対する認証に使用されます (また、時間の経過とともに他の認証システムへの拡張を可能にするため)。FB からユーザー データ (名前、電子メールなど) と Facebook 認証トークンを取得します。この方法で認証されたユーザーは、パスワードを入力する必要はありません。FB なしで登録することを選択したユーザーは、電子メール アドレス、パスワード、およびその他のユーザー データを提供します。FB ログインによって作成されたユーザーは、FB から取得できないプロファイルの詳細を提供するために user/edit に移動します。また、既存のユーザー登録メカニズムを維持し、ユーザーが電子メール/パスワード/その他の詳細を手動で提供できるようにします。
ユーザー検証
Clearance は、ユーザーの電子メール アドレスを検証します。オーバーライドされた password_optional? 関数は基本的にパスワードの検証をバイパスします。本番環境で使用する場合、このソリューションには、「有効な pwd または有効な omniauth クレデンシャルの少なくとも 1 つが必要です」を実装するためのユーザー検証が含まれている必要があります。
セッションの作成
Clearance のセッション モデルが使用されます (remember_token を Cookie に保存します)。
FB 経由で署名するためのメソッドを追加するために、セッション コントローラーがオーバーライドされます。FB からのコールバックはこのメソッドにルーティングされ、ユーザーの認証データを作成/更新し、Clearance の sign_in(user) を呼び出します
Authorization
Clearance の単純なモデルは維持されます。「authorize」フィルターは、基本的に、有効なユーザーがサインインしていることを確認するだけであり、 current_user ヘルパーが提供されます。
FB
の使用法 ユーザーの FB トークンは、FB 認証後に (ユーザーに属する認証オブジェクトに) 保存されます。Koala は、他の FB リクエスト (たとえば、ユーザーのウォールへの投稿) に使用されます...詳細はここでは省略されています。私は特別なことはしていません。
FB トークンの更新
FB トークンは定期的に期限切れになります (FB の「オフライン アクセス」の役割は廃止されます)。ユーザーがログインするとトークンは更新されますが、アプリ セッションが期限切れになる前に (ユーザーが FB からログアウトしたり、FB パスワードを変更したり、トークンの有効期限が切れたりすると)、トークンが無効になる場合があります。サインイン フローの外で FB トークンを定期的に更新する方法に取り組んでいますが、それはこの回答の範囲外のようです。