[regression] 허용된 src 도메인에서 iframe 임베딩 오류

안녕하세요. allowed_iframes에 https://www.tickcounter.com을 추가했는데도 이 스크립트가 여전히 표시되지 않습니다:

<div style="left:0; width:100%; height:0; position:relative; padding-bottom:25%; margin:0 auto"><iframe src="https://www.tickcounter.com/widget/countdown/5847336" style="top:0; left:0; width:100%; height:100%; position:absolute; border:0; overflow:hidden" title="My countdown"></iframe></div>

제가 볼 수 있는 범위에서는 오류 로그에 아무것도 기록되어 있지 않습니다.

허용한 다른 src 도메인의 다른 임베디드 iframe에서도 실패했습니다.

같은 src 도메인에서 동일한 유형의 임베디드 iframe은 지난번에 시도했을 때(대략 6개월 전 또는 1년 전)에는 정상 작동했습니다. 현재 사용 중인 버전은 Discourse v3.3.1 +5(안정성 분기)입니다.

테스트 통과(tests-passed) 브랜치의 최신 버전에서 iframe은 문제 없이 임베드됩니다. 설정한 style과 title 속성은 Discourse에서 제거됩니다. 대신 width와 height 속성을 설정할 수 있습니다. 예를 들어:

<iframe src="https://www.tickcounter.com/widget/countdown/5847336" width="100%"></iframe>

게시물로 이동한 후 브라우저 개발자 도구의 “Elements” 탭을 열면 무엇을 확인하시나요?

개발자 도구의 “Console” 탭을 열면 어떨까요? 오류가 있나요?

:thinking: hmm. 저한테도 이건 정상적으로 작동하는 것 같습니다.

admin - all site settings - allowed iframes:

previewer:

cooked post:

답변 주셔서 감사합니다.

<div class="regular contents"><div class="cooked"></div><section class="post-menu-area clearfix"><nav class="post-controls expanded">…

음, 몇 가지 오류가 있습니다:

Failed to load resource: net::ERR_CONNECTION_REFUSED
beacon.min.js:1

하지만 이것은 제가 사용 중인 DNS 블랙리스트로 보입니다. VPN으로 연결하면 오류가 발생하지 않습니다. 그리고 완전히 다른 컴퓨터와 네트워크를 사용하는 다른 사용자가 처음에 이 동일한 문제를 저에게 보고한 것이 우연일 것 같지는 않습니다.

OK, Firefox에서 다른 콘솔 메시지가 표시됩니다:

Partitioned cookie or storage access was provided to “https://www.tickcounter.com/widget/countdown/4471981” because it is loaded in the third-party context and dynamic state partitioning is enabled.
[자세히 알아보기]

또한 iframe 코드를 골격(static) HTML 파일에 붙여넣고 브라우저에서 열었을 때 iframe이 정상적으로 로드되었음을 언급해야 합니다.

이 iframe은 예전에 당신에게 잘 작동했었는데요… 혹시 Cloudflare를 사용하고 계신가요? 그렇다면 속도 최적화 기능인 Speed Brain을 비활성화해 보시고 효과가 있는지 확인해 보세요. (활성화된 경우) 이 기능은 비교적 최근에 도입된 것이라 잘 알고 있습니다.

안녕하세요, 아니요, 저는 Cloudflare를 사용하지 않습니다.

네, 저는 iframe을 작동시킬 수 있습니다. 포럼에서 무언가가 이를 차단하고 있는 것 같습니다.

음, 네. 그렇게 보입니다. 하지만 Discourse에 /logs/ 디렉토리에 오류가 기록되어 있지 않나요?

서버에서 그걸 차단할 만한 것을 실행하고 있다는 생각은 안 나네요. /etc/resolv.conf에 호스팅 제공자의 DNS를 사용하고 있었고, 8.8.8.8으로 변경해 보았지만 이 문제는 변하지 않았습니다.

오류를 일으키는 경우에만 해당됩니다. 정상적인 기능을 위해 무언가가 이를 차단하고 있을 수 있습니다. 제 추측은 이 문제가 발생하기 전후로 무엇이 변경되었는지 파악해 보는 것입니다. 콘텐츠 보안 정책(CSP) 변경이 영향을 미쳤을지도 모르겠습니다.

DNS 차단 목록을 사용 중인데 이로 인해 문제가 발생하고 있다는 말씀이시니, 그러면 사용을 하지 않는 것이 좋겠네요?

허용된 iframe 설정에

또는

https://www.tickcounter.com/를 추가했나요?

저평판을 가진 도메인을 차단하는 DNS 서비스입니다. 하지만 이것이 문제가 되는 이유는 아닙니다. 1) VPN을 통해 연결하면 다른 DNS를 사용하는데도 이 문제가 계속되고, 2) 이 문제를 제게 보고한 사용자는 완전히 다른 설정을 사용 중이며, 3) DNS 구성은 제 LAN에만 적용되어 있고, 서버 측에서 올바른 HTML 생성에 실패하는 Discourse 서버에는 적용되지 않았고, 4) 이 HTML 파일은 iframe을 올바르게 로드합니다:

<!DOCTYPE html>
<html lang="en">

<head>
  <meta name="description" content="Webpage description goes here" />
  <meta charset="utf-8">
  <title>Change_me</title>
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="author" content="">
</head>

<body>

<div style="left:0; width:100%; height:0; position:relative; padding-bottom:25%; margin:0 auto"><iframe src="https://www.tickcounter.com/widget/countdown/5847336" style="top:0; left:0; width:100%; height:100%; position:absolute; border:0; overflow:hidden" title="My countdown"></iframe></div>

</body>
</html>

오, 그게 문제였군요. 마지막에 /가 빠져 있었습니다.
정말 감사합니다!

Discourse에서 무언가 변경된 것 같습니다. 마지막으로 이걸 시도했을 때 https://www.tickcounter.com을 추가했는데, 그때는 작동했습니다. 제 생각에는 사용하고 있는 정규식 로직이나 설정 설명이 조정되어야 합니다. 설정 설명에는 이렇게 되어 있습니다:

게시글에서 Discourse가 안전하게 허용할 수 있는 iframe src 도메인 접두사 목록

"도메인 접두사"라고 하면 /를 포함하지 않는 도메인 이름과/또는 서브도메인을 떠올리게 됩니다. 아니면 복잡한 iframe src URL에 대해 더 정확한 로직을 사용해야 한다면, 다음과 같이 말하는 것이 좋겠습니다:

게시글에서 Discourse가 안전하게 허용할 수 있는 iframe src URL 접두사 목록

링크를 추가할 때, 필드 아래에 오류 메시지가 표시되어야 합니다. 전방 슬래시 하나 더 필요하다는 내용이죠.

2개월 이상 전에 추가된 링크들(즉, 보안 수정이 병합되기 전)이 문제입니다. 당시에는 오류 메시지가 표시되지 않았고, 기본 링크에도 세 번째 '/'가 포함되지 않았습니다.
이 문제로 인한 지원 토픽은 이번이 적어도 두 번째입니다.

그렇지, 그게 사실인 건 아닌지 궁금했어 — 기존 링크가 어딘가에서 깨진 건 아니었는지 말이야. :thinking:

기존 입력 사항을 확인하여 더 이상 작동하지 않는 링크에 대해 관리자에게 알림을 보낼 수 있을까요?

개인적으로는 URL인데 '도메인’이라고 부르는 점이 가장 큰 혼란의 원인이었다고 생각합니다.