comtK

제가 작성중에빼먹은 부분이 있었네요ㅠㅠ

다음 프로젝트 생성하고 셋팅하다가 발견했어요ㅠㅠ

<!-- 스프링 시큐리티 -->

<filter>

<filter-name>springSecurityFilterChain</filter-name>

<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>

</filter>

<filter-mapping>

<filter-name>springSecurityFilterChain</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

이거를 web.xml에 추가해주시면 됩니다ㅠ

</web-app> 안에다가요ㅠ  

안녕하세요 콤트입니다.

이번에는 MVC 패턴에 대해서 이야기해보겠습니다.

Model View Controller의 약자입니다.

어플리케이션을 크게 모델, 뷰, 컨트롤러로 구분하고, 결합도를 최소화 하는 패턴이라고 합니다.

각 부분들에 대해 이야기해보겠습니다.

모델은 어플리케이션의 비즈니스 로직 부분을 이야기합니다.

DB에서 데이터를 가져오고, 어플리케이션에 필요한 서비스를 수행하는 부분입니다.

뷰는 말그대로 사용자에게 보여지는 영역입니다.

JSP 파일이 주를 이룹니다. 모델에서 처리하여 보내진 정보를 보여주는 영역입니다.

컨트롤러는 모델과 뷰 사이에서 요청의 흐름을 컨트롤하는 부분입니다.

사용자의 요청을 받아들이면, 컨트롤러는 요청에 해당하는 비즈니스 로직을 호출하여 요청을 처리학나, 데이터를 가져오거나 처리하고, 결과를 뷰로 포워딩하여 사용자가 결과를 확인하게하는 기능을 합니다.

MVC 패턴에는 모델1과 모델2가 존재합니다.

각각의 모델에 대해서 알아봅시다.

* 용어설명

DTO : Data Transfer Object의 약자로 데이터를 담아 움직이는 객체를 뜻합니다.

사용자가 입력한 데이터(회원가입 정보, 로그인시 계정 및 패스워드 등등)나, 사용자가 요청한 데이터(게시판 목록, 게시글 내용 등등)을 담아서 흐름을 따라 움직입니다.

DAO : Data Access Object의 약자로 데이터를 저장하고있는 데이터베이스에 접근하는 객체입니다.

사용자가 요청한 데이터가 DTO에 담겨져서 넘어오면 DAO는 DTO에 있는 데이터들을 이용하여 DBMS에 쿼리를 날려서 데이터를 저장하거나, 가져옵니다. 

모델1은 컨트롤러 부분과 뷰 부분이 같이있다고 생각하시면 됩니다.

(이미지 출처 : http://blog.daum.net/gunsu0j/165)

위 이미지를 보시면 컨트롤러와 뷰가 같이 존재합니다.

사용자가 페이지에 접근하면, JSP 페이지 내에서 직접 비즈니스로직을 호출하여 요청을 처리하고 그 결과를 그대로 JSP페이지에 전달하여 사용자에게 보여지게 됩니다. JSP 페이지 내에서 스크립트릿(<% %>)으로 자바코드를 작성하여 비즈니스로직 클래스를 import하고, 메소드를 호출하여 나온 결과값을 그대로 처리한다고 생각하시면 됩니다.

* 장점

1. 개발 초기에 크게 설정이 필요가 없어 빠른 개발이 가능하다.

2. 복잡한 설정이 들어가지 않기떄문에, 접근이 용이하다.

* 단점

1. 컨트롤러와 뷰가 같이 묶여있어 병행작업이 힘들다.

ex) 페이지의 비즈니스로직 부분과, 뷰 부분에 수정사항이 생겼을 경우, 비즈니스로직과 뷰 부분이 같은파일에 있기 때문에 작업이 순차적으로 진행되어야한다.

만약 SVN이나 git을 이용하여 코드를 공유할 경우, 각자의 PC에 있는 파일로 작업한 후에 커밋을 하면, 충돌이 일어나서 코드를 정리해주어야 한다. 이를 막기위해선 한사람이 수정을 끝낸후에 커밋을 하면, 다음사람이 커밋내용을 업데이트 받아서 작업을 진행하여야 한다.

2. 자바 코드와, JSP & HTML 이 섞이기 때문에 코드가 복잡해진다.

모델2는 모델1에서 뷰와 컨트롤러가 나뉘었다고 생각하시면 됩니다.

(이미지 출처 : http://blog.daum.net/gunsu0j/165)

모델1 이미지와 거의 비슷하지만, 컨트롤러와 뷰가 분리되어있는것을 볼 수 있습니다.

모델2로 작업을 진행할 경우 모델1에서 복잡했던 코드는 한층 간결해집니다. 사용자의 요청을 컨트롤러가 받아서 비즈니스로직을 호출한 후에, 처리된 결과를 컨트롤러가 뷰로 포워딩해줍니다. 이로서 뷰는 넘겨받은 결과에 대한 화면을 보여주기만 하면 됩니다.

* 장점

1. 모델1에 비해서 코드가 한결 간결해진다.

2. 분리된 코드로 인하여 유지보수가 편해진다.

3. 확장이 용이하다.

* 단점

1. 개발 초기에 설정이 필요한 부분이 모델1보다는 많기때문에 실질적인 작업이 들어가기까지 시간이 걸린다.

2. 개발자가 모델2 아키텍쳐에 대한 이해가 필요하다.

(모델1 역시 이해가 필요하지만, 그보다 더 수준높은 이해를 필요로 한다.)

3. 코드가 분리되면서 관리해야할 파일이 많아진다.

음... 어... 이어쓴다그러고 한달이 지났네요..ㅠ 게을러서 죄송합니다ㅠ

주말되면 그렇게 쉬고싶더라구요ㅠㅠ

변명좀 하자면 운동도 좀 하고 그러면 그냥 쉬고싶어서..ㅠㅠ

바로 시작하겠습니다ㅠ

이전내용 : http://comtk.tistory.com/20

잠시 이전에 올려두었던 'security-context.xml'을 보고가겠습니다.

오늘은 여기서 ●이 있는 파일들만 설명드리겠습니다.

이전글에 전체 파일들에 ●들이 막 찍혀있는건 그파일들을 손댔다는뜻인데, http://comtk.tistory.com/10 이 글에 있는 내용의 작업들을 한겁니다. DB가서 데이터 가져오는 작업을 한것이죠. 어떤작업을 한것인지는 설명드리겠습니다.

위 이미지에서 맨 아래부분을 확대해보겠습니다.

위 이미지를 보시면 'authentication-provider' 를 보시면 'customizeUserDetailsService' 라고 되어있습니다.

권한에 대한 처리를 'customizeUserDetailsService'에서 제공받는다는 의미로 생각됩니다.

첫번째 ●을 보시면 'loginAction 구현' 이라는 주석이 달려있습니다.

저 클래스에서 권한과 로그인에 대한 부분을 같이 처리하고있습니다.

해당 클래스의 내용을 확인해보겠습니다.

위에서부터 차근차근 설명해보겠습니다.

이 클래스는 'UserDetailsService'를 상속받아서 만들어야 합니다.

네 그래야만 해요. 그래야지 저대로 쓸수있어요. 따로 설정을 해주지않으면 스프링은 저 클래스를 사용해서 권한 및 로그인에 대한 처리를 한다고 알고있습니다. 그래서 클래스를 상속받아서 메소드를 입맞에 맛게 오버라이딩 한 후에 사용해야 합니다.

그 다음으로 변수들을 보겠습니다.

이 변수들은 사실 꼭 필요한것은 아니지만.. 잠시후에 계정의 권한을 위해서 만들어둔 변수들입니다.

위에서부터 하나씩 설명하지면 '사용 가능한지', '계정이 만료되지 않았는지', '자격이 만료되지 않았는지', '계정이 잠기지 않았는지' 체크하는 변수들입니다.

그 다음줄은 사용자가 입력한 계정명으로 해당 계정을 찾아서 가져옵니다.

그 아랫줄에서는 그 계정에 대한 상태를 가져와서 if문에서 하나하나 비교해서 상태에 맞게 계정정보를 설정해줍니다.

다음줄로 넘어가겠습니다.

저는 권한을 DB에 저장하여 사용하고있습니다.

DB에서 권한목록을 가져와서 권한을 추가해줍니다. 위 이미지에서 가지고있는 권한중에 'Anonymous'가 있을경우, 권한목록을 따로 생성하지않는것을 볼 수 있습니다. 이는 위 내용은 손님이 아닌 그 이상의 권한을 가진 사람들에 대한 권한처리를 위해 작성된 것임을 알려드립니다. 각 프로젝트의 특성에 맞게 권한을 부여해주시는것이 바람직합니다.

이제 설정한 권한 및 계정상태를 member에 담아서 리턴해줍니다.

이 과정이 끝나면 로그인이 되거나, 로그인에 실패하거나 둘중 하나의 상황을 맞이하게 됩니다.

먼저 성공했을때의 상황을 보겠습니다.

맨 위 이미지에서 두번째 ●에 해당하는 클래스입니다.

로그인이 성공했을 경우를 보여줍니다.

이 클래스 역시 다른 클래스를 상속받아서 사용합니다.

저는 로그에 '성공' 이라는 텍스트를 찍고 메인페이지로 이동하도록 작업했습니다.

맨 위 이미지에서 세번째 ●에 해당하는 클래스입니다.

로그인이 살패했을 경우를 보여줍니다.

이 클래스 역시 다른 클래스를 상속받아서 사용합니다.

저는 로그에 '실패' 라는 텍스트를 찍고, 어떤이유로 로그인에 실패했는지 로그를 남깁니다.

이후 페이지는 다시 로그인페이지로 이동합니다.

이부분은 따로 파일을 만들지 않고 기본 스프링 인코더를 사용했습니다.

그러나, 따로 암호화 모듈을 사용하여 사용하셔도 됩니다.

'class'부분을 수정하여 사용하시면 됩니다.

자 이제, 로그인 및 계정에 대한 권한설정 부분을 하였습니다.

그럼 이제 권한을 사용하여야 하는데... 어떻게 사용할까요...

손님이 접근가능한 부분과, 관리자가 접근가능한부분등 각 권한에 따라 접근 및 행동에 제약이 있어야지, 그렇지않으면 권한이 의미가 없습니다.

●을 보시면 '@secured("ROLE_USER")'가 보이실겁니다.

이 한줄로 사용자의 접근을 통제할 수 있습니다.

위 이미지처럼 메소드 위에 써놓으면 해당 메소드는 저 권한이 있는 사용자만 접근이 가능하게 됩니다.

그러나, 메서드별로 해놓으경우 각 메소드마다 다 써줘야하는 번거로움이 있습니다.

class 위에 적어놓으시면 클래스 내의 모든 메소드는 선언되어있는 권한이 있는 사용자만 접근 가능합니다.

그렇기때문에 권한 및 기능별로 클래스를 잘 나누어 사용하는것이 좋습니다.

그럼 한줄만 추가 및 수정하는것으로 사용자의 접근을 통제 가능하게 됩니다.

이외에도 여러가지 설정이 더 있겠지만, 이정도면 기본적인 로그인 및 권한, 접근제어등에 대해서 사용이 가능하다고 생각됩니다. 혹시 내용중에 틀린부분이 있다면 지적해주시면 감사하겠습니다. 그래야 저도 더 공부가 되니까요!!

다음번엔 무엇을 해볼까요.. 뭔가 더 있을텐데... 아참 스프링 4.0이 나왔다는데 그것도 날잡아서 시작해봐야겠어요!!

다른 카테고리도 글을 써야하는데 참... 할게많네요ㅠ 어 어떻게 마무리를 하지.. 음.. 다음에 또 봐요!!