** 부처님 오신날에 쉬는 동안 문득 세션 확인에 대한 문제점이 떠올랐다.
** 기존의 로그인 확인은 컨트롤러에서 세션을 확인했다. 그도 그럴 것이 세션은 자바스크립트 상에서 확인하기가 어렵다고 생각했다.
@WebServlet("/login2")
public class LoginControl2 extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
HttpSession session = request.getSession();
if (session.getAttribute("user") != null) {
PrintWriter script = response.getWriter();
script.println("<script>");
script.println("alert('이미 로그인 되었습니다.');");
script.println("location.href='main'");
script.println("</script>");
} else {
request.getRequestDispatcher("/WEB-INF/login2.jsp").forward(request, response);
}
}
}
** 이건 이전 로그인을 구현한 게시물의 컨트롤러 코드이다.
** 서버에서는 가급적 페이지를 직접 만들어서 클라이언트를 던지는 일은 거의 없도록 하는 것이 좋다고 한다.
** 우리가 Ajax를 사용하는 것도 그러한 이유 중 하나이다. 차츰 프론트와 백앤드가 완전히 나뉘게 되면서
더이상 페이지를 만드는 것을 서버에서 맡지 않게 되었다. ajax 사용하기 전을 생각해보면 클라이언트는 서버에 어떠한 요청을 할 때 서버에서 JSP페이지를 만들어서 클라이언트에 던졌었는데 이제는 json같은 값만을 던져주게 되었다.
** 저 코드상의 문제는 <script> 부분인데 사실 저게 스크립트만이 있다하더라도 저 스크립트가 적힌 페이지를 만들어서 던져주는 것이라 한다. 그럼 서버에서 JSP를 만들어서 던저주는 것과 같은 것이므로 이 세션 확인을 아예 컨트롤러로 오기 전에 확인을 해야한다.
** jsp내에서 자바코드블럭을 쓰면 너무나 쉽지만 HTML코드와 자바 코드를 되도록 쓰고 싶지 않은 마음에 그러지 못했는데 sessionStorage를 알게 되었다.
** Http프로토콜은 연속적이지 않다. 단지 요청을 보내고 그에 대한 응답을 받을 뿐이다. 이전에 세션을 정리했던 대로 연속적이지 않은 것을 마치 실처럼 연속적으로 보이려고 사용하는 것이 쿠키와 세션이었다.
** 클라이언트(브라우저)가 처음 웹사이트에 접속할 때 서버는 클라이언트가 세션 아이디가 없다면 세션을 부여해준다. 그리고 이후의 요청마다 세션 아이디가 함께 온다.
** 우리가 세션에 setAttribute할 때나 getAttribute할 때 HttpSession 객체를 가져오는데 잘 보면 request에서 가져온다.
HttpSession session = request.getSession();
** 다른 요청들의 session이 아니라 저 요청을 한 클라이언트의 session id에 set하고 get하는 것이다.
** 이걸 잘 몰랐던 것이 눈에 보이지 않고 이를 톰캣이 알아서 해주기 때문이었다.
** 로그인이라는 것은
** A라는 사람이 id와 pw를 입력해 서버에 로그인 요청을 했을 때 서버는 이를 받아서 올바른 id와 pw인지 확인 후 올바르다면 그 유저 정보를 A라는 사람의 클라이언트(브라우저) 세션 아이디와 유저 정보를 세션에 담는데 이 세션은 서버가 관리하는 것이지 클라이언트에서는 무엇을 담았는지 알 수가 없다.
** 클라이언트는 웹사이트를 이용하면서 요청마다 세션 아이디를 내밀뿐 이것이 무엇이 담겼는지는 서버만이 알고 관리한다. 마치 일종의 장부와 같다. 아마 세션 아이디가 1번이라면(예를 들자면) 세션 장부에는 ( 세션 아이디 1번 / "키값" / 유저 정보 ) 이런 식으로 서버가 적어두었을 것이다.
** 그러면 컨트롤러에서 확인하자니 페이지를 만들어줘야하고, 컨트롤러로 오기 전 JSP에서 확인하자니 자바스크립트 상에서 세션을 열고 확인할 수는 없다.
** 그럼 어떻게 해야할까 쿠키에 담아볼까 하며 고민하던 끝에 웹스토리지라는 것을 알게 되었다.
** 이걸 사용해서 해결해보려고 했는데 결론적으로는 웹스토리지는 세션 방식이 아닌 JWT 같은 토큰을 '어디에' 저장할 것인가에 대한 고민이므로 세션 방식에서는 사용하지 않는듯 하여 개발일기에 적어만 두었다.
** 추후에 세션이 아닌 토큰으로 바꾸어볼 때 사용해봐야겠다.
1. 웹 스토리지 (web storage)
- 서버가 아닌, 클라이언트에 데이터를 저장할 수 있도록 지원하는 HTML5의 새로운 기능이다. 웹 스토리지와 쿠키의 기능 자체는 유사하지만, 쿠키는 약 4KB까지 밖에 저장 공간을 이용하지 못하는 반면에 웹 스토리지는 약 5MB까지 저장 공간을 이용할 수 있다.
- 웹 스토리지에는 로컬 스토리지 (local Storage)와 세션 스토리지 (session Storage)가 있다. 로컬 스토리지와 세션 스토리지는 각각의 고유한 특성이 있으며, 프로그래머의 필요에 따라 선택적으로 사용된다.
- 유효기간별 구분
구분 유효기간 localStorage 없음(반영구적) sessionStorage 브라우저 탭이 열려 있는 동안만 유효하며 종료 시 삭제됨 - 공통 메서드
메서드 설명 setItem(key, value) 해당 키 값으로 데이터를 저장한다. getItem(key) 해당 키 값의 이름을 가진 데이터를 가져온다. removeItem(key) 해당 키 값의 이름을 가진 데이터를 삭제한다. key(index) 해당 인덱스 값을 가진 키의 이름을 가져온다. clear() 모든 데이터를 삭제한다. length 저장된 데이터 수를 가져온다.
2. 세션 스토리지 (session storage)
- 세션 스토리지는 각 세션마다 데이터가 개별적으로 저장된다.
- 쿠키는 브라우저 내의 다른탭끼리도 공유가 되므로 같은 도메인에 다른 사용자로 로그인 할 경우 문제가 발생하기 쉬운데 비해 세션 스토리지는 탭별로 데이터를 관리할 수 있고 탭이 닫혔을때 모든 데이터는 삭제된다.
3. 로컬 스토리지 (local storage)
- 로컬 스토리지는 브라우저에 반영구적으로 데이터를 저장하며, 브라우저를 종료해도 데이터가 유지된다.
- 브라우저 자체에 반영구적으로 데이터가 유지되지만, 도메인 (domain)이 다른 경우에는 로컬 스토리지에 접근할 수 없다. 예를 들어, www.google.com에서 로컬 스토리지에 저장한 데이터를 www.ieeexplore.ieee.org에서 접근할 수 없는 것과 같다.
4. 어떤 유형의 데이터를 어디에 저장하면 좋을까?
- 자동 로그인 -> 로컬스토리지
- 입력 폼 정보 -> 세션스토리지
- 비로그인 장바구니 -> 세션스토리지
- 다시 보지 않음 팝업 창 -> 쿠키
♣ 참고 및 인용
'개발 일기' 카테고리의 다른 글
[문제 해결] properties를 사용할 때는 항상 (0) | 2021.07.22 |
---|---|
2021.06.17 개발 일기 (0) | 2021.06.17 |
[해결][Mybatis] insert 할 때 commit 안 됨 (0) | 2021.05.18 |
[해결]HTTP 상태 405 – 허용되지 않는 메소드 (0) | 2021.03.22 |
앞으로의 계획 (0) | 2021.03.17 |