将第三方站点的 HTTP 会话从服务器传递到客户端
假设我的 Web 应用程序代表向我的应用程序提供凭据的用户，以便该应用程序可以对第三方服务进行 API 调用。顺便说一句，这是为了向第三方网站发布产品报价（有点像 eBay，但规模较小）。
现在，使此发布变得容易的一种超级方便的方法是重用第三方服务必须接受经过身份验证的用户提供的产品的复杂 Web 表单。这个想法是填充他们的 Web 表单并将客户端浏览器重定向到它，以便用户可以使用复杂且熟悉的 Web 表单编辑内容。这将是最好的用户体验和最少的实施工作。
然而，这并不是一个有记录的方法。更重要的是，它不能以简单的方式工作，例如从请求参数（GET 或 POST）填充表单字段。网络表单并不是这样工作的。
可能还有其他选择。我的应用程序可以代表用户打开与第三方应用程序的会话，提交所有数据，以便将其存储在他们的数据库中，然后向用户的浏览器发送接管我的服务器应用程序在他的服务器上打开的会话所需的所有数据。代表。请注意，我还没有尝试过这个；我认为如果第三方应用程序将会话与 IP 号码绑定（无论是否合理，应用程序可能会这样做），它可能会失败。
但是，是否可以让打开 HTTP 会话的服务器程序将接管该会话所需的所有信息写入 HTML/Javascript 文档并将该文档发送到用户的浏览器，其中 Javascript 执行并组装请求，例如直接在第三方表单上使用浏览器时组成的，我一直在使用 HttpFox 进行观察？
所有的信息，即HTTP的一切；显然不可能将服务器的IP号传递给客户端......但是所有cookie和参数。然后，在浏览器中执行的 JavaScript 必须使用我以某种方式在文档中传递的信息（可能在脚本部分中）来编写对第三方网站的请求，该请求直接进入服务器应用程序已打开的会话。这意味着源自我的域的文档将设置 cookie（添加请求标头），然后让用户的浏览器执行该请求。
换句话说，技术上是否可以将会话从服务器传递到客户端？
你会如何用 JavaScript 做到这一点？
进行更新
根据另一个问题的答案 ：您无法为其他域设置 cookie。允许这样做会带来巨大的安全缺陷。这表明我不是前端开发人员。
还没有放弃。其中有 XmlHttpRequest 对象。也许这可以被滥用于我的邪恶目的？
第二次更新
所以我尝试了 XmlHttpRequest。坏消息（对于我和这个特殊情况）：看起来它无法使用 XmlHttpRequest 工作，因为（使用当前的 Firefox）我精心伪造的请求被重写，根据似乎预计成为跨源资源共享的 W3C 标准，因此 Cookie< /code> 标头很简单已删除的虚拟标头 Moin 和 Gurke 缩减为 Access-Control-Request-Headers: gurke,moin。坦率地说，这严重破坏了游戏。我很失望。
Let's say my web app is acting on behalf of users who give their credentials to my app so the app can make API calls to a third party service. Incidentally, this is for posting product offers to this third party site (bit like eBay, but on a smaller scale).
Now one super convenient way to make this posting easy would be to reuse the sophisticated web form that third party service has to accept product offers for authenticated users. The idea is to populate their web form and redirect the client browser to it so the user can edit things there using the sophisticated and familiar web form. This would be the best user experience and the least implementation work.
However, it is not a documented way to do it. What's more, it doesn't work in the simple way, like populating the form fields from request parameters (GET or POST). The web form just doesn't work that way.
There might be an alternative. My app could open a session with the third party app on the user's behalf, submit all data so it is stored in their database, and then send the user's browser all the data it needs to take over the session that my server app opened on his behalf. Note that I haven't tried this yet; and I reckon it might fail if the third party app ties a session to an IP number (which, whether sound or not, an app might do).
But wouldn't it be possible to have the server program opening the HTTP session write all the information needed to take over that session to an HTML/Javascript document and send that document to the user's browser, where the Javascript executes and assembles a request such as composed when using a browser on the third-party form directly, which I've been observing using HttpFox?
All the information, that is everything HTTP; it's obviously not possible to pass the server's IP number to the client ... But all cookies and parameters. The Javascript executing in the browser would then have to use the information I'd be somehow passing in the document (probably in the script part) to compose a request to the third party web site that goes right into the session the server app has opened. This would mean that a document originating from my domain would set cookies (add request headers) to then have the user's browser execute that request.
So in other words, is it technically possible to pass a session from the server to the client?
How would you do it in Javascript?
Update
According to answers to another question: You cannot set cookies for another domain. Allowing this would present an enormous security flaw. Goes to show I'm not a frontend developer.
Not giving up, yet. There's the XmlHttpRequest object. Maybe this can be abused for my evil purposes?
Second Update
So I experimented with XmlHttpRequest. Bad news (for me and this particular case): It appears it won't work using XmlHttpRequest either because (using the current Firefox) my nicely forged requests are rewritten according to what appears to be slated to become a W3C standard on Cross-Origin Resource Sharing, so a Cookie header is simply removed and dummy headers Moin and Gurke are reduced to Access-Control-Request-Headers: gurke,moin. Now frankly, this is spoiling the game big time. I'm disappointed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，放弃了。我想做的事情是不可能的。其原因是所谓的同源策略，以使浏览器变得更安全。请参阅这个其他答案获取一些指导。看来我对 W3C 跨源资源共享工作草案的评估是错误的，该草案允许同源策略的例外。因此，如果广泛实施，它可能是可行的。但总体来说，这次尝试存在太多的假设和不确定性。
呵呵。成功了。 :)
毕竟不需要 cookie 和其中包含的会话 ID。我已经弄清楚如何获取该请求所需的所有参数，并且通过向客户端发送自动提交表单来将它们提供给客户端：
然后客户端进入自己的会话。效果很好。只要他们不改变界面。我设置了测试来监控它们的形式，并提醒我采取行动，它们以不兼容的方式更改了内容。
Okay, giving up. What I want to do is not possible. The reason for this is the so-called same-origin policy to make browsers a safer place. See this other answer for some pointers. And it appears I was wrong on my assessment of the W3C working draft on Cross-Origin Resource Sharing, which is there to allow exceptions from the same-origin policy. So if this were widely implemented it might be viable. But overall there are too many ifs and uncertainties in this attempt.
Hehe. Got it working. :)
The cookie and the session ID contained therein weren't needed after all. I've figured out how to obtain all the parameters needed for that request, and I'm providing them to the client by sending him an auto-submitting form:
The client then enters his own session. Works great. As long as they don't change the interface. I set up tests to monitor their form and alert me to take action they change stuff in incompatible ways.