您最喜欢的跨域cookie共享方法是什么？

Question

我看到iframe / p3p技巧是最受欢迎的，但我个人不喜欢它，因为javascript +隐藏字段+框架确实让它看起来像黑客工作。我也遇到过使用Web服务进行通信的主从方法（ http：// www。 15seconds.com/issue/971108.htm ）它似乎更好，因为它对用户是透明的，并且它对不同的浏览器是强大的。

有没有更好的方法，每种方法的优点和缺点是什么？

Answer 1

我的方法将一个域指定为“中心”域，将其他域指定为“卫星”域。

当有人点击“登录”链接（或呈现持久登录Cookie）时，登录表单最终将其数据发送到中央域上的URL，以及隐藏的表单元素，说明它来自哪个域from（只是为了方便起见，所以之后用户被重定向）。

然后，中央域中的此页面继续设置会话cookie（如果登录顺利）并重定向回用户登录的任何域，并在URL中使用特殊生成的令牌，该令牌对于该会话是唯一的。

卫星URL处的页面然后检查该令牌以查看它是否与为会话生成的令牌相对应，如果是，则在没有令牌的情况下重定向到自身，并设置本地cookie。现在卫星域也有会话cookie。此重定向会清除URL中的令牌，因此用户或任何爬虫都不太可能记录包含该令牌的URL（尽管如果这样做，则无关紧要，令牌可以是一次性令牌）。

现在，用户在中心域和卫星域都有会话cookie。但如果他们访问另一颗卫星呢？嗯，通常情况下，他们会认为卫星是未经验证的。

但是，在我的应用程序中，只要用户处于有效会话中，所有到其他卫星域上的页面的链接都会附加一个或多个。我保留这个''查询字符串意味着“检查中央服务器，因为我们认为这个用户有一个会话”。也就是说，任何HTML页面上都没有显示令牌或会话ID，只有字母“s”无法识别某人。

如果还没有有效会话，接收此类's'查询标记的网址会重定向到中央域名，并说“你能告诉我这是谁吗？”通过在查询字符串中添加内容。

当用户到达中央服务器时，如果他们在那里进行了身份验证，则中央服务器将只接收他们的会话cookie。然后，它将用另一个单一使用令牌将用户送回卫星，卫星将在登录后将其视为卫星（见上文）。即，卫星现在将在该域上设置会话cookie，并重定向到自身以从查询字符串中删除该令牌。

我的解决方案无脚本或iframe支持。它确实需要将“？s”添加到用户可能还没有该URL的cookie的任何跨域URL。我确实想到了解决这个问题的方法：当用户首次登录时，在每个域周围设置一系列重定向，并在每个域中设置会话cookie。我没有实现这一点的唯一原因是它会很复杂，因为你需要能够设置这些重定向会发生在何时停止的设置顺序，并且会阻止你扩展超过15个域左右（太多了，你变得危险地接近许多浏览器和代理的'重定向限制'。）

Answer 2

如果您完全控制所有域后端，那么这是一个很好的解决方案。在我的情况下，我只有一个客户端（javascript / html）控件，另一个完全控制，因此我需要使用iframe / p3p方法，这很糟糕:(。

Answer 3

该文中的示例对我来说似乎很可疑，因为您基本上会重定向到一个url，而url又会在变量字符串中将变量传递回您的域。

在该示例中，这意味着恶意用户可以直接导航到 http： //slave.com/return.asp?Return=blah&UID=123 ＆QUOT;并以用户123登录slave.com。

我是否遗漏了某些内容，或众所周知这种技术是不安全的，不应该被用于，例如，该示例建议的事情（传递用户ID，可能是为了使一个人的身份可移植）。

Answer 4

@thomasrutter

您可以通过进行ajax调用来检查“中央”域以获取页面加载时的身份验证状态，从而避免必须管理卫星上的所有出站链接（通过将“s”附加到查询字符串）。您可以通过每个会话只进行一次来避免冗余调用（在后续页面加载时）。

在页面加载之前在服务器端进行身份验证检查请求可能会更好，这样（a）您可以更有效地访问会话，并且（b）您将在页面呈现时知道用户是否是登录（并相应地显示内容）。

Answer 5

我们使用cookie链接，但它不是一个好的解决方案，因为当其中一个域不能为用户工作时（由于过滤/防火墙等），它会中断。较新的技术（包括你的技术）仅在“主”技术中断开。提供cookie /管理登录的服务器中断。

请注意，您的return.asp可能会被滥用以重定向到任何网站（请参阅例如这个。

Answer 6

好吧我好像找到了一个解决方案，你可以创建一个脚本标签，加载你要设置/获取cookie的域的src ...到目前为止，只有safari似乎无法设置cookie，但是Ie6和FF工作得很好......如果你只想获取cookie，这是一个非常好的方法。

Answer 7

您还应该针对域b，c，d，...验证活动会话信息，这样您只有在用户已经登录域a时才能登录。

Answer 8

您所做的是在接收变量的域上检查引荐来源地址，以便您可以确认链接来自您自己的域，而不是只需在地址栏中键入链接的人。这种方法效果很好。