웹 프로그래밍 (63) 썸네일형 리스트형 스프링 시큐리티에서 뷰(View)에 대한 접근 설정 스프링 시큐리티 뷰(View)에 대한 접근 설정방법 이번 멋쟁이사자처럼 최종 프로젝트를 하면서 jwt 토큰을 이용해서 스프링 시큐리티 설정의 통해 REST Api 접근을 통제하는것이 가능했다. 일단 뷰는 모든 사용자가 접근하고 그후에 어떤 Get 요청이라든지 Post 요청이라든지는 아래와 같이 시큐리티의 requestMatchers를 설정하여 권한 설정이 가능했다. requestMatchers(HttpMethod.GET, "/something").hasRole("ADMIN") 이렇게 모든것이 잘풀린다고 생각했던 찰나 그럼 뷰는 어떻게 막는지에 대한 의문이 생겼다. 왜 이런 의문이 생겼나면 어드민만의 뷰가 존재했기 때문이다. 즉 다른 사용자는 사용할수 없는 페이지가 있는데 이곳은 어드민만 보이는 버튼을 통.. JPA 영속성 컨텍스트 JPA를 이해하는데 가장 중요한 용어 엔티티를 영구 저장하는 환경이라는뜻 EntityManager를 통해 영속성 컨텍스트에 접근 가능 디비와 애플리케이션의 중간에서 중개함 영속성 컨텍스트의 장점 1차 캐시(1차캐시에 저장돼서 같은 쿼리가 여러번 나가지 않음) 동일성 보장(1차캐시에서 꺼내오기때문에 동일) 트랜잭션을 지원하는 쓰기 지연(쓰기 지연 SQL에 모아두고 트랙잭션 단위에 쿼리를 한꺼번에 날림) 변경 감지(Dirty Checking: 1차 캐시에 저장할때 스냅샷을 찍어놓고 트랜잭션 커밋 시점(내부에서 flush 호출)에 만약 스냅샷과 엔티티가 다르다면 쓰기 지연 SQL에 업데이트 쿼리를 추가함) 지연 로딩(연관관계의 객체들은 필요할때 가져오도록함, 처음엔 프록시 객체로 끼워넣음) 변.. Querydsl JPQL의 단점 JPQL은 문자열을 사용해 개발자가 직접 쿼리를 작성 컴파일시에 오류를 잡아내기 어려움 동적쿼리 작성 어려움 Querydsl Querydsl은 데이터를 조회하는 여러 맥락에 대하여 같은 Java 코드로 데이터를 조회하는것을 목표로 함 자바 코드기 때문에 컴파일시 오류 검출 가능 조건으로 따로 추출하여 동적쿼리 작성이 유리 JPAQueryFactory JPQL을 빌더처럼 작성할수 있게 해주는 객체 JPA를 사용하기 때문에 EntityManager를 의존함 Spring Data JPA를 사용한다면 Bean 객체로 등록돼 있음 자세한 사용법 https://github.com/joshiaLee/Querydsl OAuth2 소셜 로그인 서비스의 회원가입 과정을 진행할 필요 없이, 제 3의 서비스에 등록된 회원정보를 활용하여 서비스에 로그인하는 기능 다른 서비스의 사용자 정보를 안전하게 위임받기 위한 표준 로그인을 대신 해주는 기술이 아님 어떤 서비스에 직접 인증 정보를 주지 않아도 나의 정보를 조회할수 있도록 권한을 위임하는 기술 정보를 조회할수 있는것이지 로그인은 상관없음, 즉 회원가입 처리나 로그인 처리는 비지니스 로직에 맡김 OAuth2 과정 사용자가 로그인 필요한 서비스 요청 사용자가 소셜 로그인 선택하면 Redirect 됨 (ex. 네이버, 카카오톡) 소셜 로그인 (ex. 네이버 로그인) 소셜 서비스 제공 화면(ex. 이 애플리케이션에게 정보를 제공하시겠습니까?) 인증 정보 제공을 선택하면 Access Token .. JWT JWT - JSON Web Token JSON으로 표현된 정보를 안전하게 주고받기 위한 Token의 일종 사용자 확인을 위한 인증 정보 위변조 확인이 용어(위변조가 어려움, 읽는거는 쉽다) 토큰 기반 인증 시스템에서 많이 활용(사실상 표준) header.payload.signature header: JWT의 부수적 정보 payload: JWT로 전달하고자 하는 정보가 담긴 부분 signature: JWT의 위변조 판단을 위한 부분 Token Based Authentication - 세션을 저장하지 않고 토큰의 소유를 통해 인증 판단 상태를 저장하지 않기 때문에 서버의 세션관리 필요 없음 토큰 소요가 곧 인증 -> 여러 서버에 걸쳐서 인증 가능 쿠키는 요청을 보낸 브라우저에 종속되지만(이동시킬수 없음), .. REST REST (Representational State Transfer) -Http를 이용한 서버를 구현할때 지켜야 하는 설계 원칙 -서버와 클라이언트 사이의 결합성(Coupling) 감소에 목표를 둠 -성능 향상 -확장성 확보 -사용 편의성 증대 사용자(클라이언트)는 데이터 표현의 상태(게시물 폼)를 전달을 하고 서버는 그 데이터 표현의 상태를 데이터 베이스라는곳에 저장한다. 1. 클라이언트 서버 Architecture -클라이언트와 서버의 역할 분리 -서버는 데이터가 어떤 방식으로 표현되는지 몰라도 됨 -클라이언트도 데이터가 어떻게 저장되는지 몰라도 됨(댓글 쓸때 게시글 article_id(FK)를 고려하지 않는다.) -양측의 독립적 발전을 추구 2. Stateless -클라이언트가 보내는 개별적인 요청.. 연관관계 편의 메서드 왜 연관관계 편의 메서드로 양쪽에 값을 모두 세팅해야 하는가? 1. 1차 캐시로 인해 쿼리가 안나가고 메모리상에서 바로 꺼내질수 있음 2. 테스트 케이스 작성시 JPA없이 작성해야 할때도 있기때문이다. public void setBoard(Board board) { // 기존 연관된 board가 있으면 제거 if (this.board != null) { this.board.getComments().remove(this); } // 새로운 board 설정 this.board = board; // 새로운 board가 있으면 해당 board에 현재 comment 추가 if (board != null) { board.getComments().add(this); } } 스프링 예외 처리 체크 예외와 인터페이스 서비스 계층은 순수하게 유지 리포지토리가 던지는 체크 예외를 런타임 예외로 전환해서 서비스계층에 던지면 됨 인터페이스를 도입 인터페이스의 구현체가 체크 예외를 던지려면, 인터페이스 메서드에 먼저 체크예외를 던지는 부분이 선언돼 있어야함 -> 인터페이스가 순수하지 못하고 종속적이게 됨 데이터 접근 예외 직접 만들기 리포지토리에서 아이디가 중복이라 예외를 서비스 계층에 던지면 서비스 계층은 복구를 시도 하려는데 이러면 또 서비스 계층이 특정 기술에 의존하게돼버림 -> 예외를 변환해서 던질것(직접만든 MyDuplicateKeyException) 이렇게 하더라도 개발자가 모든 오류코드에 대해서 일일이 잡아줘야함 그리고 데이터베이스 마다 다름 -> 스프링이 데이터 접근 계층에 대한 수십가지.. 이전 1 2 3 4 5 ··· 8 다음
