개발

<카카오 OAuth를 기반으로 알아보자>카카오 OAuth 공식문서카카오 공식 문서와 저의 이해를 바탕으로 작성되었습니다. 카카오 로그인은 카카오 계정과 애플리케이션을 연결하고 토큰을 발급받아 카카오 API를 사용할 수 있도록 하는 기능입니다.토큰은 두 종류가 잇는

<Java 8>​LocalTime/LocalDate/LocalDateTime시간대 (Zone Offset/ Zone Region)에 대한 정보가 전혀 없는 API이다.한국에서 입력한 값이 미국으로가도 동일하므로 생일 같은 경우에 가장 적합하다.​ZoneOffset

Redis를 JPA Repository를 이용하듯이 인터페이스를 제공하는 스프링 모듈CRUD Repository를 지원하기 때문에 좀 더 직관적으로 사용가능하다.​Redis Java Client현재 스프링에서 지원하는 clientjedis, lettuce만 현재 공식

HandlerMethodArgumentResolver를 커스텀마이징 해보자우선 HandlerMethodArgumentResolver 는 컨트롤러 메소드에 여러 인자 값(@PathVariable)을 추가해서 자주 작업을 한다.이런 인자들이 즉, parameter로 쓰여진

인증은 모든 API 요청에 대해 사용자를 확인하는 작업이라고 생각하면 된다.사용자 A, B가 있는데 서버에서는 누가 보낸 요청인지 정확히 알아야한다.이때 쓰는 통신 방식이 HTTP 통신입니다. HTTP 통신은 응답 후 연결이 끊기며 과거에 대한 정보를 담지 않는 sta

Adapter패턴은 서로 호환되지 않는 두 클래스를 호환되도록 만들어준다. client -----depends on ----> target ^

공통점 : 모두 클라이언트와 다른 객체 사이에 끼여들어서 클라이언트로부터 요청을 받아와서 다른 객체한테 전달해주는 역할을 한다.어댑터 : 다른 객체의 인터페이스를 바꿔줌프록시 : 똑같은 인터페이스를 사용함.

<하려는 일>Oauth를 통해 가입을 시키려고 할 때, 카카오와 네이버 Oauth를 다루는 컨트롤러에서 코드 겹치기 때문에 이를 어댑터 패턴으로 빼고자 한다.<문제점> 이런식으로 AuthService가 싱글빈이라서 이렇게 카카오 웹 클라인트랑 네이버 웹 클라

OAuth 소셜로그인을 할 때, 이 카카오,네이버 회원이 우리의 서비스 회원인지 확인을 하고, 로그인시에 캐시에 발급한 랜덤 토큰값으로 저장해서 회원 정보 조회, 회원 정보 수정, 회원 삭제시에 이 유저가 맞는지 토큰값을 확인한다.처음에 이걸 개발 할 때, 어차피 회원

<문제점> 캐시를 사용해서 사용자가 로그인을 했을 때, 난수 값을 돌려줘서 사용자인지를 확인했다. (멤버 조회, 삭제, 변경시에 이 난수값으로 사용자인지 확인) 하지만, id가 1번인 사용자가 id가 2번인 사용자의 닉네임을 변경할 수 있는 것이었다. 캐시안에 있

원래 컨트롤러와 서비스에서 소통할 때, DTO로 소통을하고 DTO를 Entity로 바꾸기 전에 MemberModel을 둬서 Entity로 소통하는 것을 막았었다. 하지만, Social 테이블을 따로 두고

swagger로 확인할때 무한 조회를 하는 stackoverflow가 발생했다.Member와 SocialMember가 1:N 양방향 매핑을 해놓은 상태였다.이렇게 되니, Member의 List < SocialMember> 를 조회하면 SocailMember는 me

클라이언트가 id, pwd를 서버에보내고 서버는 id, pwd로 데이터베이스 값들이랑 비교하면서 맞는 값들인지 확인할 수 있다.http 프로토콜을 사용해서 통신을 하는데, http는 stateless한 상태이기 때문에 로그인 유지를 위해 쿠키와 세션이 필요하다. 즉,

시큐리티 설정 & UserDetails & UserDetailsService

시큐리티 OAuth (Oauth Client)를 사용할거면 redirect URL의 저 부분은 고정이다. 저기에 대한 컨트롤러 주소를 만들 필요가 없다는 뜻.@GetMapping("/login/oauth2/code/google")이런것을 안만들어도됨이 주소도 Oauth

스프링시큐리티는 자기만의 세션을 두고 있다. 원래 세션의 영역도 있다. 시큐리티 세션

JSON WEB TOKEN기본적으로 유저가 웹브라우저를 띄우고get 방식으로 www.naver.com으로 요청을보내면서버는 해당메서드에 맞는 것을 찾아서 html을 리턴해줌이때 헤더에다가 쿠키를 만들어서 보내줌, 쿠키 : session ID를 담아서 준다. 웹브라우저는

신뢰성있는 통신 : 내가 보낸 데이터가 잘갔는지 안갔는지 항상 확인함OSI 7계층을 알면 보안에대해서 알게되고, 이때 JWT가 왜 나왔는지도 이해할 수 있음. 응용계층 : 사진100장, 비밀번호프레젠테이션계층 : 압축, 암호화세센계층 : 인증체크 (상대방 컴퓨터에 접근

a가 b에게 어떤 문서를 보낼 때, c가 중간에 낚아챌 수 있다. 어떤 데이터를 보냈는지 알 수 있다. CIA!!c가 문서를 획득을 하면 : 기밀성이 깨짐, 새로운 문서를 만들어서 b에게 전송 (문서가 변경되면 무결성이 깨짐), b가 위조된 문서를 받으니까 가용성이 깨

Session 사용 (핑크) vs JWT 사용 (초록)