같은 주소가 상태마다 다른 일을 했다

신청 화면을 맡았다. /apply.do 하나로 신청서 열기와 저장과 취소가 전부 처리되고 있었다.

Servlet 하나에 세 가지 일이 들어 있었고, 어느 쪽으로 갈지는 세션에 담긴 값이 정했다.

Open Table of contents

한 자리에서 갈리고 있었다
화면과 세션이 어긋나 있었다
주소 셋과 신청 번호
숨김 필드를 믿어도 되는지 모르겠다
정리

한 자리에서 갈리고 있었다

Spring 의 DispatcherServlet 이 *.do 를 다 받고 있었다. Controller 안에는 HttpSession 값을 보고 갈라지는 if 가 있었다. 상태가 NEW 면 폼을 보여 주고 EDIT 면 저장했다.

취소를 누르고 뒤로 갔다가 다시 저장을 누르면 신청이 두 건 생겼다. 세션 상태가 그 사이에 바뀌어 있었다.

화면과 세션이 어긋나 있었다

Controller 에 로그를 넣어 요청이 들어올 때의 HttpSession 값을 봤다. 같은 버튼인데 들어오는 값이 매번 달랐다.

브라우저에서 뒤로 가면 화면은 예전 것인데 세션은 최신이었다. 화면을 연 때와 버튼을 누른 때 사이에 값이 바뀐 것이다.

iBatis 쪽 로그도 켰다. log4j.properties 에 넉 줄을 넣으면 나가는 SQL 이 콘솔에 찍힌다.

log4j.logger.com.ibatis=DEBUG
log4j.logger.java.sql.Connection=DEBUG
log4j.logger.java.sql.PreparedStatement=DEBUG
log4j.logger.java.sql.ResultSet=DEBUG

java.sql.PreparedStatement 를 켜야 ? 자리에 들어간 값까지 보인다. 취소 뒤 저장에서 INSERT 가 한 번 더 나가고 있었다.

주소 셋과 신청 번호

주소를 셋으로 갈랐다. /apply/form.do와 /apply/save.do와 /apply/cancel.do로 나눴다.

주소만 보면 무엇이 일어날지 알 수 있게 됐다. 세션 값에 따라 갈리는 if 가 사라졌다.

저장이 끝나면 화면을 바로 그리지 않고 redirect:/apply/list.do 를 돌려줬다. Spring 은 redirect: 로 시작하는 뷰 이름을 그대로 그리지 않고 302 를 보낸다. 그러면 새로 고침으로 POST 가 다시 나가지 않는다.

JSP 폼에 신청 번호를 숨김 필드로 넣어 같이 보냈다. 저장 쪽에서 그 번호가 이미 있으면 새로 만들지 않게 했다.

숨김 필드를 믿어도 되는지 모르겠다

숨김 필드는 화면에서 고칠 수 있다. 이걸 믿어도 되는지 모르겠다.

서버에서 한 번 더 확인해야 할 것 같다. 찾아보니 Struts 1 에는 saveToken 과 isTokenValid 로 한 번 쓰고 버리는 값을 다루는 것이 있었다. Spring 에는 그런 것이 안 보여서 직접 넣어야 하는 모양이다. 지금은 번호가 같으면 넘어가는 정도만 해 뒀다.

jQuery로 버튼을 눌렀을 때 바로 막는 것도 넣어 봤다. 그런데 뒤로 가기로 들어오면 그 코드가 다시 돌아 소용이 없었다.

정리

주소 하나가 세션 상태에 따라 세 갈래로 갈리고 있었다
화면을 연 때와 버튼을 누른 때 사이에 상태가 바뀐다
뒤로 가기로 들어오면 화면과 세션이 어긋난다
iBatis 로그를 켜면 INSERT가 한 번 더 나가는 것이 보인다
주소를 셋으로 갈라 무엇이 일어날지 주소에 드러나게 했다
저장 뒤에는 redirect: 로 돌려보내 새로 고침이 POST 를 다시 내지 않게 한다
신청 번호를 함께 보내 같은 번호면 새로 만들지 않게 했다
숨김 필드를 믿어도 되는지 아직 모른다