PengTory

스프링 시큐리티(Spring Security) 스프링 시큐리티는 스프링 기반의 애플리케이션의 보안(인증과 권한, 인가 등)을 담당하는 스프링 하위 프레임워크이다. 즉 인증(Authenticate) 과 인가(Authorize)를 담당하는 프레임워크를 뜻한다. 스프링 시큐리티에서는 주로 서블릿 필터(filter)와 이들로 구성된 필터체인으로의 구성된 위임모델을 사용한다. 그리고 보안과 관련해서 체계적으로 많은 옵션을 제공해주기 때문에 개발자 입장에서는 일일이 보안관련 로직을 작성하지 않아도 된다는 장점이 있다. [인증과 인가]- 접근주체 (Principal): 보호된 리소스에 접근하는 대상 - 인증(Authentication): 해당 사용자가 본인이 맞는지 확인하는 절차 - 인가(Authorize): 인증..

Java와 Spring을 공부하다보면 종종 JDBC, JPA 그리고 Hibernate라는 단어를 볼 수 있다. JDBC와 JPA는 모두 자바 프로그램 내에서 DB에 접속하기 위해 만들어진 API이다. 항상 추상적으로 알고 넘어가던 부분을 자세히 정리해볼까 한다. 두 개념에 대해 알기 전에 먼저 영속성(Persistence)에 대해 알고 시작하자. 영속성(Persistence) persistence의 뜻은 위 사진과 같다. 따라서 영속성은 단어 해석처럼 데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의특성을 말한다. 영속성을 갖지 않는 데이터는 메모리에서만 존재하기 때문에 프로그램이 종료되면 모두 사라지게 된다. 따라서 파일 시스템, 관계형 데이터베이스 혹은 객체 데이터베이스 등을 활용해 데이..

초 난감 예외처리 try{ // ... } catch(SQLException e){ } // 예외를 잡고 아무 것도 안함 -> 만들어선 안됨 try catch문을 써서 예외를 잡아낸 것은 좋지만 catch문 안에 아무것도 쓰지 않아 넘겨버리는 것은 위험하다. 왜냐하면 프로그램 실행 중 오류가 있어 예외가 발생했는데 이를 무시하고 계속 진행하기 때문이다. 그렇다면 cath문 안에 e.printStackTrace() 혹은 System.out.println(e)와 같이 메시지를 출력하는 방법은 어떨까? 잠깐 해결된 듯 보이지만 다른 로그나 메시지에 금방 묻혀 찾기 어려울 것이다. 그렇다면 정상적인 예외처리를 하기 위한 방법을 적어보겠다. 예외의 종류와 특징 자바에서 throw를 통해 발생시킬 수 있는 예외는 ..

JDBC try/ catch/ finally JDBC 수정 기능의 예외처리 코드 앞서 만든 UserDao 코드에서는 많은 점을 개선 했지만 아직 예외상황에 대한 처리가 없다는 문제점이 있다. 기존의 deleteAll() 코드를 보자. public void deleteAll() throws SQLException{ Connection c = dataSource.getConnection(); // 여기서 예외가 발생하면 바로 메소드 실행이 중단됨 PreparedStatement ps = c.prepareStatement("delete from users"); ps.executeUpdate(); ps.close(); c.close(); } 정상 처리가 된다면 메소드를 마치기 전 close() 를 호출해 리소드..

애플리케이션은 계속 변하고 복잡해져간다. 그 변화에 대응할 수 있는 첫 번째 전략이 앞서 블로그에 정리한 IoC/DI와 같은 기술이라면, 두 번째 전략은 만들어진 코드를 확신할 수 있게 해주고, 변화에 유연하게 대처할 수 있는 자신감을 주는 테스트 기술이다. UserDaoTest 지금까지 만들었던 main() 메소드로 작성된 테스트 코드를 살펴보자. public class UserDaoTest { public static void main(String[] args) throws ClassNotFoundException, SQLException{ ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml"); U..

스프링은 DaoFactory와 같은 자바 클래스를 이용하는 것 외에도, 다양한 방법을 통해 DI 의존관계 설정정보를 만들 수 있는데 가장 대표적인 것이 바로 XML이다. XML은 단순한 텍스트 파일이기 때문에 다루기 쉽고 컴파일과 같은 별도의 빌드 작업이 없다는 장점이 있다. 또한 환경이 달라져서 오브젝트의 관계가 바뀌는 경우에도 빠르게 변경사항을 반영할 수 있다. 스키마나 DTD를 이용해서 정해진 포맷을 따라 작성됐는지도 손쉽게 확인할 수 있다. XML 설정 스프링의 애플리케이션 컨텍스트는 XML에 담긴 DI 정보를 활용할 수 있다. DI 정보가 담긴 XML 파일은 를 루트 엘리먼트로 사용한다. 하나의 @Bean 메소드를 통해 얻을 수 있는 빈의 DI 정보는 아래 세 가지다. 빈의 이름: @Bean 메..

제어의 역전(IoC)과 의존관계 주입 IoC는 매우 느슨하게 정의돼서 폭넓게 사용되는 용어다. 따라서 스프링을 IoC 컨테이너라고만 해서는 스프링에 제공하는 기능의 특징을 명확하게 설명할 수 없다. 스프링이 제공하는 IoC 방식을 핵심을 짚어주는 의존관계 주입(Dependency Injection)라는, 좀더 의도가 명확히 드러나는 이름을 사용하기 시작했다. 런타임 의존관계 설정 의존관계 두 개의 클래스 또는 모듈이 의존관계에 있다고 말할 때는 항상 방향성을 부여해줘야한다. 의존한다는건 B가 변하면 A에 영향을 미친다는 뜻이다. A가 B에 의존하고 의존하고 있지만, 반대로 B는 A에 의존하지 않는다. 의존하지 않는다는 말은 B는 A의 변화에 영향을 받지 않는다는 뜻이다. 지금까지 작업해왔던 UserDao..

싱글톤 레지스트리로서의 애플리케이션 컨텍스트 애플리케이션 컨텍스트는 우리가 만들었던 오브젝트 팩토리와 비슷한 방식으로 동작하는 IoC 컨테이너다. 그러면서 동시에 이 애플리케이션 컨텍스트는 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이기도 하다. 서버 애플리케이션과 싱글톤 스프링이 주로 적용되는 대상이 자바 엔터프라이즈 기술을 사용하는 서버환경이기 때문에 스프링은 싱글톤으로 빈을 만드는 것이다. 만약 매번 클라이언트에서 요청이 올 때마다 각 로직을 담당하는 오브젝트를 새로 만들어서 사용한다고 생각해보자. 아무리 자바의 오브젝트 생성과 가비지 컬렉션의 성능이 좋아져도 서버가 감당하기 힘들다. 그래서 엔터프라이즈 분야에서는 서비스 오브젝트라는 개념을 일찍부터 사용해왔다. 서블릿 클래스당 하나의 오브젝트만 만..