在 iFrame 中使用第三方购物车的想法
我们有一个客户想要在他们的网站上使用第三方购物车，但我们必须发送给客户的 URL 看起来非常难看，而且无法进行任何换肤。客户提出使用 iFrame 将购物车保留在其网站上。
如果两个站点都有 SSL，那么至少挂锁仍然存在，您对这种做法有何看法？坏的？有安全问题吗？比将它们发送到另一个看起来非常不同的页面更好吗？也许由于 Paypal 和 Google Checkout 之类的东西，人们现在已经习惯了这种做法？
We have a client that wants to use a third party shopping cart on their website, but the URL we'd have to send our clients to looks pretty ugly and there is no way to do any skinning. The client brought up using an iFrame to keep the shopping cart on their website.
If both sites had SSL so that at least the padlock would still be there, what are your thoughts on this practice? Bad? Any security issues? Better than sending them to another page that looks very different? Maybe people are used to this kind of practice by now thanks to things like Paypal and Google checkout?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您将无法通过 IFrame 传输信息，特别是当它位于不同的域时（出于安全原因）。了解相同域政策。
使用 paypal 和 google checkout 通常意味着您将用户重定向到结账网站，并且在完成后他们会被重定向回您的网站。
与此类网站交互的另一种流行方式是使用其 API（通常作为 Web 服务公开）。这允许您留在您的网站上并与结账服务进行通信 - 这是更多的工作，因为您需要设计自己的结账并建立通信层。
You will not be able to transfer information over an IFrame, especially if it is on a different domain (due to security reasons). Read about the same domain policy.
Using paypal and google checkout normally means that you redirect the user to the checkout site and they get redirected back to your site when finished.
Another popular way to interact with such sites is by using their API (normally exposed as web services). This allows you the stay on your site and communicate with the checkout service - it is more work, as you need to design your own checkout and build up the communications layer.