Gem 选择 Oauth Gem 遇到的问题

betterthornbird · 2016年08月23日 · 最后由 betterthornbird 回复于 2016年08月23日 · 2289 次阅读

最近将项目的认证这块拿出来重写做独立的一个项目。

认证模块做以下事情

  1. Grant access token
  2. Refresh the access token
  3. Revoke the access token
  4. Check access token from client request header, to see whether it exists and if it's correct.

不做以下事情

  1. Accept registering client applications
  2. Have redirect_url or call back url for client requesting a token
  3. Grant request token
  4. Use oauth verifier, oauth nouce
  5. Generate session

简言之就是作 token provider, 而且 client 是固定的几个,不接收注册。 还有个比较土的是基于历史原因,一直使用 oauth 2.0 的一个 draft 版本,都不是以bearer开始。

在前面两个版本的实现中,第一版是用oauthoauth-provider实现;第二版是doorkeeper实现。

现在再复查下这两种 gem,基本上都有大部分功能用不上以及逻辑大段的 customise 问题。 特别 doorkeeper 觉得一个简单的逻辑被分在很多代码碎片中了,读和 debug 都很难受。

但如果自己写,可能的后果是拓展性和适用性不会好。一些命名和规范可能就不遵循 oauth2 了。

不知道大家有没有碰到类似的,gem 不通用,大部分都 customise 的情况,是自己写还是往 gem 中套呢?

有办法能把 oauth 协议升级到 RFC6749 正式版么?

建议采用第三方组建来实现,而不是自己写。doorkeeper 的确有你说的这些问题,但是如果仅仅把这些当作是作者的一种代码风格(显摆),封装好了尽量不动,不去碰就好了。

我曾是 doorkeeper 的活跃提交者。doorkeeper 的代码质量是历史原因了,毕竟好几年的项目,模型和控制器部分我已经重构过了,业务逻辑部分因为工作重心转到其他领域,没有精力维护(之前我给主要的维护者讲过其他部分的重构思路,但是他总是忽略掉...感觉主要维护者 tute 的工作重心也不在这,所以没有意愿解决结构问题,自己提交的代码很少)

不过还是建议使用 doorkeeper,实现协议是个体力活,而且 doorkeeper 其实是有大量团队不乏上市企业在使用的,所以虽然代码质量有一些糟糕,但是综合来看还是久经考验的。

另外,在我看来,如果让我在 doorkeeper 的基础上实现类似微博开放平台那样的效果,并不难,毕竟是 Ruby 自身的优势。。。难度不会高于定制 Devise。

PS. 如果真的要造个轮子,不妨来重构 Doorkeeper 吧!

#1 楼 @lgn21st 作为 token provider,要考虑向后兼容问题,有困难。

尽量用第三方的话,还有种选择是用实现了基础功能的oauth, oauth-providerdoorkeeper大而全。 @jasl 哈膜拜下,我没想要造个轮子,就是觉得把我目前的情况揉进 doorkeeper 有点困难。

#3 楼 @betterthornbird 可以,因为 Doorkeeper 的业务逻辑是和控制器分离的,你直接定制控制器和里面的 action 就可以了,扩展你需要的功能,屏蔽你不希望包含的。业务逻辑部分可以复用的就拿过来复用,不用就扔着就可以了。

或者还有个方案是参考下这个文章(不确定你是否有读过):https://blog.yorkxin.org/2013/10/08/oauth2-ruby-and-rails-integration-review

顺带提一句... 如果有精力更新 Doorkeeper 的话,我想把那堆混乱的业务逻辑整理成 ServiceObject,模型整理成 Repository 模式。Doorkeeper 的测试的代码腐化的不行了。。。这个才是打击我热情的最大阻力。。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号