가장 좋아하는 크로스 도메인 쿠키 공유 접근법은 무엇입니까?
https://stackoverflow.com/questions/263010
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
나는 iframe/p3p 트릭이 가장 인기있는 것임을 알지만 JavaScript + Hidden Fields + 프레임이 실제로 해킹 작업처럼 보이기 때문에 개인적으로 마음에 들지 않습니다. 또한 웹 서비스를 사용하여 통신하는 마스터 슬레이브 접근법을 발견했습니다.http://www.15seconds.com/issue/971108.htm) 그리고 사용자에게 투명하고 다른 브라우저에 대해 강력하기 때문에 더 나은 것 같습니다.
더 나은 접근 방식이 있습니까? 각각의 장단점은 무엇입니까?
해결책
내 접근 방식은 하나의 도메인을 '중앙'도메인으로, 다른 도메인을 '위성'도메인으로 지정합니다.
누군가가 '로그인'링크를 클릭하거나 영구 로그인 쿠키를 표시하면 서명 형 양식은 궁극적으로 데이터를 중앙 도메인에있는 URL로 보냅니다. 편의를 위해 사용자는 나중에 다시 리디렉션됩니다).
그런 다음 중앙 도메인 의이 페이지는 세션 쿠키를 설정하고 (로그인이 제대로 된 경우) 사용자가 로그인 한 모든 도메인으로 다시 리디렉션하고 해당 세션의 고유 한 URL에서 특별히 생성 된 토큰으로 다시 리디렉션합니다.
위성 URL의 페이지는 토큰을 확인하여 세션을 위해 생성 된 토큰에 해당하는지 확인하고, 그렇다면 토큰없이 자체로 리디렉션하고 로컬 쿠키를 설정합니다. 이제 위성 도메인에는 세션 쿠키도 있습니다. 이 리디렉션은 URL에서 토큰을 지우므로 사용자 나 크롤러가 해당 토큰이 포함 된 URL을 녹음 할 가능성은 낮습니다 (그렇지 않은 경우에는 중요하지 않지만 토큰은 단일 사용 토큰이 될 수 있습니다).
이제 사용자는 중앙 도메인과 위성 도메인에 세션 쿠키가 있습니다. 그러나 그들이 다른 위성을 방문한다면 어떨까요? 글쎄, 일반적으로 그들은 위성에 무단으로 나타납니다.
그러나 내 응용 프로그램 전체에서 사용자가 유효한 세션에있을 때마다 다른 위성 도메인의 페이지에 대한 모든 링크에는 A 또는 S가 추가되었습니다. 이 'S'쿼리 문자열을 예약하여 "이 사용자가 세션이 있다고 생각하기 때문에 중앙 서버에 체크인"을 의미합니다. 즉, HTML 페이지에 토큰이나 세션 ID가 표시되지 않으며 누군가를 식별 할 수없는 문자 'S'만 표시됩니다.
그러한 'S'쿼리 태그를받는 URL은 아직 유효한 세션이 없다면 중앙 도메인에 "이것이 누구인지 말해 줄 수 있습니까?"라고 말하는 리디렉션을 수행합니다. 쿼리 문자열에 무언가를 넣음으로써.
사용자가 중앙 서버에 도착하면 인증을 받으면 중앙 서버는 단순히 세션 쿠키를받습니다. 그런 다음 다른 단일 사용 토큰으로 사용자를 위성으로 다시 보냅니다. 위성은 위성이 로그인 한 후 위성으로 처리됩니다 (위 참조). 즉, 위성은 이제 해당 도메인에 세션 쿠키를 설정하고 쿼리 문자열에서 토큰을 제거하기 위해 스스로 리디렉션됩니다.
내 솔루션은 스크립트 또는 iframe 지원없이 작동합니다. 사용자가 아직 해당 URL에 쿠키가 없을 수있는 크로스 도메인 URL에 추가해야합니다. 사용자가 처음 로그인 할 때 모든 단일 도메인 주위에 리디렉션 체인을 설정하여 각 도메인에 세션 쿠키를 설정하는 방법을 생각했습니다. 내가 구현하지 않은 유일한 이유는 이러한 리디렉션이 언제, 언제 중지 해야하는지 정해진 순서를 가질 수 있어야하고 15 도메인을 넘어서 확장하는 것을 막을 수 있다는 점에서 복잡하기 때문입니다. (너무 많으면 많은 브라우저와 프록시의 '리디렉션 한계'에 위험하게 가깝게됩니다).
다른 팁
모든 도메인 백엔드를 완전히 통제하는 경우 좋은 솔루션입니다. 내 상황에서 나는 하나에 클라이언트 (JavaScript/HTML) 컨트롤 만 있고 다른 하나는 전체 통제력이 있으므로 iframe/p3p 방법을 사용해야합니다.
이 기사의 예는 기본적으로 URL로 리디렉션하여 쿼리 스트링의 변수를 도메인으로 다시 전달하기 때문에 나에게 의심스러워 보입니다.
이 예에서는 악의적 인 사용자가 단순히 다음으로 탐색 할 수 있음을 의미합니다. http://slave.com/return.asp?return=blah&uid=123"그리고 Slave.com에 사용자 123으로 로그인해야합니다.
내가 무언가를 놓치고 있거나,이 기술이 안전하지 않으며, 그 예와 같은 것들이 제안하는 것과 같은 것을 사용해서는 안된다는 것이 잘 알려져 있습니까 (사용자 ID를 통과하고 아마도 신원을 휴대용으로 만들기 위해).
@thomasrutter
AJAX 호출을 통해 페이지로드의 인증 상태에 대해 '중앙'도메인을 확인하여 위성의 모든 아웃 바운드 링크를 위성 (QueryString에 추가)을 관리하지 않아도됩니다. 세션 당 하나만 만들어 중복 통화 (후속 페이지로드)를 피할 수 있습니다.
(a) 세션에 더 효율적으로 액세스 할 수 있도록 페이지로드 전에 인증 확인 서버 측을 만드는 것이 더 나을 것입니다. (b) 페이지에서 알 수 있습니다. 그에 따라 콘텐츠를 표시합니다).
우리는 쿠키 체인을 사용하지만 도메인 중 하나가 사용자에게 작동하지 않을 때 (필터링 / 방화벽 등으로 인해)가 끊어지기 때문에 좋은 솔루션은 아닙니다. 최신 기술 (귀하를 포함하여)은 쿠키 / 로그인을 관리하는 "마스터"서버가 로그인을 분해 할 때만 중단됩니다.
Return.asp는 모든 사이트로 리디렉션하기 위해 남용 될 수 있습니다 ( 이것 예를 들어).
좋아, 솔루션을 찾은 것 같다. 쿠키를 설정/받으려는 도메인의 SRC를로드하는 스크립트 태그를 만들 수있다. 잘 작동합니다 ... 여전히 쿠키를 얻고 싶다면 이것은 아주 좋은 접근법입니다.
또한 도메인 B, C, D 등에 대한 활성 세션 정보를 검증해야합니다.이 방법으로 사용자가 도메인 A에서 이미 로그인 한 경우에만 로그인 할 수 있습니다.
당신이하는 일은 도메인에있는 변수를 수신하는 것입니다. 참조자 주소를 확인하므로 링크가 자신의 도메인에서 확인하고 단순히 링크를 주소 표시 줄에 입력하는 사람이 아닌지 확인할 수 있습니다. 이 접근법은 잘 작동합니다.
