我最终编写了 this solution 编码 - 将其发布在这里以防它可以帮助其他人(或以防其他人有改进它的建议)。
以下是一些逻辑:
该应用最初是使用 Clearance 构建的,用于身份验证/授权,因此坚持使用 Clearance 可以让现有的名称/密码和现有的授权代码继续工作。
用户识别
Clearance 使用电子邮件地址作为主要标识符。该应用程序需要每个用户都有一个电子邮件地址用于其他目的,因此我们将继续使用电子邮件作为主要用户 ID。当用户注册时,我们从 FB 获取它,如果他们通过 FB 注册。 (请注意,omniauth-facebook 请求一组可配置的 FB 权限;默认情况下包括对电子邮件地址的访问)。
用户注册
新用户可以选择创建电子邮件/密码组合,或通过 FB 注册。 Omniauth-facebook 用于针对 FB 进行身份验证(并允许随着时间的推移扩展到其他身份验证系统)。我们从 FB 获取用户数据(姓名、电子邮件等),以及 Facebook 身份验证令牌。通过这种方式进行身份验证的用户无需提供密码。选择在没有 FB 的情况下注册的用户提供电子邮件地址、密码和其他用户数据。通过 FB 登录创建的用户将被带到用户/编辑处,以完成提供我们无法从 FB 获取的任何个人资料详细信息。我们还保留了现有的用户注册机制,允许用户手动提供电子邮件/密码/其他详细信息。
用户验证
Clearance 验证用户的电子邮件地址。我们覆盖的密码_可选?功能本质上绕过了他们的密码验证。对于生产用途,此解决方案应包括用户验证以实现“您必须至少拥有一个有效的 pwd 或有效的omniauth 凭据”
会话创建
使用 Clearance 的会话模型(将 remember_token 存储在 cookie 中)。
覆盖会话控制器以添加通过 FB 进行签名的方法。从 FB 路由到此方法的回调,该方法创建/更新用户的身份验证数据并调用 Clearance 的 sign_in(user)
授权
Clearance 的简单模型被保留:“授权”过滤器本质上只是检查有效用户是否已登录,并提供 current_user 帮助器。
FB 使用情况
用户的 FB 令牌在 FB 身份验证后存储(在属于用户的身份验证对象中)。 Koala 用于其他 FB 请求(例如发布到用户的墙)...此处省略详细信息;我没有做任何特别的事情。
FB 令牌刷新
FB 令牌会定期过期(并且不推荐使用 FB 的“离线访问”角色)。用户登录时会刷新令牌,但令牌可能会在应用会话到期之前失效(当用户退出 FB、更改其 FB 密码或令牌过期时)。我正在研究如何在登录流程之外定期更新 FB 令牌,但这似乎超出了此答案的范围。