일부 콘텐츠 관리 시스템에 URL 삽입 문제 (URL 삽입 문제)가 발생하지 않도록 방지하려면 어떻게해야합니까?

Question

실제 문제로 인해 시스템이 이러한 종류의 URL을 허용하지 못하게하는 것을 이해하지 못합니까?

http://www.washingtonpost.com/hey-this-url-doesn't-mean-a-damn-thing/gIQAocHrpJ_story.html 

나는 무슨 일이 일어나고 있는지 알고 있습니다. 라우팅 시스템은 마지막 백 슬래시 뒤에 키를 찾습니다. 그리고 나서 버전을 만들기 위해 밑줄 뒤에 나오는 것을 파싱합니다.

그래서 : washingtonpost.com/whatever/gIQAocHrpJ_story.html은 우리에게 washingtonpost.com/whatever/gIQAocHrpJ_print.html 우리에게 washingtonpost.com/whatever/gIQAocHrpJ_mobile.html이 우리에게 가져다 일반 인쇄 버전을 제공합니다 일반 이야기 버전을 제공합니다 모바일 XML 버전

이상하게도 .html을 .js 또는 .xml과 같은 다른 일반적인 확장자로 변경하거나 전혀 변경하지 않아도 동일한 페이지가 다시 나타납니다. 그러나 .fffuuu와 같이 비표준으로 변경하면 사용자 친화적 인 404 페이지 또는 전체 빈 페이지가 나타납니다. 마치 CMS 프로그래머가 생각 나게했던 처음 몇 가지 파일 형식을 허용하고 시스템에서 모두 동일하게 취급하게하는 것과 같습니다.

나는 레일스와 워드 프레스에서만 간단한 사이트를 만들었 기 때문에 접두사 상수가 검색 속도에 어떻게 영향을 줄 수 있는지와 같은 URL 패턴에 대한 간단한 개념을 이해합니다.하지만 운율이 없다고 생각하는 것은 잘못되었습니다. 위의 디자인 패턴에 대한 이유?

당신을 기쁘게 생각합니다. 워싱턴 포스트는 최근에 막대한 재 설계를 마쳤습니다. 이것은 레거시 시스템으로 할려고하는 것이 아니라 CMS 설계자가 현대 모범 사례를 자유롭게 채택 할 수있는 것입니다. 나는 그들이 채택한 url-design-pattern의 장점을 보지 못했다. 단, CMS 디자이너는 더 잘 알지 못한다.

현재 시스템이 고유 키가있는 사람이 읽을 수있는 필드가있는 데이터베이스 모델보다 빠른 이유는 무엇입니까?

http://www.washingtonpost.com/HUMAN-READABLE-KEY/UNIQUE_KEY.html

도메인 슬래시 최종 슬래시 사이 패턴은 사람이 읽을 수있는 키이다. 시스템은 UNIQUE_KEY로 레코드를 찾은 다음 사람이 읽을 수있는 키가 해당 레코드에 대해 DB의 내용과 일치하는지 확인합니다.

링크의 공식 버전에서는 홈페이지에서 생성되므로 연/월/일 정보가 포함되어 있습니다. 다시 말하지만, 당신이 그것들을 바꿀 수 있고 동일한 페이지를 얻을 수 있기 때문에 의미가 없습니다 (고맙게도, JS는 그것들을 파싱하는 것에 의존하지 않는 것 같습니다).

CMS 디자이너가 뉴스 스토리가 8/20/2011에 깨뜨릴 수 있기 때문에 CMS 디자이너가 날짜에 구속되기를 원하지 않는다고 생각하지만 인쇄본 버전은 2011 년 8 월 21 일에 실시간으로 전송됩니다 ... 물론, URL에 날짜가 전혀없는 것입니다. URL이 으로 변경 될 수있는 경우 사용자에게 문서 관련 정보가 포함되도록 사용자를 교육시키지 마십시오.

도메인 이후의 첫 번째 용어조차도 의미하지 않습니다. 따라서 :

http://www.washingtonpost.com/politics/mitt-romney-debates-us-economy/gIQAocHrpJ_story.html 

는

http://www.washingtonpost.com/sex/mitt-romney-debates-us-economy/gIQAocHrpJ_story.html 

같은 이야기로 이동합니다 마지막으로, 구글과 다른 검색 엔진하지이 플레이 혼란을합니까?

Answer 1

이 주요 이유는 헤드 라인이 변경 되어도 독자가 계속 이야기에 도달 할 수 있는지 확인하기 위해서입니다. "슬러그"(사람이 읽을 수있는 키 : mitt-romney-debates-us-economy)는 일반적으로 페이지의 제목 또는 제목 텍스트에서 자동 생성됩니다. 어떤 오래된 CMS에서, 이것이 잘 생각되지 않은 곳에서, 헤드 라인을 변경하면 종종 URL이 이전과 동일하게 남아있게됩니다. 상상할 수 있듯이, 원래의 제목이 잘못 선택되었을 때, 이것은 매우 당혹 스러울 수 있습니다.

결과적으로 대부분의 CMS 개발자는 ID를 기반으로 스토리를 조회하는 것으로 바뀌 었습니다. ID가 변경되지 않았는지 확인하는 것이 훨씬 쉽습니다. 그렇다면 슬러그와 어떻게해야할까요? 일부 CMS들은 그것을 무시합니다. 그것이 워싱턴 포스트의 접근법입니다.

또 다른 해결책은 다음과 같습니다. 데이터베이스에서 이야기를 찾으면 URL 슬러그가 해당 이야기의 현재 슬러그와 일치하는지 확인하십시오 (현재 헤드 라인 기준). 그렇지 않으면 사용자를 올바른 URL로 리디렉션하십시오. 최종 사용자의 관점에서 볼 때 http://www.washingtonpost.com/hey-this-url-doesn't-mean-a-damn-thing/gIQAocHrpJ_story.html을 입력하고 페이지로드가 완료되면 http://www.washingtonpost.com/politics/mitt-romney-debates-us-economy/gIQAocHrpJ_story.html

왜 워싱턴 포스트가 그렇게하지 않는지 확실하지 않습니다. 그들에게는 똑똑한 사람들이 많이 있기 때문에 특정 CMS에 연결된 기술적 인 이유가 있습니다 (벤더에서 구입 한 제품을 기반으로합니다). 다른 시스템에서는 필자가 설명한 솔루션을 매우 쉽게 수행 할 수 있습니다 (장고에서는 3 줄로 작성했습니다).