위 사진은 JD.com의 단일 지점 인증 과정 중 http 요청입니다.
그의 프로세스는 다음과 같습니다. 즉, 현재 홈페이지는 www.jd.com이고, 교차 도메인 요청을 시작하여 sso.jd.hk에 대한 인증을 시작합니다. 이 요청은 쿠키를 전달하며 쿠키도 응답으로 반환됩니다. 응답으로 반환된 쿠키의 도메인은 첫 번째 수준 도메인 이름으로 설정됩니다.
몇 가지 질문이 있습니다
(1) 이는 교차 도메인 요청입니다. 요청이 쿠키를 전달하는 이유는 무엇입니까? 이거 괜찮아요? 다른 친구들이 쿠키를 들고 다닐 수 있다고 하는 걸 봤어요
예: http://blog.csdn.net/wzl002/a... 도메인 간 Ajax 요청에 쿠키 설정을 포함할지 여부
그런데 JD.com에 대해서는 구체적으로 어떻게 처리하셨나요?
(2) 응답에 쿠키가 설정되어 있는데 현재 도메인 이름이 jd.hk가 아니고 www.jd.com으로 설정이 가능한가요? 구체적으로 JD.com에서는 어떻게 설정하나요?
(3) 응답에 p3p가 설정되어 있습니다. 이를 통해 질문 2에서 언급한 문제가 해결됩니까?
(4) p3p는 http://blog.csdn.net/ghj1976/...
을 참고하시면 됩니다.언급된 기사:
P3P를 채택한 후 웹사이트가 개인 식별 정보를 수집하는지, 이 정보를 사용하여 사용자 프로필을 생성하는지, 방문자가 데이터 수집을 거부하도록 허용하는지를 자동으로 감지하도록 브라우저를 설정할 수 있습니다.P3P 지원 브라우저에는 선택할 수 있는 몇 가지 기본 옵션이 있습니다. 또는 공유할 데이터와 허용할 쿠키 유형 등의 질문에 답하여 설정을 맞춤화할 수도 있습니다. 귀하가 웹을 탐색할 때 이 소프트웨어는 귀하의 개인정보 보호 기본 설정이 웹사이트의 데이터 수집 관행과 일치하는지 여부를 결정합니다.
내가 이해한 바는 다음과 같습니다. p3p 기능이 있는 브라우저는 도메인 전체에 걸쳐 쿠키 쓰기를 감지하고 사용자와 상호작용하여 사용자에게 도메인 전체에 걸쳐 쿠키를 작성하는 데 동의하는지 물어볼 수 있습니다. 자주 발생하는 웹페이지 변경 프롬프트 상호작용과 유사합니까? ? ? ? 이런 이해는 불합리한 것 같아요,
한마디 한마디 부탁드립니다 (
＾-＾)
PHP中文网2017-05-17 09:59:37
도메인 이름과 호스트의 차이점을 이해하세요. 예를 들어 www.jd.com은 도메인 이름이 아닌 호스트 이름이고 jd.com은 도메인 이름입니다. 아래 그림에서 HostOnly를 선택하면 이 쿠키는 이 호스트에서만 작동합니다. 호스트 이름 www1.jd.com을 변경하면 작동하지 않습니다. 그러나 HostOnly를 선택하지 않으면 이 쿠키는 이 도메인 이름 아래의 모든 호스트에서 유효합니다. 이 쿠키가 www.jd.com에서 생성되더라도 www1.jd.com에서 계속 읽을 수 있습니다. , 브라우저가 www1.jd.com을 방문하면 이 쿠키는 요청의 일부로 서버로 전송됩니다.
Ajax 크로스 도메인은 이와 다릅니다. Ajax는 도메인 이름과 호스트의 차이를 혼동합니다. Ajax의 관점에서 보면 요청이 동일한 호스트에서 시작되지 않는 한 크로스 도메인으로 간주됩니다. 예를 들어, www1.jd.com의 콘텐츠에 액세스하기 위해 www.jd.com에서 Ajax 요청을 시작하는 경우에도 이 요청은 교차 도메인으로 간주됩니다. 엄밀히 말하면 이는 크로스 도메인이 아닌 크로스 호스트로만 간주됩니다. 그러나 역사적 이유로 항상 이렇게 정의되어 왔기 때문에 수정할 방법이 없습니다.
伊谢尔伦2017-05-17 09:59:37
제 제안은 토큰 확인 방법을 직접 설계하는 것입니다. 쿠키와 http 요청 응답은 토큰을 전달하는 방법일 뿐입니다. 이 토큰을 redis/memcached에 저장하면 모든 노드는 토큰을 통해 현재 상태(검증되었는지 여부)를 쿼리하거나 동일한 이유로 검증을 제공하는 독립적인 서비스를 작성할 수 있습니다. sso.jd.hk는 쿠키를 사용하여 인증 토큰 및 타임스탬프와 같은 정보를 저장합니다.
토큰은 비밀로 유지될 필요가 없으며 토큰을 직접 회신하면 됩니다. 이 모드는 웹소켓 인증에도 적합합니다.
일반적으로 사용되는 계산 방법:token = sha1(数据ID+过期时间戳+验证密码)
토큰, 데이터 ID, 만료 타임스탬프를 클라이언트에 보내고, 다른 서비스에 요청을 보낼 때 이 세 가지 정보를 첨부하세요. 인증 비밀번호는 서버만 알고 있으므로 해당 요청이 다른 서비스에서 왔는지 확인할 수 있습니다. AWS 리소스 확인 방법은 확인 비밀번호가 API 키로 대체된다는 점을 제외하면 이와 유사합니다.
