이 문제가 여러 부작용이 발생되고 있습니다.

 

우선 글 작성 직후 url을 참조해서 어딘가에 그대로 보내는 경우 긴주소로 전달이 됩니다.

 

신디케이션을 사용시 네이버쪽으로 긴주소로 전달되어 문서가 중복 색인이 되는 일이 생기구요.

 

또 여타 애드온에서 글 작성 직후 표시되는 글 주소를 어딘가에 전달할 경우 긴주소로 전달합니다.

제가 확인한 애드온은 구글단축주소 애드온이 그랬습니다.

 

최근 코어에서 무엇이 변경되었는지 안그랬는데 갑자기 한달 이내의 기간 사이에 글 작성 직후 짧은주소가 아닌 긴주소로 보여주고 있습니다.

 

 

수정 : 글 작성 직후 긴주소로 보여지는건 원래 그랬고 글 작성 중 게시글 주소를 긴주소로 가져가게 하는 것으로 바뀐 것 같습니다.

 

이를 정상적으로 다시 고치고 싶네요.

 

https://github.com/xpressengine/xe-core/issues/2170

https://github.com/xpressengine/xe-module-syndication/issues/10

웹지기

profile
10년을 다루다 보니 이제 간단한 것도 만들고 커뮤니티 운영에 관한 다양한 노하우가 있습니다. 어려운 점이나 가지신 생각을 함께 소통해 보아요.
https://rxtip.kr/ 라이믹스 꿀팁
  • profile
    .htaccess 파일은 잘 업로드 되었나요?
  • profile profile
    네. 저희 사이트만의 문제가 아니고 XE 사이트 전체 문제에요. XE공홈에도 글 작성을 해 봤습니다. 동일한 문제를 가지고 잇습니다. 제가 파악한 바로는 최근에 발생된 문제 같아요.
  • profile profile
    앗. 지금보니 웹지기 님이었군요.

    게다가 짧은 주소가 아예 작동하는게 아니라 둘다 수집해가는 거였네요~

    엉뚱한 답변 죄송합니다!
  • profile profile
    짧은주소는 rss 사용하면 가져가구요. 긴주소로 중복 가져간건 신디케이션으로 가져가서 그런데 제가 본문에 언급한 문제 때문입니다.
  • profile

    XE에서 글 작성 직후에 넘어가는 주소는 항상 긴주소입니다. 최근에 바뀐 게 아닙니다. 라이믹스에서는 1년여 전에 패치해서 짧은주소로 넘어가도록 했고요.

    POST 요청 상태에서 getUrl(), getFullUrl() 등의 함수를 호출하는 경우 POST로 넘어온 개인정보가 URL에 포함되어 나오는 보안문제가 있어서 1.8.44쯤에 고쳐졌습니다. 따라서 POST 요청 상태, 즉 글쓰기 직후가 아닌 글쓰기 요청 도중에 URL을 생성하는 서드파티 자료가 있다면 여기에 영향을 받았을 수도 있습니다.

     

    그러나 mid와 document_srl만 넘겨주면 짧은주소를 반환한다는 규칙은 변하지 않았으니, 예전에 불필요한 다른 파라미터 때문에 긴주소로 나오던 것이 짧은주소로 바뀌었다면 몰라도 예전에 짧은주소로 나오던 주소가 긴주소로 바뀔 가능성은 낮습니다.

  • profile profile

    네. 기억에 의존하기 때문에 최종 출력 주소는 예전부터 긴주소 였을 수 있습니다.
    하지만 
     즉 글쓰기 직후가 아닌 글쓰기 요청 도중에 URL을 생성하는 서드파티 자료가 있다면 여기에 영향을 받았을 수도 있습니다.

    이부분이 영향을 받는 것 같습니다. 최근에 부터 생긴 변화에요.

     

    시기적으로 봐도 1.8.44 업데이트 시기와 거의 맞는거 같습니다.

  • profile profile
    그렇다면 코어에서 보안상 변경된 것이 잘못이 없다면
    서드파티에서 이를 받아서 짧은주소로 변환하는 것이 필요하겠습니다.

    신디케이션은 XE팀에서 담당을 하니 고치면 될 것이고 제가 고친 애드온 처럼 이렇게 주소를 가져갔다면 고쳐야 하는 상황이 벌어진거네요.
  • profile profile
    서드파티 자료에서는 mid와 document_srl을 사용해서 URL을 조립하는 것이 가장 확실합니다.

    예: getFullUrl('', 'mid', $mid, 'document_srl', $document_srl)

    맨 앞에 반드시 빈 문자열('')이 들어가야 하고, mid와 document_srl 이외의 변수는 일체 넣지 마시고요.

    맨 앞에 빈 문자열('')을 넣지 않으면 현재 요청에 들어온 파라미터들을 그대로 다 집어넣고, 거기다가 변수를 또 추가하는 변태스러운 상황이 발생합니다. 현재 주소에서 page만 바꾸는 등 간단한 조작을 할 때 쓰라고 있는 기능 같은데, 위와 같이 정상적인 동작을 하는 것보다 오히려 이게 더 간결하기 때문에 서드파티는 물론 코어에서도 별 생각 없이 쓰다가 개인정보 노출 사고가 일어나곤 합니다. URL 생성시 맨 앞에 빈 문자열('')을 넣지 않는 부분이 눈에 띈다면 거기를 제일 먼저 의심해 보셔야겠네요.
  • profile profile
    네. 제가 말한 애드온은 말씀 하신 것으로 제가 어제 고쳤습니다.
    그런데 신디케이션 모듈은 코드를 봐도 엄두가 나지 않으니 그냥 멍 하고 있었구요.

    코어에서 유지할 것이면 신디케이션에서 짧은주소를 선택한 사이트는 짧은주소로 api쪽으로 전송할 수 있께 빨리 조치가 되어야 할텐데.. XE팀이 과연 이걸 언제 처리할지...

    답답하네요.
  • profile profile
    XE의 게시글 소스에는 이런 소스가 들어있습니다.

    <--script>
    var current_url = "https://xe1.xpressengine.com/?mid=devlog&document_srl=23244976";
    var request_uri = "https://xe1.xpressengine.com/";
    var current_mid = "devlog";
    var waiting_message = "서버에 요청 중입니다. 잠시만 기다려주세요.";
    var ssl_actions = new Array();
    var default_url = "https://xe1.xpressengine.com/";
    var enforce_ssl = true;</script-->


    혹시 신디케이션에서 핑을 받은 네이버에서 이 문서를 크롤링해가면서 전달받은 url이 아닌 위 소스에 영향을 받아 저 주소로 기록해 버리는거 아닌가 의심스럽습니다.
  • profile profile
    current_url은 짧은주소를 일부러 길게 풀어쓴 것으로, 페이지수나 댓글번호 등의 변수를 추가할 일이 있으면 참고하라고 있는 것입니다......만, 혹시 그대로 사용하는 자료가 있다면 문제가 될 수도 있겠지요.
  • profile profile

    최근의 문제라고 생각하기에는 근거가 부족하다는 생각이 들었습니다. 동일한 문제가 발생한 애드온 코드를 확인해 보니 $current_page = getenv('HTTP_HOST').getenv('REQUEST_URI'); 이렇게 되어 있어서 아마 짧은 주소로 가져오지 못했을 가능성이 높네요. 글작성시 주소창에 표시되는 긴주소를 가져갔을 것 같아요.

    이 애드온 설치 시점이 우연히 1.8.44 시점하고 맞아서 그때부터 그랬던 것으로 착각하게 했던 것 같습니다.

     - 애초에 이 애드온은 처음 설치시 부터 긴주소를 가져가고 있었던 것인데 제가 확인을 못했네요.

    XE는 원래부터 문제를 가지고 있었던 것 같습니다.

    SEO모듈에서 네이버쪽으로 전달하는 주소는 분명 짧은 주소로 전달하지만 네이버에서 그 주소로 다시 방문해서 긁어갈때는 어딘가에 있는 긴주소를 문서의 주소로 가져가서 색인해 버리는 것이라는 정황이 거의 확실해 가고 있습니다.

    SEO모듈에서 네이버쪽으로 던진 문서 url과 요약을 확인도 없이 그냥 색인해 버리지는 않을 것 같습니다. ping을 날릴때 전송한 url은 방문예약을 위한 주소로 정확한 주소를 신디케이션모듈에서 네이버봇으로 던졌다해도 이후 봇이 그 정보로 해당 문서를 방문했을때 인식되는 문서주소가 결국 올바르지 못하다는 추측입니다.