동결 사용자 에이전트 문자열

Chrome 및 기타 주요 브라우저는 사용자 에이전트 문자열을 동결하려고하며, 이는 광범위한 관심을 끌었습니다. 이는 사용자 에이전트 문자열이 여전히 존재한다는 것을 의미하지만 (요청 헤더에 나타나고 navigator.userAgent 통해 JavaScript에서 액세스 할 수 있음) 브라우저/플랫폼/버전을 감지하는 기능은 시간이 지남에 따라 감소합니다. Google은 공식적으로 이러한 움직임은 사용자 개인 정보를 보호하고 지문 인식을 방지하는 것이라고 설명했습니다.

프론트 엔드 개발 분야는 항상 권장되었습니다. 사용자 에이전트 감지를 피하십시오 . 많은 웹 사이트에서 사용자 에이전트 감지를 잘못 사용하여 좋은 것보다 더 많은 해를 끼칩니다. 사용자 에이전트 탐지를 피하는 가장 좋은 방법은 실제 요구 사항에 따라 테스트하는 것 입니다.

브라우저가 특정 기능을 지원하는지 여부를 테스트해야합니까? 브라우저가 기능을 지원해야한다고 가정하는 추상 개념에 의존하지 않고 기능을 직접 테스트하십시오.

JavaScript에서 많은 기능을 테스트하는 것은 매우 간단합니다. API가 있는지 확인하십시오.

 if (navigator.geolocation) {
  navigator.geolocation.getCurrentPosition (showposition);
} 또 다른 {
  Console.warn ( "지리적 위치 지원되지 않음");
}

CSS에서는 @supports 기본 메커니즘을 사용할 수 있습니다.

 @supports (display : 그리드) {
  .기본 {
    디스플레이 : 그리드;
  }
}

이것은 부울 값을 반환하는 JavaScript API에 의해 감지 될 수 있습니다.

 css.supports ( "display : flex");

모든 웹 플랫폼 기능이 테스트하기 쉽지는 않지만 일반적으로 사용자 에이전트 프로브가 필요하지 않습니다. 어려움에 직면하면 ModernIZR이 해당 테스트를 제공하는지 확인할 수 있습니다. 해당 테스트,이 테스트는 기능 테스트의 골드 표준이 잘 ​​테스트되었으며 예측할 수없는 가장자리 케이스를 처리합니다. Modernizr 라이브러리를 사용하여 명확한 논리적 지점을 얻으십시오.

 if (modernizr.requestanimationframe) {
  // support} else {
  // 지원되지 않음}

브라우저 유형, 플랫폼 및 버전을 실제로 알아야하는 경우 사용자 에이전트 클라이언트 힌트 (UA-CH)를 사용할 수 있습니다.

예를 들어, 플랫폼 정보를 얻으려면 요청에서 Sec-CH-Platform 헤더를 설정할 수 있으며, 이론적으로 응답에서 얻을 수 있습니다. 이를 위해서는 사전 예방 적 정보 요청이 필요하므로 문제가있는 개인 정보 지문 인식 문제를 피할 수 있습니다. 마찬가지로, 모바일 장치를 감지하기위한 Sec-CH-Mobile 헤더가 있지만, "모바일"장치가 무엇인지 누가 결정합니까? 이 정보를 기반으로 어떻게 결정을 내려야합니까?

일반적으로 서버 측에서 브라우저, 플랫폼 및 버전 정보 (다른 상황에서 다른 코드를 전송)를 이해하는 것이 바람직하지만 이는 클라이언트 측만큼 중요하지만 서버 측에서는 테스트 할 수 없습니다. 동결 된 사용자 에이전트 문자열은 서버가 UA-Ch를 사용하여 마이그레이션 할 수있을 정도로 오래 지속될 수 있어야합니다.

Jon Arne Sæterås는 우려를 표명했습니다.

저는 15 년 넘게 모바일 웹 분야에서 일해 왔으며 크고 작은 많은 웹 사이트가 사용자 에이전트 헤더를 기반으로 장치 탐지에 의존한다는 것을 알고 있습니다. Google 관점에서 UA-Ch로 전환하는 것은 쉬운 것처럼 보이지만 이것이 바로이 변화를 주도하는 팀이 그 영향을 이해하지 못하는 곳입니다.

장치 감지 기반 기능은 프론트 엔드 코드뿐만 아니라 중요하고 널리 사용됩니다. 대형 소프트웨어 시스템과 백엔드 코드는 전체 인프라 스택과 마찬가지로 장치 감지에 의존합니다.

메인 코드 기반에서는 소량의 서버 측 UA 감지를 수행합니다. 우리는 브라우저 (Browser)라는 레일 보석을 사용하여 우호적 인 API에 UA 유래 정보를 노출시킵니다. 나는 다음과 같이 쓸 수 있습니다.

 Browser.safari?
  # Safari 코드 종료

또한 고객에게 사용하기 위해이 보석의 정보를 클라이언트에 노출시킵니다. 프론트 엔드 및 백엔드에는 사용 인스턴스가 거의 없으며 이러한 인스턴스는 다른 방식으로 쉽게 처리 할 수있는 것 같습니다.

과거에는 첫 페이지가로드 될 때 유용한 방식으로 프론트 엔드 정보를 서버로 전달하는 것은 약간 까다로웠습니다 (UA는 뷰포트 크기 및 기타 정보를 알지 못했기 때문에). 매우 영리한 작업을 수행하고 골격 페이지를로드하고 뷰포트 너비와 화면 크기를 측정하기 위해 작은 자바 스크립트 코드를 실행 한 다음 쿠키를 설정하고 페이지를 강제로 새로 고치는 것을 기억합니다. 쿠키가 존재하면 서버에 필요한 정보가 있으며이 요청에서 골격 페이지가 전혀로드되지 않습니다.

이는 복잡하지만 서버는 서버 측에서 뷰포트 너비 정보를 얻을 수 있으며, 이는 다른 HTML과 같은 작은 화면 리소스 (예 : 다른 HTML)를 전송하는 데 매우 유용합니다. 그렇지 않으면 불가능합니다.

UA-Ch는 정상적인 클라이언트 프롬프트와 혼동되어서는 안되기 때문에 이것을 언급했습니다. 서버를 Accept-CH 헤더를 보내도록 서버를 구성한 다음 클라이언트 코드가 다시 전송할 정보를 화이트리스트로 만들 수 있어야합니다.

<meta content="DPR, Viewport-Width" http-equiv="Accept-CH">

이는 서버가 후속 페이지로드에서 클라이언트 로부터이 정보를 얻을 수 있음을 의미합니다. 이것은 멋진 API이지만 Firefox와 Safari는 그것을 지원하지 않습니다. 두 브라우저 모두 얼어 붙은 UA 문자열로 인해 UA-Ch에 관심이 있다면 개선 될지 궁금합니다.

위 내용은 동결 사용자 에이전트 문자열의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!