Gem 选择 Oauth Gem 遇到的问题
最近将项目的认证这块拿出来重写做独立的一个项目。
认证模块做以下事情
- Grant access token
- Refresh the access token
- Revoke the access token
- Check access token from client request header, to see whether it exists and if it's correct.
不做以下事情
- Accept registering client applications
- Have redirect_url or call back url for client requesting a token
- Grant request token
- Use oauth verifier, oauth nouce
- Generate session
简言之就是作 token provider, 而且 client 是固定的几个，不接收注册。
还有个比较土的是基于历史原因，一直使用 oauth 2.0 的一个 draft 版本，都不是以bearer开始。
在前面两个版本的实现中，第一版是用oauth和oauth-provider实现；第二版是doorkeeper实现。
现在再复查下这两种 gem，基本上都有大部分功能用不上以及逻辑大段的 customise 问题。 特别 doorkeeper 觉得一个简单的逻辑被分在很多代码碎片中了，读和 debug 都很难受。
但如果自己写，可能的后果是拓展性和适用性不会好。一些命名和规范可能就不遵循 oauth2 了。
不知道大家有没有碰到类似的，gem 不通用，大部分都 customise 的情况，是自己写还是往 gem 中套呢？
有办法能把 oauth 协议升级到 RFC6749 正式版么？
建议采用第三方组建来实现，而不是自己写。doorkeeper 的确有你说的这些问题，但是如果仅仅把这些当作是作者的一种代码风格（显摆），封装好了尽量不动，不去碰就好了。
我曾是 doorkeeper 的活跃提交者。doorkeeper 的代码质量是历史原因了，毕竟好几年的项目，模型和控制器部分我已经重构过了，业务逻辑部分因为工作重心转到其他领域，没有精力维护（之前我给主要的维护者讲过其他部分的重构思路，但是他总是忽略掉...感觉主要维护者 tute 的工作重心也不在这，所以没有意愿解决结构问题，自己提交的代码很少）
不过还是建议使用 doorkeeper，实现协议是个体力活，而且 doorkeeper 其实是有大量团队不乏上市企业在使用的，所以虽然代码质量有一些糟糕，但是综合来看还是久经考验的。
另外，在我看来，如果让我在 doorkeeper 的基础上实现类似微博开放平台那样的效果，并不难，毕竟是 Ruby 自身的优势。。。难度不会高于定制 Devise。
PS. 如果真的要造个轮子，不妨来重构 Doorkeeper 吧！
#3 楼 @betterthornbird 可以，因为 Doorkeeper 的业务逻辑是和控制器分离的，你直接定制控制器和里面的 action 就可以了，扩展你需要的功能，屏蔽你不希望包含的。业务逻辑部分可以复用的就拿过来复用，不用就扔着就可以了。
或者还有个方案是参考下这个文章（不确定你是否有读过）：https://blog.yorkxin.org/2013/10/08/oauth2-ruby-and-rails-integration-review
顺带提一句... 如果有精力更新 Doorkeeper 的话，我想把那堆混乱的业务逻辑整理成 ServiceObject，模型整理成 Repository 模式。Doorkeeper 的测试的代码腐化的不行了。。。这个才是打击我热情的最大阻力。。