인증이 되어있지 않은 사용자는 스프링 시큐리티의 필터링에 걸려 로그인 페이지로 향하게 된다. 나의 경우 처음에는 로그인을 성공했을 때 핸들러를 통해(SimpleUrlAuthenticationSuccessHandler를 상속받아 작성) 메인페이지로 돌아가게끔 URL을 지정하였다.


그렇다면 메인페이지말고 내가 로그인 페이지로 넘어가기전에 요청했었던 url로 넘어가고 싶다면 어떻게 해야 할까?


보통 다른 방법들을 찾아보았을 때 login페이지 컨트롤러에서 Session 값을 넣거나 하는 작업을 하는 것들을 보았는데, 사실 우리는 그럴필요가 없다. 



레퍼런스에서 발견한 내용인데 두번째 문단을 읽어보면 인증전의 요청을 세션에 저장하고 있다고 얘기한다.

그리고 세션에 저장되어 있는 속성의 이름은 SPRING_SECURITY_SAVED_REQUEST 이다. 그렇다면 이제 로그인을 성공했을 때 핸들러에서는 다음과 같이 작업을 하면 될것이다.




또 다른 방법으로는 위의 글에서 언급한바와 같이 핸들러를 작성할 때 SavedRequestAwareAuthenticationSuccessHandler

를 상속받아 사용할수도 있는 것 같다.




스프링 MVC 기본 흐름과 주요 컴포넌트



스프링 MVC는 여러 가지의 컴포넌트로 구성되어 있으며 흐름은 다음과 같고 역할은 밑에 표로 정리하였다.



 구성 요소

설명 

 DispatcherServlet

요청 받음, 컨트롤러에게 요청 전달, 결과값을 view에 전달한다. 

HandlerMapping

URL을 통해 어떤 컨트롤러가 이를 처리할지를 결정

 HandlerAdapter

요청을 변환하여 컨트롤러에게 전달. 컨트롤러로부터 받은 결과를 다시 리턴. 웹 브라우저 캐시 등의 설정도 담당 

Controller 

전달 받은 요청을 처리한 뒤, 결과 리턴. View에 보여줄 데이터들을 모델에 담아 전달 

 ViewResolver

뷰를 결정한다. 

View

데이터들을 Html에 삽입 


[참고 자료 : 웹 개발자를 위한 Spring 4.0 프로그래밍 - 최범균]



1. 의존 객체를 직접 생성하는 방식



아래와 같은 객체를 생성해야 한다는 가정을 들어보자.


new A( new B);


이렇게 의존 객체를 직접 생성하는 방식을 사용하게 되었을 때 내용은 아래 사진과 같이 되게 된다.




이렇게 구성되어 있을 때 만약 A가 생성할 때 B가 아닌 C를 참조해야 한다고 할 때, 다음과 같이 작성했던 모든 클래스들에 대해서 코드를 고쳐야 하는 상황이 온다.




2. 의존 객체를 외부에서 조립하여 내리는 방식



의존 객체를 직접 생성하는 방식과 달리 Dependency Injection는 의존 객체를 외부로부터 전달받는 구현 방식이다.



이 경우 A가 B가 아닌 C를 참조하게 되었을 때는 이를 정의하고 있는 파일만 고쳐주게 되면 된다는 것이다.



지금 설명할 때에는 3개의 클래스만 영향을 받기 때문에 직접 구현하는 것도 나쁘지 않다 생각할 수 있지만, 이를 몇 십개 이상의 파일을 직접 찾아 고친다고 생각하고 다시 한번 생각해보자. 

ASM ClassReader failed to parse class file - probably due to a new Java class file version that isn't supported yet:




대충 에러 내용이 ASM ClassReader가 버전이 달라서 읽을 수 없다고 하는 내용입니다.


람다를 사용하기 위해 1.8로 변경했는데 Spring의 버전이 낮아서 생긴 에러입니다.


출처 : https://spring.io/blog/2014/03/27/spring-framework-4-0-3-released-with-java-8-support-now-production-ready

스프링이란?



스프링이란?

=자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크.


정의)


프레임워크 = 소프트웨어를 만드는 데 기본이 되는 골격 코드, 완전한 애플리케이션이 아니며 확장 또는 구현하여 완전한 애플리케이션으로 완성이 된다.  예시 ) EJB , Spring


스프링의 주요 전략


1. POJO를 이용한 가볍고 비침투적 개발

2. DI와 인터페이스 지향을 통한 느슨한 결합도

3. Aspect와 공통 규약을 통한 프로그래밍

4. Aspect와 템플릿을 통한 반복적이고 상투적인 코드 제거


핵심은 응집도를 높이고 결합도를 낮추는 것.


스프링 배우기 전 개념들


1. EJB (Enterprise Java Bean)


자바빈 ?

=  컴포넌트 기반의 소프트웨어 모델 스펙, 자바 객체를 재사용 가능하게 컴포넌트화 시킬 수 있는 코딩 방침을 정의. 


엔터프라이즈 자바 빈 ?

=  보안 , 트랜잭션 지원, 분산 컴퓨팅 등의 엔터프라이즈 어플리케이션 개발 시 필요한 다양한 서비스를 컨테이너에서 제공하며 개발자는  비즈니스 로직에 전념하도록 지원. 하지만 스펙 자체가 복잡하여 사용하기 힘들고, EJB 컨테이너가 없을 경우 사용이 불가능하며, 컨테이너가 변경될 경우 호환이 어렵다는 단점이 있음.



2. POJO

어떠한 제한에도 묶이지 않은 단순 자바 오브젝트





Spring Container




Container = EJB의 비즈니스 서비스 컨테이너의 기능은 유지하되 복잡성을 제거하고 객체들의 라이프사이클을 관리


1. Spring Container


- Spring Framework에서 Container 기능을 제공

- Spring Framework를 초기화 하는 역할

- XML에 등록된 Bean들의 라이프 사이클/ 의존 관리 담당



2. Inversion of Control/Dependency Injection (제어 역전/ 의존 주입)

 

IoC = 프로그램 코드에서 직접 객체를 생성하지 않고, 외부(컨테이너)에서 빈(Bean)을 생성하고 제공한다는 개념.


IoC의 구현 방법 2가지

  1. Dependency Lookup (DL)
    DL는 클라이언트가 컨테이너에서 생성한 객체를 검색하여 사용하는 방식

  2. Dependency Injection (DI)
    DI는 컨테이너가 자동으로 처리 수행

DL의 경우 Lookup을 하기 위한 코드를 구현해야 되지만, DI의 경우 컨테이너가 직접 Lookup을 수행하므로 DL만큼의 코드를 필요로 하지 않는다.



AOP(Aspect Oriented Programming) - 관점 지향 프로그래밍


코드에서 핵심 로직(비즈니스 로직)과 그 외의 로직(공통 관심 사항)을 분리시키고, 공통 관심 사항을 구현한 코드를 핵심 로직을 구현한 코드 안에 삽입하는 것이다.


공통 기능이란 주로 트랜잭션 적용이나 보안 검사, 로그를 남기는 것과 같은 코드를 말한다.


아래와 같이 공통 기능들이 있을 때 코드는 다음과 같이 만들어질 것이다. 이렇게 되면 핵심 로직외에도 많은 코드들이 들어가야 할테고, 공통 로직에 변경이 생기면 이를 구현하고 있는 많은 클래스에서 변경이 일어날 것이다.



이를 aop의 개념으로 이용하면 다음과 같이 핵심 로직과 공통 기능을 분리시킬 수 있으며, 이를 변경함에도 쉽고, 쉽게 로직에 추가할 수도 있다. 


 




https://jojoldu.tistory.com/129?category=635883 님의 Validation을 통한 유효성을 체크하는 글을 따라해보다 뭔가 느낌이 뽝 와서 적어봅니다.


일단 최조 Valid(여기서는 MemberRequestDto에 validation을 작성.)를 통해 걸러지게(?) 되면 



다음과 같은 에러를 보게 된다.


Valid를 통해서 에러를 내리는 법도 있지만, 중복 검사와 같이 어떤 작업을 거치고 에러를 내리는 것은 불가능하기 때문에 Exception을 만들고 내려야한다. 그러기 위해서는 새로운 Exception을 만들어보자.


내가 원하는 그림은 위와 같이 이메일을 중복 검사하여 중복이 되면 해당 에러를 valid에서 내린 에러와 같이 내리되 필요한 default message와 field 부분만 따로 Error클래스로 만들어 내리는 것이다.

 

코드를 보면 클래스위에 어노테이션에 해당 예외 클래스는 어떤 상태를 내릴 것인지 결정을 하고, RuntimeException을 상속받아 원하는 부분을 작성하기 시작하면 된다. 



Exception을 만들었다면 기존의 에러를 내릴 때 사용하는 클래스에 새로 만든 Exception의 에러를 추가해준 후 내려야 한다. 빈을 등록해보자


 

이렇게 기존에 getErrorAttributes에 현재 내리는 Exception종류가 ValidCustomException일 때 속성을 추가해주고 필요할 때 예외를 던지면 된다.







csrf.pdf


정리한 파일입니다.

+ Recent posts