Programmer's Progress

게시글 수정 구현 방법과 관련된 내용을 소개하기 전에 앞서 게시글 수정을 구현하는 것이 얼마나 복잡하고, 어려운 것인지를 설명해야 할 것 같다. 먼저 게시글을 수정하기에 앞서, 수정해야 할 게시글의 제목, 내용, 이미지 등등을 백엔드 서버에 요청해야 할 것이다. 이때 JQuery의 AJAX기능을 활용해 비동기식으로 요청한다. 게시글의 제목이나 내용 자체는 DB에 저장된 내용을 SQL Mapping방식인 MyBatis프레임워크를 이용해 얻어오기만 하면 되므로 간단하다. 그런데 이미지는 이미지 자체를 DB에 저장한 것이 아니라, 서버 컴퓨터의 D:드라이브에 저장되어있고 DB에는 해당 게시글의 번호, 원본 이미지 이름, 난수 이름만을 저장하고 있다. 아래의 릴레이션 스키마를 확인해보자. 하나의 게시글은 여러 ..

게시글 삭제 구현 과정을 설명하기 전에 짚고 넘어가야 할 것이 있다. 먼저 기존의 코드 중에서 새로운 게시글, 메시지 번호를 얻는 방법을 변경하였음을 밝힌다. 기존 방식은 이렇다. SELECT NVL(MAX(article_id),0)+1 FROM free_board와 같이 현재 존재하는 게시글들 중에서 가장 게시글 번호가 큰 게시글의 번호 + 1을 새로운 게시글에 할당한다. 이 방식에는 큰 문제가 있었다. 1. 현재 게시글 목록에 번호가 1, 2, 3인 게시글들이 있고 각각 서로 다른 탭에서 참조하고 있다고 가정하자. 2. 첫 번째 탭에서 3번 게시글을 삭제하고, 다시 새로 게시글을 작성한다. 3. 두 번째 탭에서 기존 3번 게시글을 삭제하려고 하면, 이미 삭제된 게시글이 아닌, 2번 과정에서 작성한 새..

앞서 언급했듯이, 비밀번호는 절대로 복호화 가능한 형태로 암호화해서는 안 된다. RSA든, AES든, DES든 어떠한 암호화 알고리즘을 사용하더라도 복호화가 가능하다면 이 비밀번호가 담긴 레코드를 탈취당했을 때 큰 문제가 발생할 것이다. 따라서 복호화가 불가능한, 단방향 해싱 알고리즘인 SHA512와 랜덤 한 값 SALT를 갖고 비밀번호를 암호화하였다. 그러나 복호화가 불가능하기 때문에 비밀번호 찾기를 구현하는 데 있어서 큰 문제가 있었다. 복호화가 불가능하기에, 기존의 비밀번호가 무엇인지 도저히 알 수가 없다는 것이다. 단순하게 JS의 alert( )를 이용해 기존 비밀번호를 출력하기에는 큰 문제가 있었다. 기존 비밀번호가 무엇인지 알지 못할 뿐만 아니라, 알고 있다고 하더라도 이 비밀번호를 DB에서 ..

메시지 읽기 기능을 구현하는 과정을 설명하기 전에 먼저 웹서비스의 전반적인 구조를 변경했음을 밝힌다. 기존에는 스프링 프레임워크, 마이 바티스 프레임워크 등, 프레임워크의 도움을 받지 않고 라이브러리 추가부터 의존관계 구성, MVC 패턴으로 설계 등등 많은 것들을 직접 구현했었다. 하지만 스프링 프레임워크를 사용하지 않고는 DAO, Service, Controller 등의 클래스 객체들이 각각의 객체들의 정보를 담아두도록 일일이 생성자 및 setter( ) 메서드를 설정하기란 번거로운 일이었고 또한 마이바티스 프레임워크 없이 DAO클래스에서 질의를 수행할 때에는 일일이 SQL문을 작성해주어야 했기에 상당히 가독성도 떨어지고, SQL문을 작성하는 것도 어려웠다. 특히 DBMS에서 단일 SQL문에 대해서는 ..

메시지 보관함을 구현하기에 앞서 먼저 메시지 관련 DB 스키마를 변경했음을 밝힌다. 먼저 기존에는 SYS_GUID( ) 함수를 이용하여 중복될 확률이 거의 없는 난수 값을 사용하여 메시지 ID로 사용했었다. 물론, 이 방식도 나쁘지 않다고 생각했지만, 사용하면 할수록 불편하다는 느낌을 많이 받았다. 디버깅도 그렇고, DB 질의를 할 때에도 16바이트 난수 값을 가지고 처리하려니 상당히 어려웠다. 따라서 이를 INT타입으로 변경했는데, 사실 엄청 대단하고 규모가 큰 서비스도 아니고 간단한 웹 서비스를 구축하려는 것이기에, 게시글이며 메시지며 그 숫자가 21억을 넘지는 않을 것이라 판단하고 INT타입으로 데이터 타입을 변경했다. 삭제 검색 송신 수신 위의 JSP코드에서 id가 LIST인 table태그에 메시..

이번에는 사용자끼리 메시지를 주고받을 수 있도록 메시지 기능을 추가할 것이다. 메시지 기능을 추가하기에 앞서 먼저 메시지에 대한 스키마 다이어그램을 소개하자면 보는 것과 같이 송신함과 수신함을 위한 테이블을 따로 구성하였는데 이는 메시지를 보낸 사람이 해당 메시지를 자신의 송신함에서 지우더라도, 즉 송신 기록을 제거하더라도 수신자에게는 그대로 해당 메시지가 남아있을 수 있도록 하기 위함이다. 물론, 송신 메시지인지, 수신 메시지인지 구분하는 값을 더 추가한다면 하나의 테이블로도 처리가 가능하긴 하지만, 하나의 릴레이션이 너무 커지면 데이터 접근 속도도 그렇고 여러 가지 면에서 상당히 불리한 점이 많기 때문에, 일부러 분할하여 처리하였다. 메시지의 기본키는 SYS_GUID( ) 함수를 이용하여 16바이트의..

기본적인 회원가입과 로그인을 구현했으니, 로그아웃과 아이디/비밀번호 찾기를 구현할 차례다. 기본적인 원리는 아래와 같이 설계되었다. 우선 스키마 다이어그램에서 빨간색 애트리뷰트는 기본키, 파란색 애트리뷰트는 외래 키를 의미한다. 그렇다면 노란색은 어떤 애트리뷰트를 의미하는 걸까? 바로 UNIQUE 한 값, 즉, 후보 키로써의 역할을 수행함을 의미한다. 상식적으로 회원가입을 진행할 때 같은 이메일, 전화번호로 회원가입이 가능한 경우는 거의 경험하지 못했을 것이다. 그도 그럴 것이, 하나의 이메일, 전화번호는 모두 한 명의 사람에게 속해있기 때문이다. 각 개인은 회원가입 시 입력한 전화번호와 이메일 주소를 아이디를 찾을 수 있게 된다. 그렇다면 비밀번호는 어떤 식으로 찾을 수 있게 할 것인가? 회원가입 시에..

지난 포스팅에는 회원가입을 구현하는 과정과 시연을 보였다. 사실 회원가입이야 이전에도 여러 번 구현해본 적 있었지만, 이번에는 좀 체계적으로 DB를 구성하고 활용하기 위해 최대한 사용자의 릴레이션에는 나이, 성별 등의 서비스 구현에 크게 필요하지 않은 애트리뷰트는 과감히 삭제했고 대신, 아이디를 기본키로 설정후, 이를 외래 키로써 참조하는 릴레이션들을 여럿 구성하였다. 아이디/비밀번호 찾기 회원가입 해당 소스코드는 로그인을 위한 form 태그의 소스코드 일부이다. 상당히 구성이 간단하다. 사용자로부터 ID와 PW를 입력받고, 이 정보가 DB에 존재하는지 여부를 확인하면 끝이다. 그리고는 세션객체를 생성하여 해당 회원정보를 저장하고, 이 세션에 사용자 정보가 담겨있는지 여부를 판단하여 JSP를 이용해 기존..