우분투 pam_abl 사용

ssh 브루트 포스 공격을 방어하는 방법에는 여러가지가 있지만 간단한 방법중에는 pam_abl을 사용하는 방법이 있습니다. pam 모듈이며 따라서 설치 후에 sshd_config에 해당 모듈에 대한 내용을 추가하면 됩니다. 해당 설명은 우분투 12.04를 기준으로 설명하고 있으므로 설치 과정이나 환경 설정에 대한 부분은 대단히 생략되어 있는 곳이 많습니다.


설치
우분투 패키지 관리자로 pam_abl 설치
(libpam_abl이며 예전 우분투 버전이면 안 나올 가능성이 있음)

터미널에서
sudo apt-cache search libpam-abl
입력 후 해당 패키지가 있는지 확인, 없으면 sourceforge 여기서 소스를 받아 컴파일 설치
있으면
sudo apt-get install libpam-abl
입력하여 해당 패키지 설치


환경 설정

/etc/ssh/sshd_config 파일
/etc/ssh/sshd_config를 열어 UsePAM 항목이 yes로 되어 있는지 확인
/etc/pam.d/sshd 셋팅
/etc/pam.d/sshd에 해당 라인 추가

기본 셋팅은 끝났습니다. 이제는 pam_abl.conf에 대한 셋팅을 처리하면 되겠네요.


pam_abl.conf 설정

/etc/security/pam_abl.conf
/etc/security/pam_abl.conf 편집

기본적으로 다른 부분은 (굳이)신경 쓸 필요가 없으며 host_rule, user_rule만 신경쓰면 됩니다.

 

host_rule=*:3/1h,30/1d
모든 호스트를 대상으로(*) 한 시간에 3번(3/1h), 하루에 30번(30/1d)에 해당되는 사용자를 차단하겠다는 뜻입니다. 여기 호스트 룰에 걸려서 차단되면 상대방은 로그인을 계속 시도해도 로그인이 되지 않습니다. 이때부터는 맞는 패스워드를 입력해도 계속 로그인 실패가 떨어지게 됩니다.
확실한 조건을 만들었다면 하단
#host_blk_cmd=iptables -I INPUT -s %h -j DROP
의 주석 처리된 라인을 활성화 시켜보세요. iptables로 해당 아이피를 차단시켜 버리는 명령어도 같이 실행되도록 처리하는 라인입니다.

user_rule=!root:3/1h,30/1d
루트를 제외한 모든 유저를 대상으로(!root) 한 시간에 3번(3/1h), 하루에 30번(30/1d)에 해당되는 사용자를 차단하겠다는 뜻입니다. !root를 하지 않는다면 root로 접근하는 무작위 공격에 root계정이 차단되는 불상사가 일어나겠죠.
이렇게만 알아두시면 무작위 공격에서는 어느 정도 방어할 시스템을 구축했다 할 수 있겠습니다.


환경 설정 – 간단한 응용

본격적인 룰 적용
본격적인 룰 적용

host_rule
111.111.111.111, 192.168.0대역, localhost, 222.222.222.222, 1.2.3.4 호스트를 제외한 나머지 호스트들에게 시간당 4번, 하루에 10번 로그인 실패하는 조건으로 차단 정책 설정함.

user_rule
simpleuser, harduser를 제외한 모든 유저를 대상으로 한 시간에 5번, 하루에 10번 실패할 경우 해당 계정으로의 로그인 시도를 차단함(어차피 호스트에서 먼저 걸리겠네요!!)


커맨드 라인 명령어

대략 이정도만 사용하므로 몇 가지만 작성해 봅니다.
우분투의 경우 항상 루트 권한으로 명령어를 입력하셔야 합니다. 항상 sudo 를 붙여서 명령어를 입력하세요.

  • pam_abl
    로그인 시도에 실패한 유저와 호스트 출력
  • pam_abl -v
    실패한 시도들을 시간기록으로 보여줌
  • pam_abl -rv
    실패한 시도들을 절대 시간으로 나열(몇 분 간격으로 로그인 시도에 실패하고 있는지 확인할 때 유용함)
  • pam_abl -f -U simpleuser
    simpleuser 계정 실패 기록 생성(단순 기록 생성이므로 차단을 위해서는 룰에 맞춰서 기록을 생성하세요. 시간당 3번이 블럭 조건이라면 명령어를 3번 치시던지…)
    -U 는 user란 의미이며, 특정 호스트에 대한 실패 기록은 -H 를 사용하시면 됩니다. 예를 들자면 pam_abl -f -H 192.168.0.254라면 254번 호스트의 실패 기록을 추가하겠죠?
  • pam_abl -w -U simpleuser
    simpleuser 계정의 차단을 해제합니다. -w는 화이트리스트입니다. -w 명령어는 차단을 해제할 뿐이며, 다시는 차단이 되지 않는다거나 하는 의미는 아닙니다. 다시 차단될 수 있으며 그럴때는 다시 명령어를 입력하세요. 아니면 저 위의 환경   설정에서 조건을 제외시키거나 하는 방법으로 사용하시면 됩니다. 물론 U 대신 H를 사용하여 호스트에도 적용 가능합니다.
  • pam_abl -p
    로그인 시도 실패 기록들 중 오래된 기록들은 삭제합니다.(환경설정에 보면 old_data는 2일로 정의되어 있습니다.2d ) 기록만 삭제할 뿐이지 차단된 사용자들이 갑자기 풀려나서 날뛰는 일은 없으니 안심하세요!!
  • pam_abl -h
    명령어의 도움말을 출력합니다.

결론
간단하게 셋팅할 수 있으며 사용하기 편리합니다.

iptables에 걸린 호스트
iptables를 사용했을 때 연동되어 차단되는 모습입니다… 아이피 공개해도 상관없겠죠?

참고
http://hexten.net/assets/pam_abl_doc/index.html
http://pam-abl.sourceforge.net/docs/pam_abl.1.html

str_replace의 성능 비교

개요

얼마전에 php str_replace 사용법에 관한 글을 작성한 적이 있었는데 작성하고 보니 궁금해졌다.
여러가지 방식을 활용할 수 있는만큼 성능에 대한 차이는 분명히 있을지언데, 어떤 방식이 효율이 가장 좋을까?

잘은 모르겠지만 한번 비교해 보는것도 나쁘지 않을 것 같다.


셋팅

str_replace를 사용하는데 여러가지 방식이 있으니 그 방식들을 전부 사용해보고 연산에 소요된 microtime을 구하여 비교한다면 간단하게 성능에 대한 결과가 나올 것이다.
성능을 측정하는데 사용하는 str_replace 사용 방식은 총 4개.

  1. 문자열 자체를 직접 파라메터에다 입력하여 사용
  2. 문자열을 변수에 대입 후 파라메터에 변수 넘겨 사용
  3. str_replace를 여러 번 사용할 때
  4. str_replace를 여러 번 사용해야할 때 대신 배열을 사용하기

사실 1,2 번과 3,4번은 딱히 상관없지만 그래도 같이 실험해 보기로…

 

 


추측

1,2번 비교에선 당연히 변수 선언하는 과정에 소비되는 비용이 있을테니 속도는 1번이 2번보다 더 빠를것이다.
3,4번 비교는 아무래도 str_replace를 여러번 사용하는거 보다는 배열 하나로 처리하는것이 조금 더 효율적이지 않을까


실험 결과

실험내용 시간
1. 변수 지정 없이 직접 입력 0.24004793167114
2. 변수 계속 선언하면서 0.29302096366882
3. 여러번 replace 0.77365112304688
4. 여러번 replace 배열 사용 0.98972487449646

음.. 1,2번의 경우 예상한 결과였다.
하지만 3번과 4번을 비교할 때 오히려 배열을 사용하는 4번이 조금 더 많은 시간을 소비하는것으로 측정이 되었다.
간단하게 생각해서는 함수를 여러번 콜하는것이 더 많은 자원을 소비할 것으로 생각했는데, 내부적으로는 어떤 방식으로 처리를 하는것인지….
해서 시간상으로의 결론은 그냥 str_replace를 여러번 사용하는 것이 조금 더 빠르다는 것.

php str_replace의 사용법

php를 사용하여 작업을 하게 되면 굉장히 자주 사용하는 함수로 str_replace라는 함수가 있습니다.
함수의 기능은 이거 검색하고 온 사람들은 다 아시겠지만 문자열에 특정 단어가 포함되어 있는 부분을 원하는 값으로 치환해주는 기능인데요,

단순한 함수이지만 의외로 인수에 배열을 넣을수도 있다는 점을 모르는 사람이 의외로 있어서 간단히 포스팅 해 봅니다.

 

 

 

참고 :

http://fi1.php.net/manual/kr/function.str-replace.php

XSS, 세션 하이재킹

개요

크로스 사이트 스크립팅(Cross Site Scripting, XSS)이라는 해킹 기술이 있다. 지금은 워낙 유명하니 인터넷만 검색해도 쏟아져 나오지만 그래도 다시 한번 보자는 차원에서 작성해보도록 한다.

대략적인 의미는 스크립트를 통해 다른 사이트로 데이터를 넘겨버린다는 뜻..

기본적으로 인터넷을 이용할 때는 이런저런 글들을 읽기도 하고 글을 작성하며 의견을 교환하기도 하는데, 웹 프로그래머의 관점에서 볼 때는 사용자의 입력을 허용한다는 것은 항상 XSS 공격의 위험성을 내포하고 있다고 해도 과언이 아니다.  무엇을 입력할 지 모르기 때문인데, 그러한 이유로 XSS가 가능하지 않도록 막는 처리는 어느 상황에서든 항상 신경써야 하는 부분이다. 하지만 모든 개발자가 그렇게 다 신경쓸 수는 없는 노릇인데…

 

이런 식. 일반 개발자들은 신경 안 쓰고 넘어가는 경우가 많다.  특히 공개되어 있는 완성도 높은 그런 프로그램들이 아닌 일반 영세한 회사나 다른 개인 개발자들이 만든 프로그램에서는 이러한 부분들이 드러나게 되는데..  얼마전 모 커뮤니티에서 다른 커뮤니티를 공격했을 때 썼던 방법도 이 방식을 응용한 것으로 알고 있다.  잘 막는 것 같으면서도 잘 막히지 않는 그런 공격 방식.

사실 개발자의 역량이 중요하다고 할 수 있겠지만 xss 공격은 정말 흔한 만큼 감탄할정도로 신기한 방식들이 많이 있다.
결국 아는 만큼 대비할 수 있다는 얘기.

 


셋팅

위에 스샷이 찍힌 게시판에서 우리는 스크립트가 동작한다는 사실을 알았다. 게시물 내용에 스크립트를 넣어도 동작하고 스샷에서는 나오지 않았지만 코맨트 부분에서도 마찬가지로 스크립트가 동작한다는 사실을 알아낼 수 있었다. 일반적인 세션 방식이라면 결국 쿠키를 키 값으로 삼아 동작하는 방식이니 우리는 쿠키값을 얻는다면 세션을 탈취할 수 있다.

방식은 여러가지가 있지만 위키피디아 XSS 설명 내용으로 시도를 해 보겠다.(위키)

img 태그에는 onerror 라는 이벤트를 부여할 수 있다. 이 이벤트는 태그 내의 src 로 이미지를 로드할 수 없을 때 동작하며 일반적으로 이미지가 없거나 할 때를 대비해서 사용하는 이벤트이다. 따라서 지금 태그에서는 src에서 이미지를 불러들일 수 없으며 onerror가 동작하겠…지?

아무튼 img 태그가 뿌려지면서 http://test.simpleuser.net/xss_test/view.php 에 접속이 되고, 해당 url의 getcookie파라메터를 통해 대상자의 쿠키도 같이 전달이 될 것이다.
결론적으로 해당 url의 view 파일 내용은 $_GET['cookie']로 들어오는 내용을 DB나 다른 곳에 저장하기만 하면 된다.

이제 누가 저거 들어와서 읽을때까지 대기하고 있으면 된다.


동작 확인


누가 들어옴;;;;

이제 쿠키를 내 브라우저에 그대로 심으면 된다.

쿠키를 편집할 수 있는 프로그램도 많고 브라우저 개발자 콘솔상에서도 직접 입력하여 제어 가능하다.

 


결과

로그인 성공!

 


결론

XSS 공격의 방식은 이런 식 이외에 다른 방법도 많은데 <script> 태그를 활용해 url 부분을 다른 식으로 치환해 버리는 방법도 있으며 일반적으로는 location.href 를 통해 해당 url로 보내버리는 방법도 있다.

해당 공격을 막을 수 있는 방법중 가장 널리 알려진 방법중의 하나는 script 기능을 활용할 수 없도록 태그를 막는 것이다.  일반적으로는 php의 htmlentities() 나 htmlspecialchars(), strip_tags() 함수를 활용한다. 해당 함수들는 모든 특수문자를 html 엔티티로 변환하거나 삭제하며, 브라우저에서 읽히더라도 태그로 인식하지 않는다. 그리고 위의 공격 방식으로도 보았듯이 태그 내의 on으로 시작하는 이벤트 어트리뷰트도 왠만하면 막도록 하자. 공격은 다 이런 부분에서부터 시작한다.  인터넷에 돌아다니는 xss filter들을 적용시켜 보는것도 매우 좋은 방법이다.

그 외에도 xss 필터를 회피할 수 있는 여러가지 방법들이 많으니 꾸준히 정보를 얻는것이 중요하다 하겠다.

태그 이벤트를 막은 예
태그 이벤트를 막은 예

 

마치며

워낙 단순하고 흔한 공격 방식이고 그만큼 실제로 사례가 많이 나오는 방법이다. 예전에 포탈사이트에서 연예인들도 털리고 했던게 다 이 xss 방식이며, 심지어 구글조차도 xss공격에 취약점이 발견된 적이 있었다.

항상 조심하고 웹으로 출력할때는 언제나 이스케이프 하는 습관을 기르도록 하자.

 


 볼만한 글

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
http://grayhash.com/2012/07/19/22_xss_bugs_on_naver/
http://securecode.tistory.com/6

MySQL 복제(Replication) 1 – 셋팅

개요

MySQL에는 복제(Replication) 이라는 기능이 있다.

이 기능이 무엇인고.. 하면, 마스터 서버에 쓰기 작업을 하면 셋팅해 둔 슬레이브 서버를 찾아 데이터를 계속적으로 퍼나르는 기능이다.
결론적으로는 계속 마스터 서버의 데이터를 따라가게 되고 간단하게 생각하면 동기화, 복제 뭐 이런식으로 생각하시면 된다.

이러한 기능을 사용하는 몇 가지 중요한 이유가 있다.

  • 부하 분산
    select 쿼리는 그 자체적인 작업으로는 장비에 큰 부하를 주지 않는다 생각할 지 모르겠지만, 어떤 상황에서도 그 부하의 양이 적다고 절대 단언할 수 없으며,
    따라서 읽기 작업의 부하를 피하기 위해 복제 기능을 활용하는 경우가 많다1. 마스터에 데이터를 쓰고
    2. 슬레이브로 복사
    3. 쓰는건 마스터에 쓰고, 읽는것은 분산 처리
  • 데이터 분산
    데이터를 분산하여 저장하면, 어떤 점이 우리에게 좋은 것일지는 여기에다 굳이 작성하지 않아도 이 글을 보는 사람은 다 알거라 생각된다.(설마..)
    이렇게 분산해서 저장을 하게 되면 그 자체로도 데이터 백업의 역할이라고 볼 수 있는것이고(그런데, 이 복제 기능을 백업 용도로 쓰면 안된다!)
    어딘가 어떤 서버가 망가지거나 하더라도 복제로 구성된 서버 자체는 원본과 다를것이 없으므로 복구 시간을 많이 줄이는데 도움이 된다.

그냥 생각만 하더라도 쓰기, 읽기를 각각의 서버에 분산시킨다면 서버가 담당하는 일이 줄어드니 성능상으로 큰 이점이 생길거라는 느낌이 확연히 느껴지지 않겠는가?
또 데이터를 복제하며 분산시켜 사본을 만든다면 조금 더 안정감 있게 운영할 수 있지 않을까?
다 이런 이유로 이러한 기능이 있는 것이다.


셋팅

복제를 활용하기 위해서는 몇 가지 셋팅이 선행되어야 하는데, 막강한 기능과는 다르게 셋팅은 그리 복잡하지 않다.

1. 마스터/슬레이브를 각각에 맞게 설정
2. 계정 만들기

큰 틀에서 이런 식으로만 작업을 하면 간단한 복제 환경을 구축할 수 있다.
물론, 더 복잡한 복제 구성을 하고자 한다면 조금 더 복잡해질수는 있겠지만 손만 약간 더 갈뿐 비슷한 수준에서 작업이 이루어진다.

 

  • 사전 준비
    마스터 서버가 한 대, 슬레이브 서버가 두 대이며, 이 서버들은 둘 다 마스터 서버를 바라보고 있다.

     

    이런 식으로 셋팅을 할 것이다.

    환경을 셋팅하기 위해 사용하고 있는 서버는 centos6.4 minimal 과 MariaDB 5.5.34 이다.
    MariaDB는 MySQL과 같은 소스에서 나온 것이라  MySQL과 같다고 보면 된다.

  • 마스터 환경 설정
    mysql 환경파일인 my.cnf를 수정해야 하는데 centos6.4+mariadb 기준으로는 /etc/my.cnf.d/에 cnf파일들이 있다. 

    다른 쪽은 신경 쓸 필요 없이 server쪽 파일만 수정하면 되고, 대부분의 서버라면 저런 식으로 환경파일이 분리되어 있지는 않고 상관 없이 서버 부분만 수정하면 된다.(mysqld)

    server_id = 1000
    log_bin = mysql.bin

    이 두 줄만 작성하시면 된다.

    server_id : 복제를 활용하기 위해서는 각 MySQL 마다 고유의 아이디를 하나씩 가지고 있어야 하는데, 그 값을 지정해 준거라 생각하시면 된다.
    DB에 PK 같은 느낌이라고 생각하면 되며 이 값은 마스터든 슬레이브 여러개든간에 항상 중복된 값이 없이 달라야 한다.

    어느 값을 쓰던 상관없지만 슬레이브와는 큰 차이를 두면 중간에 마스터가 환경이 변경되거나 해도 관리 측면에서 유용하다.

    log_bin : 바이너리 로그를 말한다.
    복제의 방식은 마스터에서 로그 바이너리를 작성하고 슬레이브에서 로그 바이너리를 참조해 복제 작업을 진행하게 되는데, 이 바이너리 로그를 활성화 한 것이다!
    바이너리 로그 자체는 장애시 복구를 하기 위해 사용되지만, 복제에서도 사용된다. 따라서 복제를 사용하지 않더라도 바이너리 로그를 활용하는 것은 관리/유지 측면에서 좋을 수 있다.

    그리고 중요한 점으로, log_bin 에 이름을 지정하지 않으면 호스트의 이름을 기준으로 바이너리 로그가 생성이 되는데 호스트 이름이 변경되면 이전까지 쌓아두었던 바이너리 로그가 무용지물이 되어버리는 경우가 생기므로 기본값을 절대 사용하지 말자. 그리고 모든 서버마다 로그 이름은 같은 이름을 사용하는 것이 좋다. 유지보수하는데 이점이 있다.

  • 슬레이브 환경설정
     

    log_bin = mysql-bin
    sever-id = 2
    relay_log =mysql-relay-bin
    log_slave_updates = 1
    read_only = 1

    대략 이런 식으로 작성하면 된다.
    마스터측 환경 설정과 비슷하고 몇가지가 더 추가되어 있다.relay_log :

    복제 시 슬레이브 측에서는 마스터에서 값을 얻어온 후 바로 작업을 하는게 아니라, 릴레이 로그쪽에 쌓아 놓고 작업을 처리하게 되는데 이 로그를 활성화한다.
    슬레이브 측에서는 가장 중요한 로그라고 할 수 있다.(없으면 복제가 안됨)

    read_only : 읽기 전용으로 설정한다.
    슬레이브 측은 읽기 전용으로 설정하는 것이 좋은게, 복제되는 서버에서 데이터를 조작할 수 있으면 데이터를 신용할 수 있을까?

    환경 파일을 변경했다면 각각의 MySQL 들을 재시작  해주자.

 


계정 만들기

  • 마스터 측

    복제에 대한 권한을 가진 계정을 생성한다.
    password 부분에서는 실제 사용할 계정의 패스워드를 입력하면 되며
    복제를 내부 아이피 대역에서 동작하도록 셋팅하고 있기 때문에 호스트는 192.168.0 대역으로 제한한다.
  • 슬레이브 측

    마스터 서버를 지정하는 쿼리인데, 호스트가 명확하므로 아이피를 그대로 써 주면 된다.
    쿼리를 다 적용하였다면, 권한 적용을 위해 MySQL을 재시작해주자(아니면 flush privileges)

체크 과정

  • 마스터 측

    쿼리를 입력하면 서버 상태가 나온다.

    show master status 쿼리 결과

    만약 이런 식으로 나오지 않고 빈 값으로 나온다던가 하면 설정 어딘가에 문제가 있는 것.

  • 슬레이브 측
    우선 슬레이브를 시작시키는 쿼리를 실행해야 한다. 

    만약 오류 메세지가 나온다면 설정 어딘가에 문제가 있는 것. 이후 슬레이브 실행 상태를 점검해 보자.

    쿼리 입력으로 상태를 체크해볼 수 있는데 꽤 많은 항목이 나오는데, 가장 중요한 항목은 Slave_IO_Running Slave_SQL_Running 항목이 yes로 놓여져 있는가를 확인해보면 된다.
    이 항목들이 yes가 아니라면 어딘가 설정에 문제가 있는 것. 그리고 그림에는 없지만 컬럼 중 Master_Server_ID 라는 항목을 한번 살펴 보도록 하자. 이상없이 설정이 되었다면 환경파일에서 설정해 두었던 마스터 서버 아이디가 여기에 보일것이다.

 


동작 확인

  1. 모든 테이블의 데이터는 전부 비워져 있는 상태.
  2. 마스터 서버에 row를 한 줄 insert 해 보자.
  3. 쨘!! 복제 작업이 완료되었다.

 

 

참조

MySQL 성능 최적화

자바스크립트로 단축키 구현

간혹 일을 하다 보면 이상한 요구사항들을 접할때가 많다.
이를테면, 엔터 키 누를때마다 작성한 데이터가 삽입되는 한 줄 게시판을 만들어달라고 해놓고 “사실은.. 줄바꿈도 되었으면 하는데요..” 하는 그런 요구사항 같은거 말이다.

 

“그러면 한 줄 게시판이 의미가 없어지지 않나요?”
되물어보니
“기본으로 한 줄 게시판인데, 시프트와 엔터를 누르면 줄바꿈이 되는 그런걸 추가해 주시면 되는데요~?”

 

간단하게 구현할 수 있다.
다른 응용프로그램 언어처럼 keyup, keydown 등의 이벤트도 그대로 다 있고..

다만 e.Alt e.Control 이런건 없고, && 이런것도 안되니 직접 키코드로 작성해주자.
대략적으로 구현해보면 이런 식이다.

키눌림에 따라 true, false 로 값을 저장 후 둘 다 true 일 경우 펑션을 실행시키면 깔끔하게 단축키 기능을 사용할 수 있다.

 

예제 : http://simpleuser.net/example/shortcut.php

 

트위터 API v1.1 적용하며…

https://dev.twitter.com/blog/api-v1-is-retired

오늘 회사에서 일 하다가 기획자 한 명이 와서 모 사이트의 SNS 데이터 받아오는 기능 하나가 동작하지 않는다고 말해주었다. 확인해 보니 페이스북이나 미투데이 같은 기능은 잘 작동 되는데 트위터가 문제였다.  멀쩡한 데이터를 받아오지 못하는 문제였는데…

확인해보니 트위터의 REST API v1 이 deprecated 되어버려서 생기는 문제였다.  사실 이전부터 트위터에서는 꾸준히 공지를 하고 있었던 부분이라 신경을 진작에 썼어야 하는데… 미처 신경도 못쓰고 있다가 문제가 발생하였다.

이제 모든 API는 v1.1 을 사용해야 작동이 된다. 뭔가 거창하게 썼지만 크게 바뀌는 부분은 없으며 api url을 https://api.twitter.com/1.1/ 로 변경하여 호출하면 해결된다.
가장 많이 쓰는 PHP용 트위터 라이브러리 twitteroauth 에서는 host라는 맴버 변수에 주소만 v1.1로 할당해주면 문제없이 돌아간다. (30분전쯤 1.1로 수정해서 새로 커밋한것으로 보인다.).

문제는 v1 에서 지원하던 기능이 v1.1에서 지원하지 않는 경우인데, 대표적인 것 두가지가 특정 유저의 타임라인을 받아오는 기능과 프로필 이미지를 받아오는 기능이다.
특정 유저의 타임라인을 받아오는 것은 이전처럼 url만 호출해서 편리하게 받아오기는 힘들게 되었지만, 개인 억세스 토큰을 api호출 때 같이 보내면 이전과 같이 편리하게 동작한다. 하지만 프로필 이미지는 이전처럼 편리하게 개인 아이디를 포함한 url 로 불러낼 수 없어서(v1.1 api에는 없음) 편리하게 불러내려면 조금 고민을 해봐야 할 것 같다.

https://dev.twitter.com/docs/api/1.1/overview
https://dev.twitter.com/docs/faq#17750
또 하나의 중요한 점으로는 json포멧으로만 결과값을 돌려준다고 한다.

블로그 시작

이전까지 블로그를 하나 운영할 생각에 코드이그나이터를 활용한 블로그를 하나 작업하고 있었다. 블로그 제작을 대략 3개월 정도 하고 있었는데, 계속 이렇게 제작을 하는것이 사실은 시간 낭비가 아닐까?? 라는 식의 고민을 하다가 결국에서는 역시 워드프레스를 설치해 쓰는게 낫겠다… 라는 결론에 도달하여 그냥 워드프레스를 설치하였다.

블로그 하나를 3개월 걸린것도 참 대단한데… 깃에 올리면서 남긴 로그를 보면 그 동안에 있었던 일들이 떠올려진다. 생업은 해야 하니 일은 나가야 하고 회사는 살인적인 야근 일정에(대략 2~3개월만에 칼퇴근함) , 그나마 시간 남아도. 블로그 하나 만들자고 인생을 포기할 수는 없으니 개인생활도 하고 여친도 좀 챙겨주고….

프로그램 완성이야 중요하지만 이런 블로그 만들자고 많은 시간을 낭비할 수는 없고.. 해서 워드프레스를 설치하게 되었다.