# HttpSession

daizy13125

서버에 정보를 임시로 저장하려면 session을 이용하면 되는데, 이 세션은 브라우져가 켜져 있을때만 유지가 된다. java 컨트롤러에서 session을 가져오려면, HttpSession session=request.getSession(); 을 선언해 주고, 세션에 원하는 정보를 저장해 주면 된다. 이 부분이 있는데, 이것은 target을 삼항연산자로 파라미터로 attribute값을 target으로 가져왔을 때 그 값이 null이면 아무것도 가져오지 않고, 있으면 target값을 가져온다는 뜻이며, 세션에 그 target값을 저장하는 것인데, 그렇다면 target값은 누가 보내주는것인고 하니, 장바구니 jsp중 로그인이 안된 상태에서 주문하기 버튼을 눌렀을 경우 로그인을 하면서 cart/list로 가라고 타겟값을 주는 것이다. 그럼 위처럼 타겟값을 갖고 로그인이 되면, 이렇게 타겟값이 있는 경우 타겟값을 갖고 ("/cart/list/")로 이동한다는 것이다.

ppoii0961

폼의 유효성을 검증할때 javascript 를 사용해 DOM을 조작해 클릭 이벤트를 걸고 유효성을 체크하는 방식은 클라이언트 측에서 진행된다. 자바에서 제공하는 validation 패키지에는 유효성 검증을 위한 인터페이스들이 들어있다. 이것을 사용하는건 서버측에서 유효성 체크하는 방식이다. 설정 스프링부트 빌드 해주는 곳 https://start.spring.io/ 프로젝트 빌드 방식 선택(이 글에선 Maven)하고 버전 선택한다. ADD DEPENDENCIES 누르고 추가할 라이브러리 검색해서 찾는다. EXPLORE 누르고 자동으로 만들어준 설정파일에서 validation 라이브러리 의존성 추가 부분 복사해온다. 게시글 작성 유효성 검증 Model NotBlank는 유효성 검증 관련 어노테이션 중 하나다. null, length가 0인 문자열(빈 문자열), 공백만 있는 문자열이 불가능 함을 유효성 검증한다. ht

junkue20

오늘은 고객의 마이페이지 생성 실습을 진행하였다. 그중 핵심이 되는 부분만 간단하게 정리를 하였다. 필터(로그인 상태 체크용) controller도, mapper도, dto도 아님. 새로운 class를 생성해주어야 한다. 위와 같은 경우에는 기존 HttpSession클래스를 불러와 로그인 상태에서만 접근이 가능한 페이지에서(예를들면 사용자의 마이페이지 등) 사용자의 id, 이름 등의 정보를 반복하여 일일이 세션에 저장했던 다른 Controller들과는 달리, 로그인때 받아왔던 사용자의 정보를 Filter를 통해 저장한 뒤 필요로 하는 모든 페이지에서 바로바로 간편하게 쓸 수 있게끔 하는 implements 이다. 세션에 저장된 정보를 토대로 request와 response의 객체를 각각 저장한 이후 System.out.println을 이용하여 필터를 적용시킨 url을 출력시키면 콘솔창에 아래와 같이 필터가 적용되어있는 주소에 한해서 세션의 접근이 이

seungyeonnnnnni

HttpSessionListener를 이용해 현재 로그인 중인 사용자 프로필 나타내기. HttpSessionListener HttpSession 객체가 생성되고 제거될 때 발생되는 이벤트인 HttpSessionEvent를 처리하는 리스너 HttpSession에는 다음과 같이 현재 접속한 클라이언트에 대한 정보를 담을 수 있다. 따라서 다음과 같이 UserController의 login 부분에서 로그인 성공 시 세션을 생성하고 클라이언트에 대한 정보를 담는다. User 객체는 다음과 같다. UserDetails 객체를 상속해 이루어져있다. SecurityContext에 들어갈 수 있는 객체는 Authentication 타입 뿐이다. Authentication 타입에 저장할 수 있는 객체는 UserDetails와 OAuth2User 타입이 있다. 회원 가입 프로세스를 직접 구현한 경우 UserDetails 타입 객체를 사용하고, 소셜 로그인

ksk7584

Session 서버의 Session Storage를 만들어 Key-Value 형태로 저장되는 자료구조를 뜻한다. 쿠키는 브라우저에 저장되므로 Value가 String Type으로 정해져 있는데 반해, 세션은 Object Type을 이용해 자바의 모든 객체를 담을 수 있도록 구현된다. 이 세션 Value에 무엇을 넣냐에 따라 역할이 달라지는데, 쿠키를 넣어 클라이언트 간의 구분을 위해 사용할 수 도 있고, 별도의 데이터를 넣어 Cache Memory처럼 활용할 수도 있다. 여러 사용자가 동시 접근할 수 있기 때문에 Thread-Safe한 자료구조를 사용해야 한다. 톰캣의 세션의 경우에도 ConcurrentMap을 사용하고 있다. Session-Cookie 서버의 세션과 클라이언트의 쿠키를 혼합하여 사용하면 다음의 장점이 있다. 클라이언트가 아닌 서버 세션에 쿠키를 저장하고 관리하므로 클라이언트에게는 세션 Key만 쿠키에 담아서 보내면 된다. 더이상 쿠

moon-tree

◆ 템플릿 페이지(template page) 홈페이지를 상(header), 컨텐츠(main), 하단(footer)으로 구분하여 생성 후 불러온다. 상단과 하단은 별도의 페이지로 만든 뒤 불러오도록 처리한다. (주의) 템플릿 페이지는 어디서 실행될 지 모르므로 상대 경로 사용 금지! ◆ jsp가 제공하는 설정 중에 ``라는 설정이 있다. 이를 사용하여 상단(header), 하단(footer) 템플릿 페이지를 불러온다. `` 본문 내용 기입 `` ◆ 페이지 접근 방법 일반적인 접근 : 메뉴 또는 회원가입 완료 페이지의 링크로 이동 로

jhkang

* 목표 세션저장소로 데이터베이스를 사용하여 애플리케이션 재시작시 로그인 데이터가 유지되도록 한다. 1. 세션 저장소 1) 필요성 세션은 WAS의 메모리에 저장된다. 현재 프로젝트도 내장 톰켓의 메모리에 저장되는데 메모리에 저장되는 구조는 아래와 같은 문제점이 있다. 메모리에 저장되기 때문에 애플리케이션 재실행시 항상 초기화된다. 즉, 배포할 때마다 톰켓이 재시작되는 것이다. 2대 이상의 서버에서 서비스를 하고 있다면 한 서버에서만 세션정보를 가지고 있게 된다. 따라서 톰켓마다 세션 동기화 설정을 해야만 한다. 이와 같은 이유로 세션 저장소를 따로 사용하는 것이 좋다. 2) 세션 저장 방식 A. 톰켓 세션 사용 일반적으로 별다른 설정을 하지 않을 때 기본적으로 선택되는 방식이다. (단점) 톰캣(WAS)에 세션이 저장면 2대 이상의 WAS가 구동되는 환경에서는 톰캣들 간의 세션 공유를 위한 추가 설정이 필요하다. B.

jhkang

* 목표 HTTP 세션에 대해 알아보고 코드로 구현해보자. 1. 세션으로 사용자 정보 유지하기 1) HTTP 세션(session)은 왜 필요할까? 세션은 일정 시간 동안 사용자의 상태를 일정하게 유지시키는 기술이다. 사용자는 로그인할 때 개인 정보를 입력하는데 이 데이터는 서버에 임시로 저장된다. 아무런 설정을 해주지 않으면 이때 저장된 데이터는 페이지를 새로 고침하면 만료된다. 따라서 페이지가 새로 고침될 때마다 로그인해야 하는 불편함이 있다. 이때 세션을 활용하면 로그인 정보를 유지시킬 수 있다. 2) HTTP 세션을 언제 생성될까? 여기서 세션은 언제 만들어질까? 모든 요청에 대해 세션을 만드는 것이 아니라 세션을 사용할 때 생성한다. 스프링에서는 세션을 관리하기 위해 HttpSession 인터페이스를 제공한다. HttpSession은 setAttribute 혹은 getAttribute 같은 api를 호출하는 시점에 요청/생성한다. > [Http

dh8570

📌 forward VS redirect > * forward > - requestDispatch로 지정한 주소로 넘어가긴 하지만 forwarding 할 시, 처음에 요청받은 요청 action 주소로 출력한다. > > * 예시 > - 원래 주소 : 경로/test.jsp > - 요청 action : test > - forward 주소 : ./test2.jsp > - 요청 후 응답 주소 : 경로/test > > * redirect > - 사용자가 요청한 action 주소로 가긴하지만 사용자의 요청 정보를 다른 jsp페이지로 건낼 수 없다. > - 서버가 해당 요청을 redirect 할 시, redirect한 주소로 출력된다.(처음 요청 정보는 없어짐) > > * 예시 > - 원래 주소 : 경로/test.jsp > - 요청 action : test > _- re

dailyzett

1. redis 방식을 채택한 이유 세션 관리를 하나의 서버에서만 한다면 추후 서버를 스케일 아웃할 때 세션 불일치 문제가 발생할 수 있다. 이를 해결하기 하려면 session clustering, sticky session, redis session 방식이 있는데 여기서는 session clustering 이나 sticky session 은 장점보단 단점이 극명해서 redis session 방식으로 진행하고자 한다. 아래 링크는 분산 서버일 때 세션 관리 방법들을 정리한 글이다. 서버가 여러대일 때 세션 스토리지를 관리하는 방법 2. redis 설치 실제 프로젝트를 NCP나 AWS를 이용해 배포한 상황이라면 redis c

saint6839

HttpSession을 사용하다가 생긴 의문 HttpSession에서 session key는 하나인데 어떻게 여러 유저를 구분해서 값을 가져올까? 예를 들면 아래와 같다. 위와 같이 createdUser 라는 하나의 문자열을 key로 이용하여 Servlet Container는 Http client와 Http server 간의 세션을 생성한다. A라는 유저가 세션 값을 저장한다고 하면 createdUser라는 문자열을 key로 이용하여 세션 값을 저장할 것이다. 그렇다면 또 다른 B라는 유저가 있다고 가정하면 어떨까? B라는 유저도 똑같은 createdUser라는 문자열을 key로 이용하여 세션 값을 저장할 것이다. 즉, 이럴 경우 어떻게 사용자마다 구분 된 세션을 가져올 수 있는지에 대한 의문인 것이다. 결론부터 말하자면 Session은 각 클라이언트마다 하나씩 생성되어 제공된다 각 클라이언트의 요청마다 Session은

iseon_u

HttpSession 요청 매핑 어노테이션 적용 메서드에 HttpSession 파라미터 추가 setAttribute() 세션 값 설정 removeAttribute() 세션 값 제거 세션 값 Thymeleaf 에서 조회 session.세션 값 으로 접근

kanamycine

Mentor's FeedBack > mentor says "수고 많으셨습니다! Session에 대해서 학습해보시는 걸 추천합니다. " HTTP SESSION > provides a way to identify a user across mmore than one page request or visit to web site and to store information about the user. > > 두 개 이상의 페이지에서의 요청이나 웹사이트 방문에서 사용자를 식별하고 해당 사용자에 대한 정보를 저장하는 방법을 제공합니다. 서블릿 컨테이너는 이 인터페이스를 사용하여 HTTP 클라이언트와 HTTP 서버 간의 세션을 생성한다. 세션은 사용자의 두 개 이상의 연결 또는 페이지 요청에 대해 지정된 기간 동안 지속된다. 세션은 일반적으로 사이트를 여러 번 방문할 수 있는 한 사용자에 해당하고, 서버는 쿠키를 사용하거나 URL을 다시 작

woply

📖 ✏️ > 이 글은 세션 기능을 구현할 때 사용할 수 있는 두 가지 방법(서블릿이 제공하는 HttpSession와 스프링이 제공하는 @SessionAttribute)을 학습하고 정리한 포스팅이다. 서블릿이 제공하는 HttpSession, 스프링이 제공하는 @SessionAttribute 세션이라는 개념은 대부분의 웹 애플리케이션 개발 시 사용된다. 웹 개발에 필수적인 역할을 하는 서블릿과 스프링은 각각 세션을 쉽게 사용할 수 있는 별도의 기능을 제공한다. 서블릿이 제공하는 HttpSession와 스프링이 제공하는 @SessionAttribute의 사용 방법을 살펴보자. 직접 구현하는 방식의 세션보다 훨씬 빠르고 간편하게 세션을 구현할 수 있다. 1. HttpSession을 이용하여 세션을 직접 구현 서블릿이 제공하는 HttpSession은 JSESSIONID이라는 이름의 세션을 자동으로 생성한다. >

yshjft

session session 쿠키만을 이용하여 로그인을 진행하는 경우 보안적으로 문제(쿠키의 조작 가능성, 쿠키 탈취 가능성, 탈취된 쿠키 평생 이용 가능성)가 발생할 수 있다. 따라서 이를 보완하고자 session을 사용한다. session 로직 client 로그인 → server server는 로그인을 위해 전달된 정보를 통해 사용자를 확인하고 session ID와 value를 session 저장소에 저장한다. session ID 추정이 불가능한 값이다. UUID라고 생각하면 된다. value 사용자 정보가 담긴 객체를 저장할 수도 있지만 세션은 메모리에 저장되기 때문에 최소한의 정보(사용자 ID)만을 저장해야 한다. server → client 사용자를 확인하고 세션을 세션 저장소에 저장하면 server는 set-cookie 헤더에 session ID를 설정하여 응답을 보낸다.(쿠키 전달)

leocodms

지금까지 아주아주 편리하게 잘 사용하던 HttpSession이 이번 프로젝트에서 말썽이었다. 문제 1 세션 저장은 잘 하는데, 새로운 request에서 항상 새로운 httpsession을 생성했다. (request.getSession()) 문제 2 HttpSession이 set되면 sessionId를 쿠키에 저장하여 다음 request에 함께 보낸다는 것을 알았다. response헤더 확인 결과, 쿠키에 sessionId를 잘 저장하는 것을 확인했다. 이는 쿠키를 잘 저장하는데, 이 세션정보를 다음 request에 못실어 보내는 것이 문제임을 뜻했다. CORS ERROR 얘가 또 말썽이었구나. axios request에 axios.defaults.withCredentials = true; 를 주어서 토큰 인증을 사용한다는 설정을 추가했다. spring boot에는 WebConfig설정에 .allowCredentials(true)를 설정했다. 이를 위해 개발 단계

kyukim

회원과 질문간의 관계 매핑 > - 유저객체처럼 회원데이터가 최상위에 놓이는 경우가 대부분이기때문에 일반적으로 유저에서는 필요한경우가아니라면 다른 객체와 관계를 맺지않는게 좋다. > > >- get을 이용해서 데이터를 꺼내오는 게 보인다면 스스로에게 어떻게 객체를 이용해서 로직을 구현하는게 더 낫지않을까 의문해보는 게 좋다. 퀘스쳔 객체를 생성할 때 userId를 getter로 가져와서 사용했다. 이런 경우에 getter를 통하지않고 생성되어진 유저 객체를 통해서 가져올수 없을까 구현해보는게 더 좋다고한다. 이유는? 잘 모르겠다. 이전 3월 12일 TIL에서 자바지기님이 Getter에 대한 캡슐화의 예시를 잘 보여주셨는데 어쨋든 Getter를 이용하는건 좋지 않은가보다. Getter 쓸일 있으면 다른걸로 바꿀수없는지 앞으로 고민해봐야겠다. 질문 상세보기 기능 ![](htt