올해 초 런던에서 열린 FullStack 컨퍼런스에서 iFrame을 다시 시원하게 만드는 것에 대해 이야기했습니다. 죄송합니다. 비디오를 보려면 로그인 해야 합니다. FullStack에서 듣고 있는 사람이라면 이 비디오를 공개 할 수 있다면 정말 좋을 것입니다.
왜 iframe으로 귀찮게 합니까?
간단히 말해서 : iframe을 사용하면 사용자 환경을 포함 가능한 '도메인 간 구성 요소'에 구축하여 사용자가 리디렉션되지 않고 다른 사이트와 상호 작용할 수 있습니다. 추적 및 광고 이외의 용도로는 엄청나게 많은 용도가 있습니다. 이 목적을 위해 더 가까이 다가오는 것은 없습니다. 그 결과, iframe을 최대한 활용하고 있지 않다고 생각합니다.
https://medium.com/@bluepnume/iframes-are-just-terrible-heres-how-they-could-be-better-974b731f0fb4
그래도 큰 문제가 있습니다
이 이야기는 iframe (및 팝업 창)이 실제로 나쁜 것들 중 일부를 다루었습니다.
해결책이 있습니까?
내 이야기는 PayPal에서 iframe과 팝업의 주요 문제를 해결하기 위해 zoid를 작성하는 방법에 대해 이야기했습니다.
Zoid는 iframe과 팝업에 다음과 같은 멋진 기능을 추가합니다.
그래서 우리는 좋은가요?
조이드는 먼 길을 간다. 그러나 단순한 자바 스크립트 라이브러리로 해결할 수 없는 특정 문제가 있습니다. iframe을 웹에서 일류 시민으로 만들려는 브라우저 공급 업체의 버킷 목록입니다.
기본적으로 : 도메인 간 내장형 구성 요소에 대한 아이디어는 실제로 사용자가 추적하고 광고하는 것보다는 공유 가능한 사용자 경험에 대해 이야기하기 시작한 후에는 아무도 거의 삼키지 않는 환약입니다.
여기 내 목록이 있습니다.
클릭 재킹 방지
iframe 내부에서 다음을 확인하는 방법이 있어야 합니다.
이 iframe이 상위 페이지에서 완전히 표시됩니까? 다음을 확인해야 합니다.
이를 통해 iframe은 클릭을 진정으로 신뢰하고 그렇지 않으면 위험한 조치를 수행 할 수 있습니다. 즉, 메시지를 보내거나 거래를 승인하거나 프로필의 설정을 변경하는 등 다른 방법으로 로그인 해야 하는 작업입니다.
iframe의 도메인을 쉽게 볼 수 있는 방법 제공
이것은 iframe 위로 커서를 가져 가거나 내부의 요소에 초점을 맞출 때 또는 사용자가 언제든지 상호 작용하는 도메인에 대한 아이디어를 제공 할 때 보조 URL 표시 줄로 구현 될 수 있습니다.
이것이 없으면 : 브라우저 개발 도구를 사용하지 않고 문자 그대로 불가능하며, 사용자가 어떤 도메인을 다루거나 정보를 입력하고 있는지 확인할 수 있습니다. 사용자 입력을 받아들이는 건물 구성 요소가 매우 필요합니다
쿠키에 대한 권한 메커니즘 제공
예, 추적 및 광고 방지는 합리적인 목표입니다. 나로부터 논쟁이 없다.
그러나 타사 쿠키 제한 및 지능형 추적 방지 기능은 내장 된 경험을 노출하고 추적과 거의 관련이 없는 iframe에 부정적인 영향을 미칩니다. 내장형 iframe 기반 구성 요소를 빌드 하는 경우 적어도 해당 iframe 내부에서 쿠키를 읽고 쓸 수 있는 권한을 사용자에게 요청하는 방법이 있으면 좋을 것입니다.
이 권한은 iframe과 실제로 사용자가 상호 작용 한 후에 만 부여되어 숨겨진 프레임이 사용자에게 많은 권한 요청 노이즈를 유발하지 않도록 방지 할 수 있습니다.
Storage Access API는이 문제를 해결하는 데 도움이 되었지만 아직 대부분의 주요 브라우저에서는 구현되지 않았습니다.
iframe을 통해 창 참조를 전달하는 방법 추가
이것은 좀 더 기술적 인 요청입니다. 하지만 지금은 postMessage를 통해 다른 창 (팝업 또는 iframe)에 대한 참조를 보낼 수 있는 방법이 없습니다.'
따라서 window.frames를 재귀 적으로 순회하거나 다른 메커니즘을 사용하지 않고 메시지를 보내야 할 때 창에 대한 참조를 찾기가 어려워집니다 (여기에서 모두 간략하게 설명했습니다). 때로는 참조를 얻는 데 사용할 수 있는 메커니즘이 없기 때문에 포스트 로봇의 ProxyWindow와 같은 해키 접근 방식이 발생합니다.
postMessage를 사용하여 창에 대한 참조를 보내거나 일종의 getWindowID 및 getWindowByID를 제공하면 완전히 안전합니다 (창의 실제 내용은 완전히 샌드 박스로 유지됨). 기존의 해키 접근 방식을 피하기 위해 브라우저가 이를 지원할 수 있다면 좋을 것입니다.
우선 순위가 높은 iframe 렌더링
현재 iframe은 종종 다른 모든 것들 뒤에 브라우저에 의해 지연됩니다. 이 iframe에로드 된 UI가 사용자 경험에 실제로 중요하므로 가능한 한 빨리 로드를 시작하십시오. 더 높은 우선 순위를 설정하는 방법을 원합니다.
대부분의 iframe이 추적에 사용된다고 가정하고 추적이 게으르면 문제가 되지 않기 때문에 이미 추가되지 않았을 것입니다. 그러나 사용자 경험은 가능한 한 빨리 이루어져야 합니다.
Others?
현재 zoid는 iframe의 균열을 해결하고 브라우저 구현이나 API 변경 없이 해결할 수 있는 모든 문제를 해결하는 데 매우 효과적입니다.
다른 모든 것의 경우, 브라우저 공급 업체가 UI 기반 iframe을 웹에서 일류 시민으로 취급하기 시작하고 지금은 채울 수 없는 위의 문제를 해결하는 데 도움이 되기를 바랍니다.
지금까지 포털에서 수행 한 작업이 정말 마음에 듭니다. 나는 단지 iframe이 남겨지지 않기를 바랍니다.
등록된 댓글이 없습니다.
