当您知道用户名和密码时,通过反CSRF将用户登录到站点

这听起来有点邪恶,但我要忍受.它也不是特定的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 .我可以要求他们做出的最小,最安全的变化是什么？

请随意说"脱掉你邪恶的黑帽子",我认为这是一个有效的回应.问题有点狡猾.