如何将控制权传递给外部 Web 应用程序并接收响应
我正在寻找一些好的文档/示例，了解如何临时将控制权传递给外部 Web 应用程序并让主机应用程序接收响应。我正在实现此通信的外部 Web 应用程序一半。
也许解释这个问题的最好方法是通过示例：
- StackExchange 将用户发送到 Google 进行登录
- 在线商店将用户发送到 Paypal 来处理付款
在这两种情况下，主机应用程序都会将用户发送到外部站点执行某些任务（登录或付款），并且外部站点传回响应。
我目前正在编写一个 Web 应用程序，该应用程序将是这些示例中的外部 Web 应用程序。我可以自己提出一个设计，但我想知道是否有可以使用的既定模式或技术。
我的下一步是硬着头皮和 RTFM（Paypal 和 OpenID）看看他们是如何实现的，但如果有人能在此之前为我指明正确的方向，我将不胜感激。
其他一些快速说明：
- 设计应该尽可能安全。理想情况下，主机和外部应用都将具有相互验证以及最终用户验证的方法。
- 该设计不能依赖 javascript，也不能涉及 iframe，因为有严格的可访问性要求。
I'm looking for some good documentation/examples on how to temporarily pass control to an external web application and have the host application receive a response. I'm implementing the external web application half of this communication.
Perhaps the best way to explain this question is through examples:
- StackExchange sends a user to Google to login
- An online store sends a user to Paypal to process payments
In both these cases, the host application sends the user to an external site to perform some task (login or payment), and the external site passes a response back.
I'm currently writing a web application that would be the external web application in these examples. I could come up with a design myself, but I'm wondering if there are established patterns or technologies that can be used.
My next step is to bite the bullet and RTFM (both Paypal and OpenID) to see how they implement it, but if anyone can point me in the right direction before then, I'd appreciate it.
Some other quick notes:
- The design should be as secure as possible. Ideally both the host and external app will have a means of authenticating each other as well as the end user.
- The design cannot rely on javascript and cannot involve iframes, as there are strict accessibility requirements.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不知道你是否会觉得它足够详细，无论如何，如果你实施与金融交易相关的东西，你应该格外小心。
例如，假设某家公司在线销售某些商品（例如书籍），
在其网站 A (webapp A) 上，希望使用外部支付来实现支付
站点 B（这是某个银行公司运行的 Web 应用程序 B）。
用户填写一个表格，其中包含他想要购买的书籍的详细信息，然后提交。
然后他被重定向到 A 的 HTTPS 页面，在那里他被通知他订购了
“极限编程”和“敏捷编程”总共 40 美元，并询问是否
他确认购买。用户按下“是”按钮，从而向 A 提交
请求Req1。
此时，Web 应用程序 A 通过 SSL（如果在 Java 中，使用 httpclient）联系 Web 应用程序 B（这是企业对企业通信，不涉及浏览器！），并告诉它：我想将一个希望访问您网站的用户重定向到您的网站付我 40 美元。 B 回答：好的，这是一个请求 id Id1（类似于 R543E32pU878..）。现在，A 始终响应用户的确认 (Req1)，将重定向到用户浏览器发送到外部支付站点 B，并在重定向中包含此 Id1。然后，B 向用户展示（通过 HTTPS）购买数据，并要求输入用户的个人和信用卡详细信息。用户输入它们并按“继续”，从而提交请求 Req2。 B 联系（同样，不涉及浏览器）VISA/银行服务器（通过 SSL），并且如果成功，则获取交易 ID Id2。
现在，B 联系 A（SSL，不涉及浏览器）并通知其交易成功，并向 A 传达交易 ID，从 A 处获得确认
它收到了消息。最后，B 通过重定向到包含请求 ID Id1 的站点 A 来响应用户请求 Req2（请记住，用户仍然等待提交其个人和信用卡详细信息的响应）。然后，A 向用户发送一个页面，通知用户交易成功，并可选择可视化交易 ID Id2，以防万一。
我并没有试图找出此类交互是否有一些行业标准；据我了解，不同的银行机构实施这种互动的方式并不完全相同。
don't know if you will find it detailed enough, and in any case if you implement something related to financial transactions, you should take extra care.
Assume, for example, that some company which sells some goods online, say books,
on its site A (webapp A), wishes to implement payments using an external payment
site B (which is a webapp B run by some banking company).
The user fills a form with details of the books he wants to buy, and submits it.
He is then redirected to a HTTPS page of A where he is notified that he ordered
"Extreme programming" and "Agile programming" for 40$ total and asked whether
he confirms the purchase. User presses on "yes" button, thus submitting to A the
request Req1.
At this point, the webapp A contacts webapp B (this is Business to Business communication, no browsers involved!) via SSL (if in Java, use httpclient), and tells it: I want to redirect to your site a user who wishes to pay me 40$. B answeres: OK, here is a request id Id1 (something like R543E32pU878..). Now A, always in response to the confirmation of the user (Req1), sends a redirect to user's browser to the external payment site B with this Id1 inside the redirect. B then exhibits to the user (via HTTPS) the data of the purchase and asks to enter user's personal and credit card details. User enters them and presses "proceed" thus submitting the request Req2. B contacts (again, no browsers involved) the VISA/bank servers (via SSL), and, in case of success, gets a transaction id Id2.
Now, B contacts A (SSL, no browsers involved) and notifies it that the transaction was successful and communicates to A the transaction id, getting a confirmation from A that
it got the message. Finally, B responds to the user request Req2 (remember, the user still waits for a response to the submit of his personal and credit card details) with a redirect to the site A which includes the request id Id1. A then sends a page to the user where the user is notified that the transaction was successful and optionally visualizes the transaction id Id2, just in case.
I did not try to find out if there are some industry standards for such interactions; as far as I know different banking institutions implement such interactions in ways which are not totally identical.