솔직히 재현하기가 정말 어렵습니다! 매우 일관성이 없고, 패턴을 찾지 못했습니다.
2개의 좋아요
@pmusaraj 간단한 질문인데 -
이 문제가 discourse 전체와 관련이 있는지, 아니면 특정 테마와 관련이 있는지 어떻게 생각하시나요? 아직 특정 컴포넌트로 좁히지는 못했지만, 이렇게 하면 해결될 수 있을지 고민 중입니다.
특정 테마나 컴포넌트의 문제라고 생각하지 않습니다. Discourse 전체와 관련된 문제일 가능성이 높습니다. 이번 주早些에 거의 컴포넌트가 설치되지 않은 Discourse 사이트에서 이를 재현했습니다.
3개의 좋아요
공유해 주셔서 감사합니다! UX가 너무 엉망이라서 답답하네요. 사용자들이 페이지를 새로고침하거나 뒤로 가야 하는 상황이니까요. 그냥 임시방편으로 미리 대비해 보려고 합니다.
1개의 좋아요
이 문제는 새로운 discourse discover 서브도메인(사파리 데스크톱)에서 발생하고 있습니다:
문제가 발생하는 것이 무작위적이고 자주 일어나지 않는 것 같습니다. 이런 일이 발생했을 때 문제를 파악하기 위해 진단 테스트를 실행할 방법이 있을까요?
4개의 좋아요
지금까지의 분석에 따르면, 디스코urses 서브도메인은 여전히 호스트로 인식되어 상대 경로로 지정된 자산/링크가 깨지는 문제가 발생합니다. 즉, 절대 경로(예: /css/main.css 대신 discourse.org/css/main.css)를 사용하지 않는 한 정상 작동하지 않습니다. 그러나 이는 아이콘, 이미지, href, js, css 등 모든 항목에 적용해야 하므로 상당히 비합리적인 우회 방식입니다.
1개의 좋아요
이 문제는 Safari에서만 데스크톱과 모바일 모두에서 발생합니다.
- 필수 페이지 부분(외부 도메인)은 외부 도메인에 기록되어야 함에도 불구하고 여전히 Discourse 로그에 표시됩니다. 언제 발생하는지 디버깅할 수 없었습니다
- 하나의 해결책(모든 CSS/JS/HREF를 절대 경로로 변경하는 대신)은 관련 페이지(외부 도메인)의 헤더에 <base href=“https://mydomain.com/”>를 배치하는 것입니다
2개의 좋아요
이 문제를 지적받기 전에 관련 이슈를 보고했습니다. 이 문제는 그와 관련이 있는 것으로 보입니다.
우리는 2일 전에 Discourse 3.2로 업그레이드했으며, 그 이후로 비슷한 문제에 대한 보고를 받고 있습니다. 우리 경우 CSS와 직접적인 관련은 없지만, 근본적인 문제는 동일한 것 같습니다.
Discourse에서 메인 웹사이트로 이어지는 링크를 따랐을 때, 브라우저는 여전히 포럼에 있는 것으로 인식합니다: 브라우저의 URL이 그렇게 표시하고 있기 때문입니다(!). 그리고 때때로(일부? 아마도 상대 경로) 링크가 포럼 도메인에서 열리며, 포럼 페이지가 존재하지 않는다는 오류가 발생합니다. 지금까지 받은 보고는 모두 iPhone/iPad에서 발생했습니다. 저는 이를 재현할 수 없지만, 영향을 받는 사용자들은 하루에 몇 번씩 이를 경험하는 것 같습니다. Discourse 로그를 확인해 보니, 메인 웹사이트에만 존재하는 페이지에 대한 404 요청이 여러 건 있음을 확인할 수 있었습니다.
브라우저가 한 웹사이트를 열면서 다른 웹사이트의 URL을 표시하는 것(iframe 없이)에 대해 매우 당황스럽습니다. 이것이 Safari 버그라면, 보안상의 함의가 꽤 심각할 수 있으므로 특정 최상위 도메인 내에서만 제한되기를 바랍니다.
어쨌든, 이것이 Discourse 3.2로 업그레이드한 후에만 발생하기 시작했다는 점을 염두에 두어야 합니다. 즉, 3.1 이후에 이 문제를 유발하는 것이 변경되었습니다.
완전한 추측일 수 있지만, 이것이 PWA 앱과 Safari가 이를 처리하는 방식과 관련이 있을 수 있다고 생각합니다. 우리의 메인 웹사이트는 PWA 앱을 선언하고 있으며, Discourse 포럼도 마찬가지입니다. 둘 다 standalone 모드와 start_url: "/"를 사용하며(우리는 고유한 id를 설정하지만 Discourse는 설정하지 않음). AFAIK, PWA 매니페스트 파일은 특정 호스트명을 지정하지 않으므로, 호스팅되는 특정 도메인에 따라 작동한다고 가정합니다. 우리 경우, 두 PWA는 서로 다른 서브도메인이지만 같은 도메인에 있습니다. 브라우저가 이를 처리하는 방식에서 혼란을 일으켜 브라우저가 혼란에 빠질 여지가 있을 수 있습니다. 하지만 다시 말하지만, 이는 단순한 추측일 뿐입니다.
2개의 좋아요
이것이 일반적인 링크(우리의 경우 상단의 내비게이션 아이콘)에서 오는 것이라면, target=_blank(또는 target=_top?)을 임시 우회 방법으로 사용할 수 있을까요?
기억이 맞다면, HREF를 'window.open’을 실행하는 JS:function으로 교체하는 방법도 시도해 보았지만 여전히 같은 결과가 나왔습니다.
기억해 두세요: 외부 페이지는 실제로 가져오고 있습니다. 따라서 이 새로운 도메인에 대한 DNS는 정상적으로 작동합니다. 하지만 스크립트를 실행하고 해당 페이지의 상대 경로 리소스를 가져올 때 그 도메인으로 전환되지 않습니다. 따라서 제가 말했듯이, Safari 내부의 “base” HREF는 페이지 가져오기 과정에서 업데이트/전환되지 않으며, 이로 인해 현재 “base” 도메인에 상대적으로 로드되어 404 오류가 발생합니다.
의도적으로 Discourse에서 JS나 CSS를 로드하는 것이 가능한가요?
target=_blank 방식을 시도해 보았고, 지금까지의 보고에 따르면 문제가 사라졌다고 합니다. 완벽하지는 않지만, 이 문제에 대해 더 명확한 해결책이 나올 때까지 임시 대안이 있는 것은 좋은 일입니다.
참고로, 이 문제는 사용자가 링크를 클릭할 때만 발생하는 것이 아니라, JavaScript "리다이렉트"에서도 발생합니다.
저희 포럼에서는 SSO를 사용하며, 로그아웃 리다이렉트를 메인 웹사이트의 URL로 설정해 두었습니다. 사용자가 포럼에서 로그아웃하면 Discourse가 사용자를 메인 웹사이트로 "리다이렉트"하는데, 이 경우에도 Safari에서 문제가 발생합니다. 콘솔을 확인해 보면 실제 302 리다이렉트가 아니므로, 아마도 window.location을 사용한 것 같습니다.
여기서 논의하고 디버깅을 도와주셔서 감사합니다.
이 우회 방법은 시도해 보기 충분히 간단하므로, 테마 컴포넌트를 통해 이 사이트(meta.discourse.org)에 추가했습니다. 만약 이 방법으로 문제가 해결된다면, Webkit 개발자들이 근본적인 문제를 디버깅하는 데 도움이 될 것으로 생각되므로 상당히 유용할 것입니다. (그리고 별개로, Discourse 코어에 기본적으로 base 태그를 추가하는 것도 평가해 볼 수 있습니다.)
제 생각에는 base 태그 워크어라운드가 외부 사이트에 적용될 때 도움이 될 수 있습니다. 문제가 discourse 웹사이트를 떠난 후에 발생하는 것 같으니까요.
테스트가 meta에서 진행되는 이유는 두 개의 서로 다른 discourse 인스턴스 사이의 링크라는 특정 사례를 처리하기 위해서인가요? 아니면 제가 어딘가에서 헷갈린 건가요 (아주 가능할 것 같습니다! 
)?
1개의 좋아요
네, 저희가 가장 흔히 겪는 문제는 서로 다른 두 디스코URS 인스턴스 간의 링크 관련 문제였습니다. base 태그를 우회 수단으로 사용하는 것이 소스 사이트(출발지)에 적용되고, 대상 사이트가 디스코URS 인스턴스가 아닌 경우에도 도움이 될 수 있다고 생각합니다. 근본적인 문제가 Safari/WebKit이 기본 URL을 혼동하고 있는 것이라면(이것은 위에서의 PWA 추측과 크게 다르지 않습니다), 어느 한 사이트에 다른 base를 추가함으로써 문제의根源이 되는 잘못된 전제를 깨뜨리는 데 도움이 될 수 있습니다. 이 역시 제 추측이지만, 시도해 볼 가치가 있습니다.
1개의 좋아요
좋은 지적입니다. 실제로 깨지는 것 같습니다. base 태그가 포함된 컴포넌트를 임시로 비활성화했습니다.
3개의 좋아요
안녕하세요 
제가 새 사용자인지 아닌지는 모르겠지만, 지금 iPad에서 무슨 일이 일어나고 있는지 테스트해 봤습니다. 브라우저 내비게이션이나 슬라이드 제스처로 페이지를 전환할 때마다 항상 발생하는 것을 확인했습니다. 다른 경우에도 가끔 발생하기도 합니다. Meta 브랜드 테마의 홈 페이지에서 검색창 버튼으로 매우 쉽게 재현할 수 있습니다.
영상에서 첫 번째는 브라우저 내비게이션으로 뒤로 가고, 두 번째는 슬라이드 제스처로 뒤로 가며, 세 번째는 로고를 클릭하여 뒤로 갑니다.
7개의 좋아요
와, 맞아요. 데스크톱 Safari에서 해당 단계를 따를 때마다 문제가 재현됩니다. 잘 찾아주셨네요 @Don 
텍스트로 정리하면 다음과 같습니다:
-
Safari에서 meta.discourse.org 열기
-
“Guides” 클릭
-
뒤로가기 (버튼, 제스처, 키보드 단축키 등 어떤 방식이든)
-
discourse.org/pricing으로 연결되는 링크인 “Our Hosting” 클릭 -
깨진 페이지 확인.
window.location은 여전히meta.discourse.org인데, HTML은discourse.org/pricing에서 온 것입니다.
9개의 좋아요