다음날.
혹시나 하는 마음에 출근 하자마자 DB를 실행해 인증 내역 쿼리를 실행해 봤다.
“햐 ㅅㅂ 쉐키들~”
욕이 육성으로 터져 나왔다. 동시에 CS 팀장으로부터 전화. 띠리링~
“네. 개발팀 봄이입니다. 인증 내역 때문에 전화 주신거죠?”
“네. 어제와 같은 상황이네요.”
“이 녀석들 어젯밤 10시부터 다시 시작이네요. 국내 IP로 돌렸나 봐요. 확인해 보고 다시 연락 드릴께요.”
“네. 수고하세요”
터미널 접속해 인증 시도 로그를 확인해 봤다. 이 쉥키들 Proxy를 돌리는지 국내 여기 저기 IP로 접속해 인증 시도를 하고 있었다. 막아야 하는데… 어떻게? 워낙 접속하는 IP가 불특정 다수라 무작정 IP만으로 막을 순 없었다. 그렇다고 손 놓을 순 없어 일단 인증 시도되는 IP를 수집해 보도록 한다. 심플하게 DB 테이블 구성해 수집하도록 구성해 서비스 반영 시켰다. 한 시간 남짓 지나 수집된 정보를 보니 특정 IP 몇 몇 개가 수십회의 인증을 시도 하고 있었다. 그리고 로그 패턴을 봐선 봇이 확실한 것 같고. 일단 인증 시도 5회 이상인 경우는 정상이 아니니까 차단 하도록 했다. 급한 상황이라 로컬 테스트 후 바로 운영 서비스 반영으로 이뤄 졌다.
하지만 더 근본적인 문제를 해결 해야 했다. 지금 인증 창은 인증 업체와 Server To Server로 개발 돼 있어 인증 화면을 우리 회사의 요구대로 커스터마이징 할 수 있는 구조다. 타 인증 화면은 키보드 보안으로 ActiveX( 또는 그에 준하는 이상한 플러그인)를 설치 해야 하지만 우리 사이트는 그런 것은 없지. 음… Captcha(보안 그림 문자)를 추가 하기로 했다. 일전에 Captcha를 만들어 놓은 클래스가 있어 서비스 적용에는 어렵지 않았다.
소스를 컨버전 시키면서 걸리는 것이 생긴다. 바로 사운드 출력이다. 보유하고 있는 사운드 파일은 숫자들 뿐. 보안 문자는 숫자+영대문자 조합인데 이 경우 정상적인 사운드 출력을 할 수 없었다. 구글링 돌려서 영문 알파벳 사운드 파일을 다운로드 받았다. Mp3파일을 Wav로 변환하니 용량이 문제가 됐다. 약 10MB(아악~!). 이 파일을 WAR에 포함 시키기엔 너무나 컸다. 그래서 서버 특정 경로에 파일들을 복사 해 놓고 사용 하기로 했다. 하지만 너무나 귀찮다. 운영서버, 개발서버, 각 개발자 PC에 모두 동일 경로에 파일을 복사해 놔야 하는 문제라니…… 나중에 개발 환경 재 설정 할 땐 어떻게 하려구… 고민이다. 하지만 WAR파일 크기를 10MB나 늘리는 것은 죄이며 악이다. 어쩔 수 없다.
Wav 파일 복사 완료 후 테스트 진행 해 봤다. 웬걸. 오류다. 파일을 찾을 수 없다는 오류. 이상하다. 접근 경로에 분명 파일이 있는데. 파일 경로 및 파일을 읽어 오는 파트에 BP를 걸어 값을 확인해 봤지만 File 정보에 있는 값은 정상 이였다. 뭐지? ㅡ,ㅡ; 혹시나 하는 마음에 Sound Resource의 구현부 클래스에 에러 로그를 추가 해 봤다. Exception이 그 클래스에서 발생. 다행히 에러 메시지는 친절 했다. Bit/Sample rate를 낮춰달라는 메시지. 요구 사항에 맞춰 Wav파일을 다시 변환 작업을 진행 했다. 용량도 많이 줄었다. 1.7MB… 다시 갈등이 생긴다. 이 정도 크기면 WAR에 포함 시켜 볼만하다 싶었다. 그래. 포함 시키는 것으로 결정. 아까 서버에 복사해 뒀던 Wav 파일을 모두 삭제 시키고 사운드 파일을 Resource 영역에 복사 시켜 놨다. 테스트 결과 사운드 잘 나온다.
그런데 Resource 경로가 사운드 파일이 들어가면서 좀 보기가 안 좋다. 개인적으로 파일이 많은 건 좋아하지 않아서. 그래서 하나로 합치기로 한다. 깔끔히 파일이 합쳐 졌다.
/** 파일 내용 byte array로 변환 */
private static byte [] getByteArrayFromFile( String fileName ) throws IOException{
final RandomAccessFile raf = new RandomAccessFile(fileName, "r");
final byte[] result = new byte[(int)raf.length()];
raf.readFully( result );
raf.close();
return result;
}
public static void main(String[] args) throws IOException {
final Map<String, byte [] > rdSource = new HashMap<String, byte [] >();
final String headerPath = "K:\\AlphabetWavs\\";
final int [][] array = new int [][]{{48, 10}, {97, 26}};
for( int [] item : array ){
int i=item[0], count=item[1]+i;
for( ; i<count ; i++ ){
final String name = (char)i;
rdSource.put(name, getByteArrayFromFile(headerPath + name+".wav"));
}
}
final ObjectOutputStream oos = new ObjectOutputStream( new FileOutputStream( headerPath+"CaptchaSound.dat" ) );
oos.writeObject( rdSource );
oos.flush();
oos.close();
}
// 프로그래머 개시판이니까 이런 내용 들어가도 괜찮겠지? ㅋㅋㅋ
Captcha의 정보는 DB를 이용하기로 했다. 과거 Captcha정보를 Session에 보관 했더니 브라우저 개발 툴에 정보가 노출 되는 경우도 있고 모바일이나 App에서 Session이 정상적인 동작을 하지 않는 경우도 있었다. Captcha정보를 DB에 추가 후 발생된 인덱스 정보만 암호화 처리 후 Front에 넘기기로 했다. 인증 정보 요청 전 Captcha 컨트롤러를 통해 결과 여부를 확인 하고 성공으로 전달 되면 인증 요청 함수를 호출 하도록 작업 했다. 만에 하나 악의 적인 목적으로 Captcha를 호출 하지 않고 바로 인증 요청을 할 경우 문제 될 수 있기 때문에 인증 요청 함수에도 Captcha를 통과 했는지 검사하는 기능을 추가 했다. 나의 요구 사항에 퍼블리셔는 재빠르게 화면 수정을 완료 했다. 다시 테스트 로컬/개발/운영 테스트 진행. 간혹 개발자 중 귀찮아 하는 사람들이 있는데 이는 꼭 해야 하는 과정이다.(과거 이런 단순 루틴을 하지 않아 발생 되는 문제를 수도 없이 봐 왔기 때문에)
서비스 반영까지 완료 후 로그 창을 띄우고 내가 직접 인증을 해 본다. 로그가 정상적으로 DB도 정상적으로 이뤄 졌다.
띠리링~ 띠리링~
“네 저 개발팀 봄이인데요. 인증 화면 수정 했습니다. 보안 문자 추가 했어요.”
“네~ 저도 한번 해 볼께요. 수고하셨어요.”
전화를 끊고 다시 로그를 살펴 본다. DB도 다시 조회해 본다. 로그는 한 시간 가량 계속 시도 정보가 올라오다가 사라 졌다.
‘휴~ 다행이야.’
퇴근 전 다시 로그와 DB를 조회 해 본다.
정상이다.
잘 끝났군. 퇴근하자.
(하지만 이런 생각은 수 일 후 싹 바뀌게 된다. 인간은 왜 똑 같은 실수를 반복 하는가…)
