后续说明：这是 11 年前写的，当时 Web 非常不同 - 例如，XMLhttprequest 不被视为可以依赖的东西，更不用说跨域了。
My approach designates one domain as the 'central' domain and any others as 'satellite' domains.
When someone clicks a 'sign in' link (or presents a persistent login cookie), the sign in form ultimately sends its data to a URL that is on the central domain, along with a hidden form element saying which domain it came from (just for convenience, so the user is redirected back afterwards).
This page at the central domain then proceeds to set a session cookie (if the login went well) and redirect back to whatever domain the user logged in from, with a specially generated token in the URL which is unique for that session.
The page at the satellite URL then checks that token to see if it does correspond to a token that was generated for a session, and if so, it redirects to itself without the token, and sets a local cookie. Now that satellite domain has a session cookie as well. This redirect clears the token from the URL, so that it is unlikely that the user or any crawler will record the URL containing that token (although if they did, it shouldn't matter, the token can be a single-use token).
Now, the user has a session cookie at both the central domain and the satellite domain. But what if they visit another satellite? Well, normally, they would appear to the satellite as unauthenticated.
However, throughout my application, whenever a user is in a valid session, all links to pages on the other satellite domains have a ?s or &s appended to them. I reserve this 's' query string to mean "check with the central server because we reckon this user has a session". That is, no token or session id is shown on any HTML page, only the letter 's' which cannot identify someone.
A URL receiving such an 's' query tag will, if there is no valid session yet, do a redirect to the central domain saying "can you tell me who this is?" by putting something in the query string.
When the user arrives at the central server, if they are authenticated there the central server will simply receive their session cookie. It will then send the user back to the satellite with another single use token, which the satellite will treat just as a satellite would after logging in (see above). Ie, the satellite will now set up a session cookie on that domain, and redirect to itself to remove the token from the query string.
My solution works without script, or iframe support. It does require '?s' to be added to any cross-domain URLs where the user may not yet have a cookie at that URL. I did think of a way of getting around this: when the user first logs in, set up a chain of redirects around every single domain, setting a session cookie at each one. The only reason I haven't implemented this is that it would be complicated in that you would need to be able to have a set order that these redirects would happen in and when to stop, and would prevent you from expanding beyond 15 domains or so (too many more and you become dangerously close to the 'redirect limit' of many browsers and proxies).
Follow up note: this was written 11 years ago when the web was very different - for example, XMLhttprequest was not regarded as something you could depend on, much less across domains.
That's a good solution if you have full-control of all the domains backend. In my situation I only have client (javascript/html) control on one, and full-control on another, therefore I need to use the iframe/p3p method, which sucks :(.
Ok I seem to have found a solution, you can create a script tag that loads the src of the domain you want to set/get cookies on... only safari so far seems not to be able to SET cookies, but Ie6 and FF work fine... still if you only want to GET cookies, this is a very good approach.
The example in that article seems suspicious to me because you basically redirect to a url which, in turn, passes variables back to your domain in a querystring.
Am I missing something, or is it well-known that this technique is insecure and shouldn't be used for, well, things like that example suggests (passing user id's around, presumably to make one's identity portable).
You could avoid having to manage all outbound links on satellites (via appending "s" to querystring) by making an ajax call to check the 'central' domain for auth status on page load. You could avoid redundant calls (on subsequent page loads) by making only one per session.
It would be arguably better to make the auth check request server-side prior to page load so that (a) you have more efficient access to session, and (b) you will know upon page render whether or not the user is logged in (and display content accordingly).
We use cookie chaining, but it's not a good solution since it breaks when one of the domains doesn't work for the user (due to filtering / firewalls etc.). The newer techniques (including yours) only break when the "master" server that hands out the cookies / manages logins breaks.
Note that your return.asp can be abused to redirect to any site (see this for example).
You also should validate active session information against domains b,c,d,... this way you can only login if the user has already logged in at domain a.
What you do is on the domain receiving the variables you check the referrer address as well so you can confirm the link was from your own domain and not someone simply typing the link into the address bar. This approach works well.
发布评论
评论（8）
我的方法将一个域指定为“中心”域，将任何其他域指定为“卫星”域。
当有人单击“登录”链接（或提供持久登录 cookie）时，登录表单最终会将其数据发送到中央域上的 URL，同时还有一个隐藏的表单元素，说明它来自哪个域（仅为了方便起见，用户随后会被重定向回来）。
然后，中央域的该页面继续设置会话 cookie（如果登录顺利）并重定向回用户登录的任何域，并在 URL 中使用专门生成的令牌，该令牌对于该会话是唯一的。
然后，卫星 URL 处的页面检查该令牌以查看它是否确实对应于为会话生成的令牌，如果是，则它会在没有令牌的情况下重定向到自身，并设置本地 cookie。 现在该卫星域也有一个会话 cookie。 此重定向会清除 URL 中的令牌，因此用户或任何爬网程序都不太可能记录包含该令牌的 URL（尽管如果记录了，也没关系，该令牌可以是一次性令牌）。
现在，用户在中央域和卫星域都有一个会话 cookie。 但如果他们访问另一颗卫星怎么办？ 嗯，通常情况下，它们在卫星看来是未经身份验证的。
但是，在我的整个应用程序中，每当用户处于有效会话中时，指向其他卫星域上页面的所有链接都会附加一个 ?s 或 &s。 我保留这个查询字符串的意思是“与中央服务器检查，因为我们认为该用户有一个会话”。 也就是说，任何 HTML 页面上都不会显示令牌或会话 ID，仅显示无法识别某人的字母“s”。
如果还没有有效会话，接收此类 's' 查询标记的 URL 将重定向到中央域，并显示“你能告诉我这是谁吗？” 通过在查询字符串中放入一些内容。
当用户到达中央服务器时，如果他们在那里经过身份验证，中央服务器将简单地接收他们的会话 cookie。 然后，它将使用另一个一次性令牌将用户发送回卫星，卫星将像登录后的卫星一样对待该令牌（见上文）。 即，卫星现在将在该域上设置一个会话 cookie，并重定向到自身以从查询字符串中删除令牌。
我的解决方案无需脚本或 iframe 支持即可工作。 它确实需要将“?s”添加到任何跨域 URL，其中用户可能在该 URL 上还没有 cookie。 我确实想到了一种解决这个问题的方法：当用户第一次登录时，在每个域周围设置一系列重定向，并在每个域上设置一个会话 cookie。 我没有实现这一点的唯一原因是，它会很复杂，因为您需要能够设定这些重定向发生的顺序以及何时停止，并且会阻止您扩展超过 15 个域左右（太多，您就会危险地接近许多浏览器和代理的“重定向限制”）。
后续说明：这是 11 年前写的，当时 Web 非常不同 - 例如，XMLhttprequest 不被视为可以依赖的东西，更不用说跨域了。
My approach designates one domain as the 'central' domain and any others as 'satellite' domains.
When someone clicks a 'sign in' link (or presents a persistent login cookie), the sign in form ultimately sends its data to a URL that is on the central domain, along with a hidden form element saying which domain it came from (just for convenience, so the user is redirected back afterwards).
This page at the central domain then proceeds to set a session cookie (if the login went well) and redirect back to whatever domain the user logged in from, with a specially generated token in the URL which is unique for that session.
The page at the satellite URL then checks that token to see if it does correspond to a token that was generated for a session, and if so, it redirects to itself without the token, and sets a local cookie. Now that satellite domain has a session cookie as well. This redirect clears the token from the URL, so that it is unlikely that the user or any crawler will record the URL containing that token (although if they did, it shouldn't matter, the token can be a single-use token).
Now, the user has a session cookie at both the central domain and the satellite domain. But what if they visit another satellite? Well, normally, they would appear to the satellite as unauthenticated.
However, throughout my application, whenever a user is in a valid session, all links to pages on the other satellite domains have a ?s or &s appended to them. I reserve this 's' query string to mean "check with the central server because we reckon this user has a session". That is, no token or session id is shown on any HTML page, only the letter 's' which cannot identify someone.
A URL receiving such an 's' query tag will, if there is no valid session yet, do a redirect to the central domain saying "can you tell me who this is?" by putting something in the query string.
When the user arrives at the central server, if they are authenticated there the central server will simply receive their session cookie. It will then send the user back to the satellite with another single use token, which the satellite will treat just as a satellite would after logging in (see above). Ie, the satellite will now set up a session cookie on that domain, and redirect to itself to remove the token from the query string.
My solution works without script, or iframe support. It does require '?s' to be added to any cross-domain URLs where the user may not yet have a cookie at that URL. I did think of a way of getting around this: when the user first logs in, set up a chain of redirects around every single domain, setting a session cookie at each one. The only reason I haven't implemented this is that it would be complicated in that you would need to be able to have a set order that these redirects would happen in and when to stop, and would prevent you from expanding beyond 15 domains or so (too many more and you become dangerously close to the 'redirect limit' of many browsers and proxies).
Follow up note: this was written 11 years ago when the web was very different - for example, XMLhttprequest was not regarded as something you could depend on, much less across domains.
如果您可以完全控制所有域后端，那么这是一个很好的解决方案。 在我的情况下，我只有一个客户端（javascript/html）控制，而另一个完全控制，因此我需要使用 iframe/p3p 方法，这很糟糕:(。
That's a good solution if you have full-control of all the domains backend. In my situation I only have client (javascript/html) control on one, and full-control on another, therefore I need to use the iframe/p3p method, which sucks :(.
好吧，我似乎找到了一个解决方案，你可以创建一个脚本标签来加载你想要设置/获取cookie的域的src...到目前为止，只有safari似乎无法设置cookie，但Ie6和FF工作正常...如果你只想获取cookie，这是一个非常好的方法。
Ok I seem to have found a solution, you can create a script tag that loads the src of the domain you want to set/get cookies on... only safari so far seems not to be able to SET cookies, but Ie6 and FF work fine... still if you only want to GET cookies, this is a very good approach.
那篇文章中的示例对我来说似乎很可疑，因为您基本上重定向到一个 url，而该 url 又在查询字符串中将变量传递回您的域。
在该示例中，这意味着恶意用户可以简单地导航到 http:// /slave.com/return.asp?Return=blah&UID=123”并以用户 123 身份登录 Slave.com。
我是否遗漏了某些内容，或者众所周知，这种技术不安全并且不应该用于，嗯，像这个例子所建议的那样（传递用户 ID，大概是为了使一个人的身份可移植）。
The example in that article seems suspicious to me because you basically redirect to a url which, in turn, passes variables back to your domain in a querystring.
In the example, that would mean that a malicious user could simply navigate to http://slave.com/return.asp?Return=blah&UID=123" and be logged in on slave.com as user 123.
Am I missing something, or is it well-known that this technique is insecure and shouldn't be used for, well, things like that example suggests (passing user id's around, presumably to make one's identity portable).
@thomasrutter
您可以通过进行ajax调用来检查“中央”域的页面加载身份验证状态，从而避免管理卫星上的所有出站链接（通过在查询字符串中附加“s”）。 您可以通过每个会话仅进行一次调用来避免冗余调用（在后续页面加载时）。
可以说，在页面加载之前在服务器端发出身份验证检查请求会更好，这样（a）您可以更有效地访问会话，并且（b）您将在页面呈现时知道用户是否已登录（并相应地显示内容）。
@thomasrutter
You could avoid having to manage all outbound links on satellites (via appending "s" to querystring) by making an ajax call to check the 'central' domain for auth status on page load. You could avoid redundant calls (on subsequent page loads) by making only one per session.
It would be arguably better to make the auth check request server-side prior to page load so that (a) you have more efficient access to session, and (b) you will know upon page render whether or not the user is logged in (and display content accordingly).
我们使用 cookie 链接，但这不是一个好的解决方案，因为当其中一个域对用户不起作用时（由于过滤/防火墙等），它就会中断。 只有当分发 cookie/管理登录的“主”服务器崩溃时，较新的技术（包括您的技术）才会崩溃。
请注意，您的 return.asp 可能会被滥用以重定向到任何网站（请参阅此< /a> 例如）。
We use cookie chaining, but it's not a good solution since it breaks when one of the domains doesn't work for the user (due to filtering / firewalls etc.). The newer techniques (including yours) only break when the "master" server that hands out the cookies / manages logins breaks.
Note that your return.asp can be abused to redirect to any site (see this for example).
您还应该针对域 b、c、d...验证活动会话信息，这样您只能在用户已经在域 a 登录时登录。
You also should validate active session information against domains b,c,d,... this way you can only login if the user has already logged in at domain a.
您要做的就是在接收变量的域上检查引荐来源网址地址，以便您可以确认该链接来自您自己的域，而不是某人简单地将链接输入到地址栏中。 这种方法效果很好。
What you do is on the domain receiving the variables you check the referrer address as well so you can confirm the link was from your own domain and not someone simply typing the link into the address bar. This approach works well.