Max*_*ams 6 authentication ruby-on-rails cross-domain
这听起来有点邪恶,但我要忍受.它也不是特定的Rails问题,即使这两个站点使用Rails.(对这两件事情提前道歉)
想象一下两个网站都使用Ruby on Rails:
mysite.com,我是一名开发人员,在更改代码等方面拥有完全访问权限,并且还有管理员登录,因此我可以管理用户帐户.
theirsite.com,我有一个管理员登录但没有开发访问权限.我知道管理它的人但我宁愿不出于政治原因向他们提出任何好处.然而,这是一个选择.
在每个网站上使用我的管理员登录,我为同一个人创建了一个用户帐户.当他们登录mysite.com时,我希望能够提供一个按钮,将它们直接登录到theirsite.com.我将他们用于theirsite.com的用户名和密码存储在mysite.com数据库的用户记录中,以方便这一点.该按钮是表单的提交按钮,该表单复制了theirsite.com登录页面上的表单,其中包含用户名和密码的隐藏字段.
绊脚石是theirsite.com使用authenticity_token变量处理CSRF,当登录从mysite.com提交时,验证失败.
我第一次试图通过这个,在mysite.com控制器中加载带有表单的页面,刮掉theirsite.com登录页面以获取真实性令牌,然后将其插入我的表单.但这不起作用.
如果我在两个浏览器选项卡中加载theirsite.com登录页面和带有远程登录按钮的mysite.com页面,并手动将theirsite.com表单中的authenticity_token复制到mysite.com表单,那么它可以正常工作.这是因为(我认为)authenticity_token通过cookie链接到我的会话,当我在同一个浏览器中完成所有会话时,会话匹配,但是当我通过抓取从theirsite.com获取真实性令牌时(使用Nokogiri但是我可以使用curl而不是相同的会话.
问题A)所以,我认为我还需要设置一个cookie,以便会话在浏览器和我所做的Nokogiri请求之间匹配.但是,这可能是不可能的,而且正是反CSRF系统旨在打败的那种东西.是这样的吗？
问题B)让我说我决定,尽管有政治因素,我还是要求theirsite.com的所有者进行一些小改动,以便在我们知道他们的theirsite.com用户名和密码时让我们将用户登录到theirsite.com .我可以要求他们做出的最小,最安全的变化是什么？
请随意说"脱掉你邪恶的黑帽子",我认为这是一个有效的回应.问题有点狡猾.
这应该不难做到。
您需要将 ajax GET 请求发送到他们的注册页面，使用 javascript 复制authenticity_token，然后将 ajax POST 发送到实际登录路由，该路由使用正确的凭据和authenticity_token 创建会话。
一个棘手的部分是找出他们的登录路线。尝试一下/sessions/new，也许他们在表单中有 url，所以看看那里的 html。祝你好运！
另一个棘手的部分是了解参数通常如何发送。查看表单的 html。如果所有input标签的名称前面都有user_，那么您需要以类似的方式构造参数；IE user_email，user_password。
完全可以获取 crsf 令牌并提交您自己的表单（因为任何人都可以访问登录页面！）。然而，很难知道他们安排的细节。猜测和检查并不是一个太糟糕的选项（同样，/sessions/new这就是我登录的方式；您还应该尝试您的路线，看看他们是否有类似的路线。）
如果这不起作用，请尝试查看他们的 github 帐户！很可能他们每月还没有支付 7 美元，而且它是向公众开放的。您将可以轻松地以这种方式查看它们的路由和参数解析。
祝你好运！
| 归档时间： |
|
| 查看次数： |
447 次 |
| 最近记录： |