4

认为:

  1. 您有一个网站http://www.example.com重定向到 Google App Engine 上的项目(即 example.appspot.com);
  2. 您希望用户之间通过 SSL 进行通信(即https://example.appspot.com);和
  3. 您希望向用户显示的域是 *://www.example.com (即不是https://example.appspot.com)。

鉴于Google 的 Appspot HTTPS 支持仅适用于https://example.appspot.com(即您不能使用 GAE 设置https://www.example.com),我想要一个 Ajax 解决方案,即:

  1. http://www.example.com通过 http 提供 HTML 和 Javascript
  2. Ajax 请求通过 SSL 发送到https://example.appspot.com

我的问题/担忧是:如何确保登录到http://www.example.com的用户(通过 Google 的用户 API)通过 Ajax 将他们的身份验证凭据传递给https://example.appspot.com

这似乎违反了同源策略(这可能是 Google 用户 API 的一个问题,也可能不是),所以如何知道哪个用户登录到 example.com 以获取对 example.appspot 的 Ajax 请求。 com?

非常感谢您的想法、评论和输入。

谢谢你。

布赖恩

4

4 回答 4

2

当两个站点合作时,有一些方法可以解决同源问题,例如查看这篇文章,但只有反复试验才能揭示哪些技术可以满足您的特定要求(这可能取决于用户在他们的浏览器,以及服务器端实现)。

于 2009-08-06T18:03:32.850 回答
2

您可以尝试使用JSONP来解决这个问题。然而 JSONP 在执行 XHR 调用时并没有像 JSON 那样很好的错误恢复。

于 2009-08-07T07:45:17.430 回答
1

使用框架不是更简单吗?从 yourdomain.com 提供一个完整尺寸的框架集,其中包含来自https://yourapp.appspot.com/的内容。

但请注意,这两种解决方案都有一个问题,即用户看到的是不安全的站点,而不是安全的站点。

于 2009-08-07T07:43:52.223 回答
1

example.appspot.com 不与 example.com 共享任何 cookie - 如果不让他们登录 example.appspot.com,您将无法识别用户。

当然,您可以完全放弃 example.appspot.com 上的 Google 身份验证并实施您自己的方案;您可以将签名和用户名附加到您创建的 AJAX 请求中,并在您的应用引擎应用程序上验证该签名。如果签名有效,则只需接受传入的用户作为经过身份验证的用户并假装他已登录。

于 2009-08-10T07:53:32.550 回答