CGI 프로그래밍 김승영 (nobreak@cgiserver.net)
1회 : 쿼리 스트링 디코더의 제작 2회 : CGI 테크닉 3회 : 인트라넷을 위한 웹 보드 제작
지난호에서는 쿠키, SSI등의 CGI 기법들을 알아보았다. CGI의 독특한 동작 방식 때문에 달라 져야하는 입·출력 기법을 짚어 보았으므로, 어느 정도 개념이 정립됐으리라 판단된다. 상태정보를 유지하지 못하는 점과 입·출력 방식의 차이를 제외하면 일반적인 그것과 별 차이가 없으므로 이번 호에서는 웹보드라는 CGI를 설계하며, 몇몇 기교를 적용하여 보며, 이러한 류의 프로그램을 제작하며 겪는 문제점을 살펴보자. 전체적으로 웹보드의 외관은 목록(list), 추가, 삭제, 관리 모듈을 갖추고 있어야 하겠다. 통합인터페이스로 구성하며, 각 모듈은 'mode'라는 쿼리로 분리하고, 하나의 CGI로써 다수의 DB를 관리할 수 있도록 하며 모듈간의 인자 전달은 과월호에서 설명한 ISINDEX 방식을 취하도록 하자.
데이터베이스 이러한 류의 프로그램 제작에 있어 핵심은 데이터베이스(이하 DB)의 선택 또는 구현이라 생각되는데, 다음과 같이 크게 3가지 방식으로 나눌 수 있겠다.
일반적으로 소프트웨어가 안정화 단계에 접어드는데는 몇 번의 버전업 작업이 동반되는데, 자체 설계된 DB의 구성에 문제가 지적된다면, 기존 자료의 안정성을 보장받기가 힘들다. 따라서 개발자들은 첫째와 둘째의 방법처럼 안정성이 어느정도 보장된 DB를 도입하게 된다. 이는 자료의 호환성, 신뢰성, 독립성이 제공되므로 소프트웨어의 버전업이나 구성의 변환 등에도 쉽게 대처가 가능하여 선호되는 방식이다. 그러나 자료구조가 독특하거나, 검색속도 향상 등의 이유로 DB 엔진 자체를 역파일등의 알고리즘을 도입하여 설계하는 경우도 흔히 볼 수 있는데, 파일 잠금에서부터 저장·추출의 최적화까지 개발자가 일일이 구현해야하는 짐을 져야 한다. 모두 장단점이 있을 텐데, 우리가 구현할 웹보드의 경우는 어떠한 판단을 내려야 할까? 대규모의 DB를 구축한다면, DBMS(DataBase Management System)를 도입하는 것이 효율적이겠지만, 웹보드의 경우는 자료가 만건을 넘기 힘들며, 자료의 양 또한 적기에 DBMS의 적용은 오리사냥에 대포들고 가는 격이라 판단된다. 또한 공개 배포를 목적으로 한다면 DBMS 배경지식이 요구되므로 사용자가 힘겨워 할 수 있겠다. 자체 엔진을 구현하는 것 또한 기능적 향상을 기대 하긴 힘드므로 제쳐 두고 배포되는 DB 라이브러리를 적용하도록 하자.
GNU 'gdbm' Library 여러 가지 종류의 DB 라이브러리가 존재하지만, 여기선 GNU Project의 일환으로 개발된 'gdbm' 라이브러리를 선택하였다. 'gdbm'는 기본적으로 유일한 'key'값에 하나의 'data'가 존재한다. 요즘 흔히 말하는 RDBMS라는 '관개형 데이터베이스 시스템'에서는 Table 정의, 패턴검색등이 DB 엔진 자체에 포함하므로 개발자는 단순히 SQL등을 적용하여 이를 제어할 수 있지만, 'gdbm'은 단순히 자료의 저장, 추출만을 지원하므로, 이러한 부분은 개발자가 손수 프로그래밍 하여야 하나, 그 구조가 간단하므로, 소규모 DB를 적용할 때 편리하다. 단점으로는 거친잠금기법을 사용하므로, 읽기 모드로는 여러 사용자가 접근할 수 있지만, 쓰기 모드로의 접근은 하나의 프로세스만이 허용된다. [표 1]의 코드는 'gdbm'을 사용하여 DB를 생성하고, 자료를 추가, 추출하는 함수를 예로 보여준다.
'gdbm' 배포판과 자세한 설명은 아래의 주소에서 얻을 수 있다. - ftp://cair-archive.kaist.ac.kr/pub/gnu/gnu.mit/gdbm-1.7.3.tar.gz - http://funnelweb.utcc.utk.edu/~harp/gnu/gdbm/gdbm_toc.html
테이블(Table) 설계 먼저 웹보드에서 사용될 테이블을 [표 2], [표 3]과 같이 구성하자. [표 2]는 웹보드의 구성에 대한 것이며, [표 3]은 게시물에 대한 테이블이다. 알아본 바와 같이 'gdbm'은 저수준의 제어만을 제공하므로, 원하는 형식의 테이블을 SQL의 'create table' 명령과 같이 간단히 구현 할 수는 없겠다. 우리는 DBMS가 웹보드에 불합리하다고 판단하였으므로, 좀 수고스럽지만 이러한 기능을 소프트웨어 자체에 심어 주어야 한다. 제작할 웹보드는 '글쓰기' 모드 또한 별도의 HTML문서로 제작하지 않고 통합화하려 하므로 'conf.language'라는 항목을 두어 몇가지 형태의 폼을 선택할 수 있도록 하였다. 이는 뒤에 나올 '관리' 모듈에서 제어된다.
목록 보기 모듈과 큐(queue) 구체적인 자료 형태까지 구상하였으니, 목록 보기 모듈부터 설계해 보자. 'wwwboard.cgi?db=test&mode=list'와 같이 호출되었을 때 적용되도록 하고, '제목, 이름, 날짜, 번호, 내용'을 패턴검색 할 수 있도록 하자. 검색패턴 없이 호출될 경우 마지막 포스팅된 게시물부터 보여주며, 현재의 변수는 ISINDEX 방식으로 상태 유지를 하도록 하자. 기본적으로 'conf.lastnum'에서 마지막 게시물 번호를 찾아 'conf.lines'의 개수만큼 출력하여 줄 수 있겠다. 출력된 페이지중 최상단과 최하단의 게시물 번호가 30과 15 라면, '다음페이지' 아이콘 링크엔 'wwwboard.cgi?db=test&num=14'를 '이전 페이지' 링크엔 'wwwboard.cgi?db=test&num=45'와 같이 구현 할 수 있겠다. 그러나 이렇듯 게시물 번호를 사용한 방범엔 약간의 문제점이 보인다. '다음페이지' 링크일 경우엔 별 문제시되지 않으나, '이전페이지' 링크의 경우 45번과 31번 사이에 삭제된 게시물이 있다면, 출력되는 게시물의 개수는 'conf.lines'에 정의된 개수 15(가정하자)보다 적은 출력을 보여줄 것이다. 패턴검색의 경우를 생각해 보면, 45번과 31번 사이에 매칭되는 게시물이 없을 수도 있다. HTTP 프로토콜의 특성상 일반적 프로그램과 같이 상태유지가 되지 않기 때문에 고려되는 부분일텐데, 큐를 적용하면 효과적으로 해결할 수 있다. 'wwwboard.cgi?db=test&num=31&dir=up'과 같이 호출하면, 내부적으로
31번 게시물부터 마지막 게시물까지(큰 번호) 검색된 결과를 큐에 저장후
인버스 출력하여 페이지당 검색개수를 [그림 1] 목록 보기 순서도 일정량 유지할 수 있다. 이를 도표화하여 [그림 1]에 나타내었고,
[그림 2]는 화면 출력 형태이다.
[그림 2] 웹보드의 목록보기 관리 모듈 과 비밀번호 확인 제작할 웹보드는 여러개의 게시판을 사용할 수 있는데, 각 게시판의 구성(configuration)을 관리 할 수 있는 모듈을 탑재하여 [그림 3]과 같이 웹상에서 관리를 행하면 편리하다. 관리 모듈에서는 [표 3]의 테이블 값을 정정할 수 있는데, DB를 사용하여 저장·참조하기도 하지만, 모듈화등의 이유로 'db.conf'와 같이 별도의 파일을 다음과 같은 형식으로 관리하기도 한다.
게시물의 삭제나, 관리 모듈 진입을 위해서는 신원 확인 방법으로 비밀번호를 대조 하는데, 비밀번호의 유출을 최대한 막기위해 입력된 비밀번호는 암호화(Encrypt)하여 저장하며, 각 모듈간의 전달시에도 암호화된 그것을 사용토록 한다. 입력된 비밀번호가 암호화되지 않고 관리 모듈로 전달(ISINDEX 또는 HIDDEN TAG)될 경우 '문서 소스 보기'등의 방법으로 유출될 수 있기 때문이다. 혹, 기존에 제작된 CGI가 보안보다는 관리의 편리성 때문에 이를 간과하였다면, 아래와 같은 HTML을 출력 문서에 삽입함으로써 [그림 4]와 같이 '문서 소스 보기'를 무력화 시킬 수 있으나, 모든 브라우저에 적용되는 것은 아니니 주의 바란다.
또한 아래와 같이 새로운 브라우저를 열어 출력하고, 일련의 절차를 마친 후 브라우저를 닫는 방법도 고려될 수 있다.
대부분의 유닉스 시스템에서는 단 방향 암호화 함수를 제공하는데 다음의 코드를 살펴보자.
같은 문자열을 암호화해도 'salt'값에 해당하는 2바이트의 문자열에 따라 전혀 다른 결과를 얻을 수 있는데, 복귀되는 문자열의 처음 2바이트는 salt값을 표시한다. 필자의 시스템에서 문자열 "0000"을 인자로 호출하였을 때 복귀되는 값은 "SYi30NGbHBYMs"였다. [그림 5]는 이를 이용한 비밀번호 확인 화면이다.
[그림 3] 관리 모듈
[그림 4] 'no-cache' 적용
[그림 5] 비밀번호 확인
쓰기 모듈과 쿠키(Cookie) 사용의 편리성을 위해, 쓰기 화면도 내장을 시키자. 쓰기 모듈로의 진입은 'wwwboard?db=test&mode=write'로 하며, 문서화일의 업로드도 지원하도록 하자. 업로드는 지난호에 알아본바와같이 enctype='multipart/form-data'로 인코딩하여 boundary값으로 분리, 저장토록 할수있다. [그림 6]과 같은 쓰기 화면의 인자는 이름, E-mail, 제목, 내용, 파일의 순으로 전달되는데, stdin에서 '--boundary'와 '--boundary' 사이의 값들을 순서대로 취하여 처리 할 수 있다.
[그림 6] 웹보드의 쓰기 메뉴 글을 쓸 때마다 이름, E-mail을 쓰는 것은 성가신 일 일수 있으니, 쿠키를 적용하여 필요한 정보를 클라이언트에 저장시키고, 쿠키가 존재하면 그 값을 이름과 E-mail란에 표시하여 주도록 하자. 또한, E-mail과 같이 검사가 가능한 부분은 타당성 여부를 판별하여 사용자의 실수를 알려줄수 있겠다. 아래의 코드와 같이 E-mail주소의 오류를 간단히 판별할수 있다.
글 보기 모듈 글 보기 모듈은 선택된 글을 [그림 7]과 같이 보여줄 때 사용되는데, 내용중에 'http://abc.com'과 같은 항목을 자동으로 링크해 주는 방법에 대해 살펴보자. 내용 출력은 공백도 정확히 출력하여 주어야 하므로, <pre> TAG나 <xmp> TAG를 활용할수 있는데, 자동 링크를 수행하기 위해서는 <pre> TAG와 [표 4]와 같은 출력 함수를 활용하여 구현할수 있겠다. [표 5]는 [표 4]의 함수를 사용한 출력 형태를 보여준다.
[그림 7] 자동 링크 적용 화면
로그(Log) 작성 웹서버에서 제공하는 로그 이외에 자체적인 로그를 작성해야 할 때가 있는데, 아래와 같은 관례를 지킨다면, 공개된 로그 분석툴도 그대로 적용할 수가 있다.
Time Out과 강제 시그널 (signal) 출력이 완료되지 않은 상태에서 사용자가 브라우저의 'STOP'버튼을 누르면 어떻게 될까? CGI는 강제 종료될까? 그렇지 않다. 서버와 클라이언트간의 연결만이 끊어지고 CGI는 계속 실행된다. 따라서, CGI는 어떠한 규제 없이 처리를 완료하고 정상 종료를 할 수 있다. 그러나 서버에 규정된 Time Out 시간 안에 종료하지 않으면, 서버는 해당 프로세서를 강제적으로 종료하려 시도한다. 대부분의 경우 이러한 경우까지 대처할 필요는 없지만, 프로그램의 구성상 DB의 동기화(Sync)나 파일 시스템 최적화와 같은 작업 중에는 종료전 마무리 작업이 필히 선행되어야 하는 경우가 있다. 아파치 서버의 경우 자식프로세서(서버는 자신을 복제[fork()]한후 복제된 프로세서를 해당 CGI로 변환 실행[execl()]한다. 즉, CGI가 자식프로세서임을 뜻한다.)가 강제 종료되지 않을 경우 SIGHUP, SIGTERM, SIGKILL 시그널을 약간의 시간차를 두고 프로세서에 보낸다. SIGKILL 시그널은 무시할 수 없기 때문에, 시그널을 포착한 시점부터 SIGKILL 도달 전에 (약 2, 3초) 필요한 작업을 마무리해야 한다. 다음 코드를 백그라운드로 실행시키고, 'kill -SIGHUP 프로세서번호' 명령을 내려보자.
마치며... 3회에 걸쳐 CGI의 전반적인 모습을 훑어보았는데, 필자 나름대로 부족한 점이 많아 욕심만큼 좋은 내용을 글로써 표현하지 못한 듯 싶다. 미숙한 글솜씨로 두서없이 쓴 글이지만 독자들이 이 글을 읽고 조금이나마 도움이 되었으면 한다. 코딩에 관한 궁금증은 아래 주소에서 소스를 다운 받아 살펴보기 바란다. http://cgi.hongik.ac.kr/wwwboard/CrazyWWWBoard2.0.tar.Z
|
