우선 스킨 레벨.
어차피 주소 찾는 프로그램이 php 레벨도 아니고 html레벨에서 읽어오니 생각보다 간단하게 해결할 수 있을듯 하다.
예를 들어, skin.html의 소스 부분에서
이 글의 트랙백 주소 : [ ##_tb_address_##]
이 부분을
이 글의 트랙백 주소 : [ ##_tb_address_##](nospam)
으로 고쳐준다거나
이 글의 트랙백 주소 : [ ##_tb_address_##](clear)
이런식으로 고쳐주면 웹페이지 소스에는http://inureyes.bluemime.com/forest/rserver.php?mode=tb&sl=###(nospam)
으로 뜰테니, 수집 프로그램에 걸리지 않을 수 있겠다.
만일 수집 프로그램이 '너의 방어 패턴을 알아냈다!' 고 나왔을 경우에는 어떻게 하느냐? (예를 들어 위의 경우에서 원하는 부분만을 잘라서 알아내는 경우.)
그러면 스킨레벨 이상이 필요하겠지.
예를 들어, skin.html의 소스 부분에서
이 글의 트랙백 주소 : [ ##_tb_address_##]
이 부분을
이 글의 트랙백 주소 : [ ##_tb_address_##](nospam)
으로 고쳐준다거나
이 글의 트랙백 주소 : [ ##_tb_address_##](clear)
이런식으로 고쳐주면 웹페이지 소스에는http://inureyes.bluemime.com/forest/rserver.php?mode=tb&sl=###(nospam)
으로 뜰테니, 수집 프로그램에 걸리지 않을 수 있겠다.
만일 수집 프로그램이 '너의 방어 패턴을 알아냈다!' 고 나왔을 경우에는 어떻게 하느냐? (예를 들어 위의 경우에서 원하는 부분만을 잘라서 알아내는 경우.)
그러면 스킨레벨 이상이 필요하겠지.
이젠 태터 소스 레벨이다.
[ ##_tb_address_##] 에서 치환해주는 경로를 풀 어드레스가 아니라 서버의 경로만을 보내주도록 하면 확실한 방지가 된다. 그리고 스킨에서 나머지 부분을 처리하도록 하는 것이다.
[ ##_tb_address_##]가 /forest/rserver.php?mode=tb&sl=### 만 돌려주도록 하고,
스킨 소스에는
이 글의 트랙백 주소 : [CODE]http://inureyes.bluemime.com/[ ##_tb_address_##] [/CODE]
로 하면 못긁어갈테다.
만일 주소만으로 rserver.php의 패턴을 알아내는 기술이 나온다면? 그 앞의 패턴을 안다면 반대로 rserver.php에서 주소 뒤에"&stat=clean" 이 붙은 트랙백만을 받게도 만들수 있을 것이다. 이경우엔 rserver.php에서 환경변수를 인식하는 부분을 추가하고, 스킨에는 "뒤에 &stat=clean을 붙여주세요" 라는 설명을 쓸 수 있겠다.
random generator를 달아주는 방법도 있다. 그날그날의 random 숫자를 생성해서 웹 상단에 표시되게 하고, 그날의 허용 번호를 random으로 생성해서 보여주고 트랙백을 보낼 때는 뒤에 "&stat=########"을 붙이도록 유도하는 방법도 괜찮을 것이다.
[ ##_tb_address_##]가 /forest/rserver.php?mode=tb&sl=### 만 돌려주도록 하고,
스킨 소스에는
이 글의 트랙백 주소 : [CODE]http://inureyes.bluemime.com/[ ##_tb_address_##] [/CODE]
로 하면 못긁어갈테다.
만일 주소만으로 rserver.php의 패턴을 알아내는 기술이 나온다면? 그 앞의 패턴을 안다면 반대로 rserver.php에서 주소 뒤에"&stat=clean" 이 붙은 트랙백만을 받게도 만들수 있을 것이다. 이경우엔 rserver.php에서 환경변수를 인식하는 부분을 추가하고, 스킨에는 "뒤에 &stat=clean을 붙여주세요" 라는 설명을 쓸 수 있겠다.
random generator를 달아주는 방법도 있다. 그날그날의 random 숫자를 생성해서 웹 상단에 표시되게 하고, 그날의 허용 번호를 random으로 생성해서 보여주고 트랙백을 보낼 때는 뒤에 "&stat=########"을 붙이도록 유도하는 방법도 괜찮을 것이다.
어느쪽이든, 설치형인 태터툴즈를 위한 방어책은 만들기가 비교적 용이하다. 서비스형의 경우에는? 모르겠다. 포기. 업체들이 알아서 하겠지. (업체측에선 제일 마지막의 random number 생성이 가장 좋을듯 하다. 다른 방법은 일괄적용되면 또 뚫리니까. 물론, 자릿수는 많아야한다. 안그러면 번호대로 다 보내는 사람도 나올걸?)
이상. 결자해지였음.
