위젯을 만들고 있는데, 그 안에 콘텐츠를 표시하기 위해 iframe을 사용하고 있습니다. 어떤 시점에서 타사 HTML 및 JS를 제공하기 시작할 수 있으므로 iframe이 좋은 아이디어라고 생각했습니다.iframe은 끔찍한 생각입니까?
위젯은 자바 스크립트를 좀 더 복잡하게 만들어 주므로, 이것이 최상의 구현이 아닐지도 모른다.
조언이 있으십니까? 다른 사람들이 iframe에 대해 생각하는 것을 듣는 것은 큰 도움이 될 것입니다.
아니요, iframe에는 문제가 없습니다. Iframe은 제 3 자 콘텐츠 게재를 시작하려는 경우 더 좋은 아이디어 일 수 있습니다.
곧 출시 될 HTML5 사양은 이와 같은 상황에서 iframe에 더 많은 보안 기능을 추가 할 계획이기 때문에 지금도 사용하는 것이 좋습니다.
위젯의 기능에 따라 다릅니다. Iframe에는 장소가 있지만 레이아웃을 복잡하게 만드는 것은 거의 없습니다. 따라서 대부분의 사람들은 절대적으로 필요한 경우가 아니라면 피할 수 있습니다.
내가 최근에 발견 한 한 가지 .aspx 페이지가 내부에 포함되어 있습니다. iframe은 때때로 쿠키 손실 문제가있어서 응용 프로그램에서 세션 상태를 잃어 버리게됩니다.
나를 위해, 그것은 다른 개발 샵이 자신의 페이지에서 내 .aspx 페이지 중 하나를 소비하는 시나리오에서였습니다. 이것은 우리가 별개의 서버에 있었음을 의미합니다.
분명히 이것은 상위 페이지에서 하위 페이지에 대한 쿠키를 거부하여 발생했습니다 ... 세션 쿠키가 진행됨에 따라 세션도 진행됩니다. More Details
이 문제는 파이어 폭스에 영향을주지 않았다,하지만 IE7에 표시 않았고 그것을 몇 시간 동안 진짜 비밀이었다 방법
특정 메커니즘이 작품은 조금 복잡하다.
또한 위에 링크 된 기사와 모순이 될 수 있습니다. 이 기사에서는 포함 된 페이지가 .aspx 인 경우이 정보를 얻지 못한다고 말합니다.이 경우 두 페이지가 모두 .aspx이므로 사실이 아닙니다.
그 기사가이 상황에 대해 말하는 다른 모든 것에 의심을 던지지만 해결책으로 이어 졌으므로 그 점도 도움이됩니다.
HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")
... 그리고 : 페이지의 초기화 이벤트 - (내가 들어 본 적이없는 개인 정보 보호 기본 프로젝트) 헤더를 기사가 제안한 것처럼
, 나는 P3P를 주입하는 다음 코드에 넣어 문제가 해결되었습니다.
iframe은 프레임과 마찬가지로 프레임을 현재 작업에 사용하기위한 컨트롤입니다. 따라서 그 자체로 좋거나 나쁘지는 않지만 당면한 과제와 고객의 요구 사항에 따라 좋거나 나쁠 수 있습니다. 내가 아는 한 모든 최신 브라우저 (및 비 리눅스 사용자)는 문제없이 iframe을 "보고 소비"할 수 있습니다.
좋은 옵션은 오버플로 CSS 속성을 사용하는 것입니다. 기본값은 표시되지만 숨김, 스크롤 또는 자동으로 설정할 수 있습니다. 나는 당신의 경우에 자동을 사용할 것입니다. 콘텐츠가 너무 커지면 iframe이있는 것처럼 보이지만 여전히 페이지에서 올바르게 표시됩니다.
은 다음을 참조하십시오
overflow property 반드시 그렇지는만큼 iframe을 내 콘텐츠를 예측할 수있다.
XMLHTTPRequest가 널리 사용되기 전에 사람들은 전체 페이지 새로 고침을 수행하지 않고 동적 방식으로 콘텐츠를 제공하기 위해 JavaScript와 iframe의 조합을 사용하고있었습니다.
이러한 방식으로 사이트를 개발하는 것에 대한 많은 정보가 있으므로 공격을받을 가능성이있는 많은 장애물에 대한 해결책을 찾는 비교적 쉬운 시간을 가져야합니다.
내가 아는 한 가지는 iframe에서 JavaScript의 교차 도메인 사용입니다. iframe에 삽입 한 페이지가 '상위'페이지와 다른 도메인에있는 경우 브라우저에는 다른 페이지에 액세스 할 수있는 것에 대한 보안 제한 사항이 있습니다. 트릭은 두 페이지를 모두 선언하는 것입니다.
document.domain = 'somedomain.com';
이러한 종류의 대안에 대해 웹에 많은 것들이 있습니다.
행운을 빈다.
나는 document.domain 만 상위 도메인으로 변경할 수 있다고 생각합니다. 즉, www.acme.com은 도메인을 acme.com으로 변경할 수 있지만 google.com으로 변경할 수는 없습니다. 따라서 iframe은 단일 도메인의 하위 도메인간에 통신하는 데 도움이됩니다. (내가 틀릴 수도 있지만 그건 내가 기억하는 것입니다.) – Josh
@Josh - 당신 말이 맞아요, document.domain은 같은 부모 도메인이지만 다른 하위 도메인의 페이지에서만 작동합니다. –
@Josh 당신 말이 맞아요.하지만 언제나'window.location.href'를 사용할 수 있습니다. – nyuszika7h
개인적으로 나는 번복하지 말고 수 있다면 개인적으로는 그것을 피할 것입니다. Javascript (또는 AJAX를 동적으로로드해야하는 경우)를 사용하면 div를 사용하고 필요에 따라 내용을 쉽게 변경할 수 있습니다. 일부 경우이 방법을 사용하면 유연성이 향상되고 JS가 단순화됩니다. 특히 많이있는 경우 위젯과 나머지 페이지 간의 상호 작용
그렇다면 두 옵션을 모두 조사해 보았습니다. JS 경로가 너무 까다 롭거나 복잡한 경우 iframe을 사용해야합니다.
내가 알고있는 "정말로 나쁜"것이 하나뿐입니다. 당신의 제 3 자 일부 자바 스크립트를 않는 경우
, 즉, 조금 너무 일찍 ... IE6와 IE7은 다음 밖으로 빈 iframe을뿐만 아니라, 오 그렇게 인정 "Operation Aborted"오류가 발생합니다 자신의 DOM을 수정하려고 시도 하지만 전체 주변 페이지. (예 : 사이트가 아래에 표시됨)
IE8에서는 수정되지 않았지만 충돌이 더 잘 처리됩니다.
iframe은 해킹 또는 시간 절약 중 하나입니다. 사용하는 경우 이러한 이유로 필요한지 확인하십시오. 콘텐트를 제어 할 수 있거나 미러링 또는 스크래핑을 통해 제어 할 수있는 경우 AJAX 또는 서버 측 포함을 사용하여 외부 데이터를 가져 와서 페이지에서 푸시하는 것을 고려해야합니다. 강력하고 관리하기 쉽습니다.
대체로 iFrame에 기술적으로 아무런 문제가 없습니다. 그러나 의미 론적으로 악이 있습니다.
웹은 지정된 URL이 항상 고유 한 자원으로 연결된다는 HTTP 프로토콜을 기반으로합니다.
iFrame을 사용하면 하나의 URL 뒤에있는 웹 페이지에서 녹아있는 여러 리소스를 모두 제공하기 만하면됩니다. 웹이 어떻게 성장해야하는지에 대해 궁금한 점이 있으면 번거로울 수 있습니다. 게다가 검색 엔진 로봇의 경우 까다 롭습니다.
대다수의 의견에 동의하지 않고 iframe은 이며 끔찍한 아이디어입니다. 잠시 동안 웹 디자인 공동체 내에서 일한 사람은 iframe이 순수한 악이며, 절대적으로이 아닌 한 피해야한다는 것에 동의합니다.
웹 페이지의 탐색 패턴이 깨 졌기 때문에 나쁘다고 믿는 이유가 있습니다. iframe을 사용하면 브라우저의 앞뒤 단추를 효과적으로 중단하고 사용자를 혼동시킬 수 있습니다. 그것은 HTTP 프로토콜 뒤에있는 전체 아이디어를 깨뜨립니다. URL은 항상 고유 한 위치로 이어질 것입니다. iframe은 오래 전에 은퇴했을 것입니다. 콘텐츠를 동적으로 게재하는 다른 방법이 있으며 대신 이러한 콘텐츠를 사용해야합니다.
당신은 Iframe을 (검색 엔진, 즐겨 찾기 나쁜 등 나쁜) 사라 사용과 즉각적인 우려를 위젯를 만드는,하지만 어느 쪽이든 내용은 더 나은 오히려 새 창에서 동적으로 또는 제공 될 경우 iframe보다
-1 다른 답변에서 말했듯이 : "그 자체로도 좋지도 나쁘지도 않지만, 당면의 과제에 따라 좋거나 나쁠 수 있습니다." 또한 뒤로 및 앞으로 버튼과 관련된 문제는 iframe에 국한되지 않으며 다른 동적 콘텐츠에서도 발생합니다. – Christophe
iframe은 악의가 아니며 단지 다른 도구와 같으며 장점을 결정하기 위해 사용되는 문맥을 결정해야합니다. Google 이미지 검색 및 기타 유명 프로필 사이트는 제한된 목적으로 iframe을 사용합니다.
일반적으로 브랜딩에 사용되거나 사용자가 사이트 외부로 사용자를 리디렉션하는 사이트로 돌아갈 수 있도록합니다.
예를 들어 교차 도메인 iframe을 사용하는 경우 페이지가 게재되는 외부의 도메인을 참조하는 iframe은 보안상의 이유로 디자인 상 제한되며 연결된 도메인 외부의 DOM 내부에 javascript를 통해 액세스 할 수 없습니다.
많은 사이트가 자신의 사이트가 퍼가기를 방해하며 iframe을 스트라이프 (해당 URL로 상위 URL을 리디렉션)합니다.
재 : "HTTP 프로토콜 뒤에 전체 아이디어, URL을 항상 독특한 위치로 이어질 것"나는 보안 및 scaleability에 대해 동일한 URL에서 내 전체 CMS 서비스를 제공
(GET 대신 POST 주로 사용 매개 변수). 인증없이 보안 컨텐츠를 볼 수 없기 때문에 새로운 페이지마다 인증을 걱정할 필요가 없기 때문에 디스패치 시스템을 사용하면 쉽게 개발할 수 있습니다.
또한 일부 애플리케이션의 경우 SEO는 적용 할 수 없습니다 (예 : 웹 기반 ERP).
PHP로 생성 된 어셈블리 트리에서 컨텐츠를 제공하기 위해 iFrame을 사용합니다. 사용자가 파트/어셈블리에 대한 세부 정보를 보려고 할 때마다 트리 (및 노드 가시성)를 새로 고치지 않습니다.
나는 귀하의 사용자 중 하나가 아니므로 다행입니다! (* all *!에 북마크 할 수 없음) – SamB
usability and accessability issues with iframes이 여러 개 있습니다. 일부 브라우저 및 스크린 리더가 iframe을 표시 할 수 없습니다, 그래서 당신은 대체 콘텐츠를 제공해야한다 : 당신이 제 3 자 콘텐츠를 제공하는 시작하면, 당신이 그것을로드가 완료된 후 초점을 잡는 iframe을 조심해야한다
<iframe src="content.html">
<p>
This content will only be displayed by browsers that do not support
iframes. You should provide a link to the content, or in your
case an alternative way to use your widget.
</p>
</iframe>
. 일반 사용자에게는 사소한 불편이 있지만, 스크린 리더를 사용하는 사용자에게는 매우 혼란 스러울 수 있습니다.
iframe에 대한 언급이 거의 없지만 나에게 쌓인 버그가있는 중요한 문제가 있습니다.
우리 동료는 우리가 Google Docs 스프레드 시트에로드 한 동적으로 변하는 데이터베이스에 투자하여 평생 동안 노력하고 있습니다. 그런 다음 Google은 지원 자료와 함께 사이트에 표시합니다.
누군가가 내 페이지 소스에서 iframe 코드를 가져 와서 페이지에 밀어 넣는 것을 막을 수있는 방법은 없습니다. 이제 그들은 우리의 모든 데이터를 얻고 있습니다. 몇 분 전에 바로 새로 고침을 받았으며 전혀 페이지가없는 상태였습니다.
Google iframe을 특정 도메인에 연결할 수 있으면 해당 트랙에서 멈출 수 있습니다.
밝은 아이디어가 있습니까?
이것은 꽤 오래되었지만 여전히 해결책을 찾고 있다면'X-Frame-Option' 헤더를 사용하여 누가 iframe을로드 할 수 있는지 제한 할 수 있다고 생각할 수 있습니다. 자, 당신은 분명히 당신이 그것을 제어하지 않는 것처럼 구글 문서 URL에이 헤더를 적용 할 수 없습니다. 하지만 당신이 할 수있는 일은 직접 Google 워드 프로세서 URL을 사용하는 대신 구글 사이드 URL로 서버 리디렉션을 수행하는 자신의 URL을 생각해내는 것입니다. 그런 다음 적절한 'X-Frame-Option' 헤더를 자신의 URL에 적용 할 수 있습니다 – Suhas
I +1 여기에서 유일한주의 사항은 실제로 사용이 실제로 이상적인지 확인하는 것입니다 (예 : 필요한 데이터를 얻기 위해 Ajax를 단순히 사용하는 대신 서버가 항상 "제 3 자 콘텐츠 아웃 오브 밴드 (out-of-band) 호출을 통해 검색 될 수 있습니다. –