웹 프로그래밍/스프링 (30) 썸네일형 리스트형 스프링 시큐리티에서 뷰(View)에 대한 접근 설정 스프링 시큐리티 뷰(View)에 대한 접근 설정방법 이번 멋쟁이사자처럼 최종 프로젝트를 하면서 jwt 토큰을 이용해서 스프링 시큐리티 설정의 통해 REST Api 접근을 통제하는것이 가능했다. 일단 뷰는 모든 사용자가 접근하고 그후에 어떤 Get 요청이라든지 Post 요청이라든지는 아래와 같이 시큐리티의 requestMatchers를 설정하여 권한 설정이 가능했다. requestMatchers(HttpMethod.GET, "/something").hasRole("ADMIN") 이렇게 모든것이 잘풀린다고 생각했던 찰나 그럼 뷰는 어떻게 막는지에 대한 의문이 생겼다. 왜 이런 의문이 생겼나면 어드민만의 뷰가 존재했기 때문이다. 즉 다른 사용자는 사용할수 없는 페이지가 있는데 이곳은 어드민만 보이는 버튼을 통.. 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 -클라이언트가 보내는 개별적인 요청.. 스프링 예외 처리 체크 예외와 인터페이스 서비스 계층은 순수하게 유지 리포지토리가 던지는 체크 예외를 런타임 예외로 전환해서 서비스계층에 던지면 됨 인터페이스를 도입 인터페이스의 구현체가 체크 예외를 던지려면, 인터페이스 메서드에 먼저 체크예외를 던지는 부분이 선언돼 있어야함 -> 인터페이스가 순수하지 못하고 종속적이게 됨 데이터 접근 예외 직접 만들기 리포지토리에서 아이디가 중복이라 예외를 서비스 계층에 던지면 서비스 계층은 복구를 시도 하려는데 이러면 또 서비스 계층이 특정 기술에 의존하게돼버림 -> 예외를 변환해서 던질것(직접만든 MyDuplicateKeyException) 이렇게 하더라도 개발자가 모든 오류코드에 대해서 일일이 잡아줘야함 그리고 데이터베이스 마다 다름 -> 스프링이 데이터 접근 계층에 대한 수십가지.. 자바 예외 이해 예외 계층 Error: 복구 불가능한 시스템 예외(그냥 둬야함) 애플리케이션 로직은 Exception부터 예외로 잡아야함 Exception: 체크 예외 -애플리케이션 로직에서 사용할수 있는 실직적인 최상위 예외 -Exception과 그 하위 예외는 모두 컴파일러가 체크하는 체크예외(단, RuntimeException 제외) RuntimeException: 언체크 예외, 런타임 예외 -컴파일러가 체크하지 않는 언체크 예외 -RuntimeException과 그자식 예외는 모두 언체크 예외 -RuntimeException과 그 하위 언체크 예외를 통상 런타임 예외라고 부름 예외 기본 규칙 1. 예외는 잡아서 처리하거나 던져야 함 2. 예외를 잡거나 던질때 지정한 예외 뿐만 아니라 그 예외의 자식들도 함께 처리.. 스프링 데이터 접근 핵심 원리 애플리케이션 서버와 DB 일반적인 사용법 1. 커넥션 연결: 주로 TCP/IP를 사용해서 커넥션을 연결 2. SQL 전달: 커넥션을 통해 DB에 SQL 전달 3. 결과 응답: DB는 SQL을 수행하고 결과를 응답, 애플리케이션 서버는 응답결과를 활용 과거에는 DB를 교체하면 애플리케이션 로직을 다 바꿔야했다(개발자는 모든 DB에 대한 로직을 알아야했음) -> JDBC(Java Database Connectivity) 표준 인터페이스(자바에서 데이터 베이스에 접솔할수 있도록 하는 자바 API) 등장 -> JDBC 드라이버는 Connection(연결), Statement(SQL 전달), ResultSet(결과 응답) 을 추상화하여 DB에 맞도록 구현해서 라이브러리를 제공함 -> 즉 DB에 맞는 드라이버만 갈.. 스프링 MVC(2) 검증 정리 메시지, 국제화 하드코딩을 일일이 바꿀려면 번거러움 -> 메시지 프로퍼티로 관리(messages.properties) 나라마다 다른언어로 뿌려줘야함 -> 국제화 타임리프의 메시지 표현식 #{...}을 사용하면 편리하게 스프링 메시지 조회 가능 -> #{label.item} 국제화 -> 스프링이 언어 선택시 Accept-Language 헤더값을 사용 -> messages_en.properties 파일을 만들어서 관리하면 홈페이지 언어 설정에 따라 자동으로 갈아낌 검증(Validation) 컨트롤러의 중요한 역할중 하나는 HTTP 요청이 정상인지 검증하는 것이다. 서버측에서 검증은 필수 th:if="${errors?.containsKey('globalError')}" ?문법: errors가 null일때 Nu.. 이전 1 2 3 4 다음
