서비스에 따라 메일 수신에 대한 제한이 다릅니다.
메일 서비스 업체에 공문 보내고 등록하고 등등의 작업을 하죠.
쥐메일은 한번 스팸통에서 걸러내 주면 이후 잘 도착하고, 나머지들은 쥐쥐치고 메일 주소를 바꾸는 편이;;
도메인의 MX 레코드를 제대로 셋팅하면 좀 확률이 올라가긴 합니다만.
아직 로그인하지 않았습니다. 로그인 또는 회원 등록을 해 주시기 바랍니다.
TNF : Tatter Network Foundation forum » gendoh가 작성한 글
서비스에 따라 메일 수신에 대한 제한이 다릅니다.
메일 서비스 업체에 공문 보내고 등록하고 등등의 작업을 하죠.
쥐메일은 한번 스팸통에서 걸러내 주면 이후 잘 도착하고, 나머지들은 쥐쥐치고 메일 주소를 바꾸는 편이;;
도메인의 MX 레코드를 제대로 셋팅하면 좀 확률이 올라가긴 합니다만.
eolin@eolin.com으로 메일을 보내보시기 바랍니다.
기본적으로 hostname 기반입니다.
그리고 하나의 hostname을 지원합니다.
두개의 ip 즉 두개의 hostname을 쓰는 경우, 시스템에서 출력하는 것은 때에 따라선 두개중 하나를 써야 하는데(가령 글의 퍼머링크등) 이때 클라이언트에서 접속을 못할 가능성이 있기 때문에 일부 기능이 정상적으로 동작하지 못할 것입니다. 가령 공인IP를 기본값으로 출력한다면 사설IP로 접근하는 클라이언트들이 접근하지 못하게 됩니다.
공인 IP라면 보통 사설에서도 접근이 되니 공인 IP를 이용하여 블로그를 개설하면 서빙되는 서버가 사설에도 물려 있다 하더라고 공인쪽으로도 통신이 가능할테니 되지 않을까요? (이제부턴 방하벽이나 라우터 문제로;;;)
보안 옵션을 건드리는 것은 좋지 않습니다.
frame을 이용한 도메인 포워딩 서비스는 추천하지 않습니다. (몇가지 기능이 오동작 할 수 있습니다.)
두개이상의 2차 도메인을 쓰는 기능이라.. 일단 코드 수정으로 쉽게 해결은 됩니다만;;; 복잡하군요.
괄호가 빠진듯?
디텍션 시스템에서 중요한 것은 미탐도 있지만 오탐도 중요하다는 것입니다.
전에 어떤 블로그에서 sex란 단어를 금칙어로 써라라고 글을 쓰셨는데 제가 가서 sexy란 단어가 포함된 도메인을 쓰는 사람이 많다고 지적한 적이 있습니다. 스팸보다도 일반인의 댓글이 더 스팸처럼 보이는 경우가 많습니다. (뭐 실제로 까페나 홈피 방문해 주세요라고 실컷 스팸 날리고는 스팸 날린적도 없는데 왠 차단이냐고 항의하시는 분들도 꽤 되시지만.)
저도 몇가지 준비하는 것도 있습니다만 이 분야로 챌린징 하고 있는 전문가 분들도 몇 계시고... 아무튼 많은 아이디어와 실험 결과들은 계속 보고 있고 바라고 있습니다.
다만 여러 알고리즘을 직렬로 연결하는 것은 큰 문제가 있습니다. 최대한 간단해야 합니다. 그래서 더 어렵더군요.
에러 표시 끄고 설치하심이.
PHP 5에서 다음 버전을 기약하며 언어가 좀 변경되었습니다. 그에 대한 워닝들입니다.
API용 비밀번호는 랜덤 생성된 후 프로그램이나 다른 서비스에 입력하게 하려는 의도로 보입니다만.
관리자 패스워드로 리셋이 가능하므로 이런 식의 접근도 나쁘지 않죠.
포워딩의 경우 세부 주소의 지원이 안될 수 있습니다. 가령 RSS같은 주소를 구입한 도메인에서 지원하기 어렵습니다.
gendoh.abc를 포워딩 받는다면 gendoh.abc/rss 라는 주소를 피드로 사용하기 어려울 것입니다. 더불어 퍼머링크(글 주소)도 gendoh.abc로 사용하기 힘들죠.
기존 독립도메인을 지원하지 않는 서비스에서는 어쩔 수 없었습니다만 티스토리처럼 도메인을 지원한다면 구지 어려운 서비스를 받을 필요는 없습니다.
name으로 접속시 redirect가 아니라 frame으로 보여주는군요.
전체 페이지의 케릭터 셋이 euc-kr이라던가 정확한 head 영역 정보가 없어 문제가 있을 수 있습니다.
포워딩 방식을 변경하심이.
모든 스트링 출력할때 htmlspecialchars를 까먹지는 말아야 합니다.
이번 문제도 비슷한 이유때문입니다.
위의 플러그인도 보안적 문제가 있군요.
뭐 쿠키로 해결?
아니면 리퍼러로 도메인 변경 여부를 확인하는 코드를 넣는 것도 방법일 것 같습니다.
텍큐 코어에서 지원은 하지 않습니다.
에러가 나면 HTML로 에러 페이지를 출력하는군요 쿨럭.
AJAX Call일때는 XML Response를 하도록 대대적인 수정이 필요. reponde:ResultPage로 다 바꿔야 하는데...
다른 곳도 많아서 메이저 버전업때 손대야 할 것 같군요. 받는 쪽 처리도 필요하고.
http://neoillus.ivyro.net/tc/login 로는 되는데 뒤에 인자가 있으면 안되는 것으로 봐서 .htaccess의 문제로 보입니다.
우선 데이터 백업을 받으시고 (위 링크로 관리자 접근이 될 것 같긴 합니다.)
새로 설치를 하실때 기존 디비를 사용한다로 설치해 보시기 바랍니다. 운이 좋다면 성공할 것입니다.
서로 다른 게스트가 비밀글로 묶일때는 어떻게 되나요?
비밀글 A
주인장 댓글
비밀글 B
주인장 댓글
인증체계 없이 같은 사람이 비밀글로 연속해서 글을 썼는지 다른 사람인지 구분하는 방법이... (그렇다고 암호가 같은가 비교할 수도 없구요)
2번 케이스에서도 방명록에서 비밀 댓글을 쓰는 사람이 블로그 주인인 확률이 99% 인긴 한데 100%는 아닌듯.
이런 문제들은 케이스별 룰 정의로 푸는게 편할겁니다.
오래된 문제중 하나니 좋은 아이디어 있으시면 계속 발전해 주시면 감사하겠습니다.
else window.onload=functionName;
...
else window.onunload=functionName;
다른 플러그인이랑 충돌할지도?
EAF.js에서 저런 부분들을 크로스 브라우징해서 동일 인터페이스로 노출해 줍니다.
로딩 타이밍 문제인듯 합니다.
댓글 달리는 데요... --? (맥 파폭2)
더불어
http://asdasd --> 당연히 안됩니다. -ㅅ- EAS님이 보고계셔.
EAS를 꺼보거나(스팸기록을 보면 후덜덜) 정상적인 URL을 입력해 보세요.
Textcube는 세션 유지 시간을 늘렸다고는 하나, IP 변동등의 이슈에는 역시 취약.
1.
자동 저장에 실패하거자 저장버튼에서 실패하는 경우, Offline 모드라고 표시해 준다.
2.
Offline 모드에서는 로그인 버튼이 생겨 팝업으로 로그인을 할 수 있게 해준다.
3.
같은 브라우저에서 로그인이 되면 서버 장애가 아닌 이상 현재 작성중인 글을 저장할 수 있게 된다.
오늘 글 날려먹고 떠오른 생각입니다. -ㅅ-
Mailplane이란 프로그램에서 아이디어 채용.
어떤가요?
ㅡㅡ;; 하나 해결하니 하나가 등장이군요.
원래 바퀴벌레는 그런 종족입니다. 한마리를 보셨나요? 그럼 어딘가에 엄청난 양의;;;;
여기랑 EAS로 걸리는 스팸만 모아놓으면 쌀만 있으면 생계가 해결될 지경이라니깐요 ;;; orz
과체중 우려가 있습니다.
graphittie 작성:lunamoth 작성:블로그주소/rss 의 generator 를 보거나, 소스보기 하셔서 주석문을 보시면 됩니다^^;
그냥 로그인 해서 맨 밑에 보면 안 되나요;
방문자가 알아내는 방법일겁니다~
제가 뚫어버리기엔 법적 문제가 있지요. -ㅅ-
1.6부터는 meta 지원됩니다.
http://www.sixapart.com/developers/xmlr … bject.html
왜이렇게 멍청한 짓을 하였는지 모르겠습니다만 base64 encoding을 xml rpc 레이어가 아닌 어플레이케이션 레이어에서 한 후 스트링으로 보내는 만행이 표준이군요. 허나 지금까지 프로그램들이 잘 동작해 온것을 보면 당연히 바이너리 파일은 base64 타입으로 자동적으로 보내져 온것으로 보이고;;; (아무튼 이동네 api들은 좀 웃기는)
아무튼 표준적으로는 string으로 올때 이것을 base64_decode 하는 것이 정상일것 같습니다만, base64로 인코딩 되어 온것을 지원 안할수도 없고. 문제는 xml-rpc 레이어에서 자동으로 처리되는지라 api 처리 루틴에서 이게 string으로 왔는지 base64로 왔는지 알 방법이 없다는 것.
textcube 전 버전과 tistory가 이 버그를 가지고 있군요.
아이디어 생각나시는분?
http://www.tistory.com/forum/viewtopic.php?id=1129
http://www.cybervill.net/entry/루비에서-티스토리로의-글-포스팅
참고로 Bloger, metaWeblog, mt API 모두 파일 삭제에 관한 함수는 없습니다.
구현에 대한 기억으론 파일이 사용되지 않으면(그래서 resource URL이 좀 엽기적입니다.) 내부적으론 링크를 끊습니다만, File Server에서 지워지지는 않죠. FS상의 구현 문제로 알고 있습니다.
Client 를 작성중이시라면 참고하시기 바랍니다. 한번 올라가면 끝입니다. API 자체가 그런 스펙이 없습니다. 다시 저장할때 첨부파일들을 어떻게 해야 하는가에 대해 아마 이런 점들을 고려하셔야 할것입니다.
TNF : Tatter Network Foundation forum » gendoh가 작성한 글