slacker 기반 slackbot 만들기

재밌어보이길래 python으로 간단한 슬랙봇을 만들어볼까 하고 알아봤더니 slackbot이란 모듈을 사용하면 슬랙봇을 쉽게 만들 수 있을것 같아서 슬랙봇을 만들어봤다.

그런데 파이썬 프로세스는 멀쩡하게 살아있지만 하루 정도가 지나면 봇이 disconnected 상태로 바뀌는 문제가 지속적으로 발생하는 문제가 있었다. 관련해서 예제 코드들을 찾아봐도 별다른 부분이 없길래 며칠 동안 디버깅을 하면서 문제를 해결해봤다.

우선 인터넷에 떠도는 slacker 기반 echo 봇의 기본 골격은 아래와 같았는데…
Continue reading slacker 기반 slackbot 만들기

해킹이 의심되는 파일들 발견…

흠 그동안 관리를 잘 안했더니, 확실히 여러가지 문제들이 생긴 것 같다. 서버 이전 전에 왠만한 문제들은 해결하고 가는게 좋을 것 같아서 파일들을 좀 살펴봤는데, 변조된 파일로 보이는 파일들이 많이 보인다. 대강 아래와 같은 식의 요상한 데이터가 덮어씌워져 있는데…

문자열을 \\xHEX 형식으로 치환해놔서 그냥 보기에는 어떤 내용인지를 쉽게 알아볼 수가 없고, pattern matching 해서 찾아내기에도 드럽게 해놨다. -_- 나뿐 놈들…
도대체 어떤 코드를 넣어놨나 궁금해서 아래 코드를 이용해서 눈으로 볼 수 있는 형태로 치환해봤는데…
Continue reading 해킹이 의심되는 파일들 발견…

HTML5 웹을 넘어 플랫폼으로…

webdevmobile에서 3회(1, 2, 3)에 걸쳐 개최한 열린 세미나가 성공적으로 끝이 났습니다. 웹은 예전부터 관심을 가지고 지켜보고 있었지만 최근 HTML5 등의 이슈에 대해서는 제대로 follow up 하지 못하고 있어서 약간의 죄책감을 가지고 있었는데, 덕분에 HTML5에서 지향하는게 무엇인지에 대해 약간이나마 알 수 있어 재밌었습니다. 🙂

아무래도 HTML이란 이름 때문에 웹퍼블리셔 분들이 많이 참석하셨던데 (특히) 3회째 세미나는 웹퍼블리셔 분들보다 앱 개발자 분들이 좋아하셨을 것 같네요.

Continue reading HTML5 웹을 넘어 플랫폼으로…

마우스 드래그, 마우스 오른쪽 버튼을 막아둔 것 풀어버리기

네이버 웹툰에 있는 만화에 링크를 걸려다 마우스 우클릭이 동작을 안하길래, 구글링을 했는데 거기서 나온 스크립트도 네이버 웹툰에서는 제대로 동작을 안했다.

조금 살펴보니 개선할 여지가 있길래 약간의 코드를 더해봤다. 절대 네이버 웹툰에 있는 이미지를 링크하기 위한 목적이었던 건 아니다.

Continue reading 마우스 드래그, 마우스 오른쪽 버튼을 막아둔 것 풀어버리기

CSS로 탭 내비게이션 구현하기…

오랫만에 웹페이지 코딩을 할 일이 있었는데, 탭 내비게이션이 필요한 상황이라 html + css로 탭 내비게이션을 구현해보았습니다.
block 레벨 엘리먼트에 position 속성을 주게 될 경우 새로운 context가 시작되게 되므로 그 하위 엘리먼트에서 position: absolute를 사용할 경우 position을 속성을 지정해둔 상위 엘리먼트의 위치 기준으로 위치가 지정된다는 사실을 이용하는 방법입니다.
border만을 활용하다 보니 디자인 상으로 사소한 문제가 있지만 span 등을 활용할 경우 충분히 이쁘게 만들 수도 있을거라 생각합니다.
Continue reading CSS로 탭 내비게이션 구현하기…

ErrorDocument 수정

403 Forbidden, 404 Page Not Found, 500 Internal Server Error 같이 자주 접해볼 수 있는 (?) 에러 페이지들은 기본 에러페이지를 사용하지 않고 나름 이쁜 페이지를 만들어 사용하고 있었습니다.
다만 예전 개념 없던 시절에 작업해놨던 페이지이기 때문에 지저분한 html, 의미 없는 markup 이 여기저기서 보이더군요. 그래서 잠깐 짬을 내어 좀 더 web standard 에 맞도록 수정을 해 보았습니다.
실력이 일천하여 예전 페이지 모양을 그대로 살리지는 못해서 살짝 아쉽네요.
예전 에러 페이지:
http://unfix.net/resources/err_page/old/
새 에러 페이지:
http://unfix.net/resources/err_page/

웹서비스와 utf-8

한국의 웹사이트들을 돌아다니다 보면 “파일이 보이지 않는 경우 ‘URL 을 항상 UTF-8 로 보냄’ 옵션을 꺼주시기 바랍니다.” 라는 메시지를 쉽게 볼 수 있다. 하지만 소위 웹프로그래머라는 사람들 중 저런 문제가 생기는 이유에 대해 관심 있는 사람들은 별로 없는 듯 싶다.

URIs
Internationalization of URIs is important because URIs may contain all kinds of information from all kinds of protocols or formats that use characters beyond ASCII. The URI syntax defined in RFC 2396 currently only allows as subset of ASCII, about 60 characters. It also defines a way to encode arbitrary bytes into URI characters: a % followed by two hexadecimal digits (%HH-escaping). However, for historical reasons, it does not define how arbitrary characters are encoded into bytes before using %HH-escaping.
Among various solutions discussed a few years ago, the use of UTF-8 as the preferred character encoding for URIs was judged best. This is in line with the IRI-to-URI conversion, which uses encoding as UTF-8 and then escaping with %hh:
Guidelines for new URL Schemes, RFC 2718, proposes to base URIs on UTF-8 unless there is some compelling reason for a particular scheme to do otherwise.
URI schemes or components already based on UTF-8:
URN syntax : RFC 2141 (syntactically, URNs look like a URI scheme, but semantically, they are not)
IMAP: RFC 2192 (the IMAP protocol uses a modified version of UTF-7, but its URIs use UTF-8)
FTP ( RFC 2640 uses UTF-8, but tolerates legacy encodings)
XPointer (W3C Working Draft)
From: http://www.w3.org/International/O-URL-and-ident

위에서 보다시피 RFC2718 에서는 URL 을 UTF-8 로 보내라고 제안하고 있으며, FTP 관련해서는 RFC2640 에서 path name 을 UTF-8 로 넘겨주라고 되어 있다. 그러므로 Internet Explore 에서 ‘URL 을 항상 UTF-8 로 보냄’ 을 해제시키는 것은 올바른 해결법이 아니라고 생각된다.
현재 까지의 대부분의 ftp client 에서 i18n 관련해서 별다른 고려를 하지 않고 있었기 때문에 path name 을 client 의 legacy charset 을 이용해서 넘겨주도록 구현되어 있다. 그렇기 때문에 (한글 기준으로) euc-kr 로 된 path name 이 사용되어 왔고 결국 server 측에도 euc-kr 로 저장되고 있는 실정이다.
그런 상황이다 보니 위의 권고안 대로 URL 을 UTF-8 로 넘겨주는 경우 실제 파일을 찾지 못하고 ‘404 Page Not Found’ 를 만나게 될 수 밖에 없는 것이다.
해결책은 간단하다고 생각한다. RFC2640 이 구현된 FTP server/client 를 사용하게 될 경우 자동으로 path name 에 UTF-8 을 사용하게 되므로 server 측에서 path name 에 별다른 조작을 가하지 않는 이상 filename 에 UTF-8 로 사용하게 될테고… 결국 UTF-8 로 된 URL 을 아무 문제없이 파일을 처리할 수 있게 된다.
얼른 이런 것들이 흥보가 되고 널리 쓰이게 되서 ‘URL 을 항상 UTF-8 로 보냄’ 을 체크해제 하라는 말을 안볼 수 있는 세상이 왔음 좋겠다 -_-;;
p.s) 현재 RFC2640 이 구현되어 있는 건 filezilla 밖에 모르겠네요. proftpd 의 경우 1.3.1rc 버젼부터 rfc2640 을 지원합니다.