# Date의 흐름
Model을 하는 부분에 대해서는 한가지만은 확실히 나올 수 있습니다. \
\
"각자의 영역으로 분리"\
\
이것은 DB를 다루는 Model 뿐 아니라, \
모든 객체와 개발에서의 Layer가 지켜야지 되는 원칙이라고 할 수 있습니다. \
일반적으로 우리가 사용한 Model은 다음과 같은 package로 나뉠 수 있습니다. \
\
com.......entities\
com........vo\
com........dto\
com........dao\
com........repositories\
com........services\
\
구성될 수 있는 package에 대해서 다시 정리하고,\
최종적인 web application의 데이터의 흐름에 대해서 알아보도록 하겠습니다. \
\
**Packages**\
\
**entities package**\
Hibernate와 같은 ORM framework를 사용하는 경우, object와 persistence model간의 관계를 구성한 ORM 객체가 위치하는 영역입니다. 또는 Table에 1:1 mapping을 해서 구성하는 경우도 있습니다. 그렇지만, entities를 사용한다는 것은 기본적으로 DDD를 사용하는 것과 동일합니다. 객체과 그 객체의 관계에 대한 구성을 코드에 녹여내는 방식을 주로 사용하게 됩니다. \
\
**vo package / dto package**\
vo(value object), dto(data transfer object)의 경우에는 일반적으로 persistence model에서 넘어오는 값들을 단순 parsing할 때 사용됩니다. 여기에 가장 대표적인 기술로 mybatis를 소개하였고, 이는 db에서 얻어오는 값을 view에서 단순 표시하기 위한 방법으로도 자주 사용하게 됩니다. 이 두 package는 myBatis를 Domain Layer의 Framework로 사용하는 경우에는 거의 필수로 사용됩니다. 또는 개발시에 Model 영역에서 Controller/View 로 데이터를 넘길때, DTO 객체를 만들어서 넘길때 사용되기도 합니다. 이때는 vo가 View Object의 의미로 사용되기도 합니다.\
\
**dao**\
직접 DB에 query를 보내고, entity, vo, dto를 얻어오는 영역입니다. DB를 사용하는 기술에 따라 다르게 구성이 되는 것이 일반적이며, CRUD에 대한 모음으로도 구성될 수 있습니다. 단순 CRUD가 이루어진다고 해도, DB에 대한 기술적 영역이 바뀌게 될 가능성은 항상 열어두고 작업을 하는 것이 좋을 것 같습니다. 그렇기 위해서는 interface로 정의된 dao를 사용하는 것이 보다더 효과적으로 구성이 가능하게 됩니다. dao로 지정하게 되는 것은 controller, domain 모두에서 dao를 사용하겠다는 의미입니다. Hibernate와 같은 ORM을 사용하는 경우에는 repository pattern으로 접근하는 것이 더 좋습니다.\
\
**repositories**\
Repository는 Dao와 매우 유사한 개념입니다. 이 두 용어의 차이점은 기능이 아닌, 사용되는 코드의 위치입니다. Domain Layer에서만 사용되는 경우에는 repository, Domain뿐 아니라 모든 영역에서 사용된다면 dao로 개발하게 됩니다. 이 둘의 차이는 Model을 풀어가는 pattern의 차이입니다. 보다더 pattern 상위적인 개념이 Repository이고, Dao는 database 적 개념이 강한 Object라고 생각하면 좀 더 이해가 쉬울 것 같습니다. \
\
**services**\
business logic 영역입니다. 여러개의 dao object들과 entity 또는 vo/dto object들을 얻어내고, 그 객체들간의 로직이 구성되는 영역입니다. 일반적으로 transaction의 단위 영역이 된다는 것을 명심해주세요. 위의 구성에서 결국은 model은 3개 이상의 package로 구성이 됨을 알 수 있습니다. 남의 코드를 보더라도 대부분 위와 비슷한 구성으로 package가 구성된 경우가 많으니 참고바랍니다. \
**Domain Framework의 비교**\
\
다음은 지금까지 알아본 Model을 접근하는 Framework의 조합에 대해서 한번 정리해보도록 하겠습니다.
| Framework | 특징 | 장점 | 단점 |
| -------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| No Framework - PreparedStatement 를 이용하는 방법 | 1. Native Query 구성 | 1. native query를 이용한 학습 시간의 단축 | 1. 오타가 발생하는 경우, query를 실행하기 전까지 에러를 확인할 수 없다.
2. 중복 코드가 많이 발생된다.
3. connection의 관리를 비롯한 Transaction의 처리를 모두 수동으로 해줘야지 된다.
4. java 코드에 sql 코드가 들어가기 때문에 관리 및 debug가 힘들다.
|
| JdbcTemplate | 1. Spring JdbcTemplate 이용
2. DataSource 이용
3. Native Query
| 1. native query를 이용한 학습 시간의 단축
2. connection 관리
3. Transaction 관리
| 1. 오타가 발생한 경우, query를 실행하기 전까지 에러를 확인할 수 없다.
2. 중복 코드가 많이 발생된다.
3. java 코드에 sql 코드가 들어가기 때문에 관리 및 debug가 힘들다.
|
| Hibernate | 1. HQL, Criteria
2. DataSource
3. Spring Transaction
| 1. 다양한 reference
2. 객체를 이용한 query의 처리로 인하여, 코드양을 줄일 수 있다.
3. 프로그램 설계 및 구성 부분에 대해서 장점을 갖는다. (DDD와 같은 객체 지향적 구성 가능)
4. Table의 변경 또는 DB의 변경에 유연한 장점을 갖고 있다.
5. 동적 query가 자유스럽다.
| 1. 학습 시간의 소요
2. criteria, HQL 모두 오타에 취약한 구조
3. 단순 CRUD에 대한 코드양 증가 - 1, 2번 항목 보다는 코드 양이 적다.
|
| Hibernate + queryDSL | 1. JQL, Criteria
2. DataSource
3. type-safe
4. code generate
| 1. 다양한 reference
2. 객체를 이용한 query의 처리로 인하여, 코드양을 줄일 수 있다.
3. 프로그램 설계 및 구성 부분에 대해서 장점을 갖는다. (DDD와 같은 객체 지향적 구성 가능)
4. Table의 변경 또는 DB의 변경에 유연한 장점을 갖고 있다.5. 오타가 발생할 수 없는 type-safe 한 query를 작성할 수 있다.6. sql query와 비슷한 문법으로, 학습에 도움을 줄 수 있다.
| 1. 학습시간의 소요
2. 단순 CRUD에 대한 코드양 증가
2. 설정이 까다롭다.
|
| Hibernate + JPA + queryDSL + Spring Data JPA | 1. JQL, Criteria
2. DataSource
3. type-safe4. code generate
| 1. JPA - java 표준
2. 객체를 이용한 query의 처리로 인하여, 코드양을 줄일 수 있다.
3. 프로그램 설계 및 구성 부분에 대해서 장점을 갖는다. (DDD와 같은 객체 지향적 구성 가능)
4. Table의 변경 또는 DB의 변경에 유연한 장점을 갖고 있다.5. 오타가 발생할 수 없는 type-safe 한 query를 작성할 수 있다.6. sql query와 비슷한 문법으로, 학습에 도움을 줄 수 있다.7. CUD, select 문의 코딩양이 현격하게 줄어든다.8. Hibernate 코드 역시 사용 가능하고 유연한 방법으로 대처가 가능하다.9. Repository Interface code에 의한 가독성 향상10. Spring @MVC의 @InitBinder와의 연동이 가능하기 때문에, Converter를 작성하는 시간을 줄일 수 있다.
| 1. 학습 시간의 소요
2. 설정이 까다롭다.
3. repository 객체를 두개를 만드는 것이 필요하다. (repository, repositorysupport)
|
| myBatis (iBatis) | 1. Native Query
2. DataSource
3. ibatis-spring 이용
| 1. 국내의 많은 사용자
2. sql query의 관리를 하는 것이 가능하다.
| 1. 객체가 아닌 VO type의 이용으로 인한, 프로그램 architecture의 발전 가능성이 낮아짐
2. java 언어 뿐 아니라, sql 로의 확장으로 인하여 관리 코드가 늘어남
|
\
지금 전 이정도로 정리를 해봤는데, 다른 분들은 어떻게 정리를 할 수 있을까요? 각 방법에 대한 장/단점을 파악하는 것이 중요합니다. 적어도 이곳에 있는 분들만이라도요.그리고, 만약에 외부 Project에 참여하게 되는 경우에는, 그 Project에 맞는 개발 방법을 이용해서 개발을 하는 것이 중요합니다.\
\
\
**Web Application에서의 데이터의 흐름** \
Domain Model을 이용해서 Web Application을 구성하는 방법은 두가지가 있습니다. 원칙을 지키고자 하는 Pure Domain Model과 Domain Model의 자유로운 사용이 특징인 Domain Model Everywhere입니다. 먼저 Domain Model Everywhere에 대해서 알아보도록 하겠습니다. \
**Domain Model Everywhere**
\
\
\
Repository, Service, Controller, View가 모두 Entity Model을 가지고 동작하는 방식입니다. 이 방식은 Domain의 Entity 객체가 Repository 뿐 아니라, Controller, View에 표현되는 방법까지 가지게 되게 됩니다. 이렇게 되면 Entity Model이 매우 커지게 됩니다. 그리고 객체의 "단일책임원칙"을 위반하게 되는 단점을 가지고 있습니다. 이 방법의 장단은 다음과 같습니다. \
장점 :# 개발하기에 빠르고 편리함\
단점 : # 복잡한 View의 표현이 매우 힘듭니다.# Domain Model에서 View Logic이 포함되기 때문에 Domain Model의 순수성이 떨어지고 객체의 단일 책임원칙을 위반하게 됩니다.# REST 서버와 같이 외부와의 통신 API에 사용하게 되는 경우에는 Domain Model이 변경되면 API가 바뀌게 되기 때문에 큰 문제를 야기할 수 있습니다.\
장점보다는 단점이 좀더 많아보입니다. 보시면 전에 제가 .NET으로 만든 mobile framework가 바로 이 모습입니다. 원칙상으로는 다음 방법을 더 권장하는 편입니다. \
\
**Pure Domain Model**\
.png)\
Domain Model은 서비스와 Repository에서만 사용하고, Controller와 View에서는 DTO를 새로 만들어서 사용하는 방법입니다. 이는 Domain의 순수성을 지키게 되는 큰 장점을 가지고 있습니다. View에서만 DTO를 사용하는 것이 BL의 변화에 따른 View의 변경을 격리할 수 있는 좋은 방법이 됩니다. \
장점 : # 순수한 Domain Model - 객체지향적인 OOP 모델\
단점# DTO를 따로 만드는 것이 귀찮고, 성가시고, 괴롭다.# DTO는 또 다른 중복 코드를 만들어낸다. # DTO와 Domain Model간의 Convert를 따로 만들어줘야지 된다. # anti-pattern 중 하나입니다. 사용하지 않아야지 된다고들 이야기합니다.\
Domain Model Everywhere pattern의 경우에는 anti-pattern이라고도 말하는 사람이 있을정도로 호불호가 매우 강하게 갈리는 pattern중 하나입니다. 개인적으로도 최대한 Pure Domain Model을 이용해서 개발하는 것이 좋다고 생각합니다. \
\
\
지금까지 개발을 해본 결과. 다음과 같은 상황에서는 반드시 DTO를 사용해야지 됩니다. \
1\. REST 서버와 같은 API의 response.: Domain Model은 자주 바뀔 수 있습니다. 그렇지만, client와 통신을 하게 되는 API의 response는 바뀌면 문제가 생기게 됩니다. 따라서 이 둘은 반드시 분리를 해야지 됩니다.\
2\. 여러 Domain Model이 결합되어서 만들어지는 새로운 View에 대한 DTO: View가 너무너무나 복잡해서 서로간에 연관성이 없는 Domain Model을 response로 보내줘야지 되는 경우에는 DTO를 만드는 것이 좋습니다. \
이 두가지 경우를 제외하고..... DTO를 모두 만드는 것은 다음과 같은 문제가 발생합니다. \
1\. 객체가 너무 많이 만들어집니다. 지금 DataWindow의 package와 같이 각 SP의 숫자만큼의 package같이 객체들이 구성되게 됩니다. 이는 객체의 naming rule 및 관리가 매우 힘들어지는 결과를 가지고 옵니다.2. 많이 만들어진 객체 숫자 만큼의 Converter가 필요합니다. Domain Model을 DTO로 바꿔주고 DTO를 Domain Model로 바꿔주는 Convert 숫자가 필요하게 됩니다.3. 위 이유로 관리 포인트가 3개로 늘어나게 됩니다. - Domain Model, DTO, Converter\
\>> 배보다 배꼽이 더 큰 사태가 발생할 수 있습니다. Domain Model Everywhere가 절대로 좋은 것은 아닙니다. 그렇지만 개발 시간과 관리 포인트를 생각해서 Domain Model Everywhere로 만들고, 그 객체들을 차츰차츰 DTO로 변환시켜가는 과정이 Application을 더욱더 깔끔하게 만드는 과정이 되게 된다고 생각합니다.\
\
결론입니다. \
\# 처음에는 Domain Model Everywhere로 Project를 시작합니다.# Domain Model로 처리하기 힘든 경우에는 DTO를 사용해서 객체의 변환을 합니다.# 최대한 Pure Domain Model을 유지하기 위해서 계속 노력합니다.\
\* Domain Model Everywhere를 지원하기 위해서 Spring은 JPA Model Object를 위한 OpenEntityManagerInViewFilter와 Hibernate를 위한 OpenSessionInViewFilter를 지원하고 있습니다. \
\
출처: [https://netframework.tistory.com/entry/16-Model-기술-정리-및-비교](https://netframework.tistory.com/entry/16-Model-%EA%B8%B0%EC%88%A0-%EC%A0%95%EB%A6%AC-%EB%B0%8F-%EB%B9%84%EA%B5%90) \[Programming is Fun]
# Session 관리
# Storage
# localStorage/sessionStorage 클라이언트에 정보 저장
웹에서 데이터를 저장하는 방법 중 **서버가 아닌 클라이언트에서 가능한 방법**을 알아보려고 합니다.
웹사이트의 정보를 저장하기 위해서 반드시 서버가 필요한 것은 아닙니다. 사용 목적에 따라 클라이언트 저장소 역시 좋은 역할을 할 수 있습니다. 일반적으로 클라이언트 저장소를 생각하면 가장 먼저 쿠기 저장소를 떠올리겠지만 html5에는 좀 더 효과적인 클라이언트 저장 공간을 제공하는데 어떤 것이 있는지 알아보면 다음과 같죠.
! localStorage, sessionStorage API 알아보기\
html5에서는 좀 더 쉽고 간단한 저장소 제공을 위해 새로운 localStorage와 sessionStorage API를 제공합니다. 둘 다 저장 공간으로 사용할 수 있는데 이 둘의 가장 큰 차이점이라면 저장소로서의 기능은 대부분 동일하며 단지 sessionStorage의 경우 세션이 종료되면 저장된 데이터도 함께 사라진 다는 점이 다른 점입니다. 그렇다면 이 메소드는 어떤 경우에 사용할 수 있을까요? 쿠키를 포함해 서로의 장단점에 대하여 비교하며 알아보도록 하겠습니다.
## **# 쿠키, 서버 저장소, localStorage, sessionStorage 차이점 및 장단점**
쿠키의 경우 저장 가능한 공간의 크기가 가장 작고 하나의 텍스트 형태로 저장된다. 그렇기 때문에 비교적 간단한 텍스트 타입의 데이터를 저장하는데 용이하다. 이런 값으로는 팝업의 이름을 예로 들 수 있다. 팝업의 경우 24시간 동안 동작하지 않도록... 즉 열지 않도록 설정하는 경우가 많은데 이때 쿠키의 변수를 저장하고 24시간의 만료시간을 설정하는 것이 좋다.
서버저장소는 데이터의 동기화가 필요하기 때문에 꼭 필요한 경우가 아니라면 전송을 최소하 하는 것이 좋을 것이다. 이런 이유로 서버 저장소는 데이터의 크기가 매우 크거나 반드시 저장해야 하는 경우에만 사용된다.
데이터가 크기나 만료시간을 고려했을때 위 저장소의 중간 정도의 애매한 경우가 있을 수 있다. 저장소가 필요하지만 다수의 컬럼이 필요한 경우가 아니만 단순한 형태라면 localStorage, sessionStorage를 사용하는게 효과적인 방법이다.
#### **! localStorage, sessionStorage를 어떤 경우에 사용할까**
대부분의 데이터의 경우 데이터베이스에 저장하므로 로컬 및 세션 스토리지가 사용되는 곳은 그리 많지 않다. 대부분 임시적인 용도 또는 캐시, history 기능을 위하여 사용된다. 아래의 경우가 그 예이다.
* 글 작성 중간 중간에 잃어버리지 않기 위한 임시 저장용도
* 장바구니나 좋아하는 콘텐츠 등 수시로 변경되는 경우
* 방문자의 이동 경로를 저장하였다가 이동할 경우
* 그 외 서버에 반드시 저장할 필요가 없는 경우
그럼 아래에서는 예제를 통하여 더욱 자세하게 알아보자.
## # localStorage 예제 및 코드보기
앞에도 언급했지만 위 두가지 객체의 차이점은 **세션에 따라서 데이터가 유지되는가 안되는가**로 구분할 수 있다. 그렇기 때문에 사용하는 방법도 거의 동일하다 하겠다. 아래는 localStorage객체의 사용로 자주 사용되는 메소드, 프로퍼티를 함께 알아보자.
### # 데이터의 저장 setItem()
특정값의 데이터를 저장하기 위한 방법으로 아래와 같이 메소드를 사용하거나 리터럴하게 사용하는 두 가지 방법이 가능하다. 아래 예제는 test란 이름의 key값을 정하고 이에 123이란 값을 저장하는 예제이다.
```
localStorage.test = '123';
localStorage.setItem('test', '123');
```
여기서 사용된 setItem() 메소드는 값을 저장하는 간단한 방식으로 key값에 매칭된 value를 인자로 넘겨주면 된다. 매우 간단하게 저장할 수 있다. 아래는 등록된 key값의 value를 얻기 위한 방법이다.
### # 데이터 불러오기, getItem()
```
localStorage.test;
localStorage.getItem('test');
```
역시 직접 키값을 입력하거나 getItem() 메소드를 사용하는 방법 두 가지가 있다. 아래는 특정 key 값을 지우는 방법에 대하여 알아보자.
참고로 전체 localStorage에 담겨있는 모든 값을 확인하려면 getItem()에 아무런 값도 넘기지 않으면 모든 정보를 받아올 수 있다.
```
localStorage.getItem(); // 전체 값 받아오기
```
그럼 아래는 데이터를 삭제하는 방법이다.
### # 데이터 삭제, removeItem()
아래는 test라는 키값에 저장된 값을 삭제하는 예제이다.
```
localStorage.removeItem('test');
// localStorage 객체에서 원하는 값을 지우는 방법
localStorage.clear();
// 한번에 저장된 모든 값을 삭제하는 방법
```
데이터를 삭제할 경우 removeItem()을 사용하여 하나만 제거할 수 있고 아니면 모든 값을 지울 수 있눈 clear() 메소드도 존재한다.
### # sessionStorage 예제보기
세션을 기준으로 데이터가 저장 및 유지되기 때문에 이 객체에 저장된 값은 **일시적인 수명**을 가지게된다. 만약 세션이 종료되는 경우... 브라우저를 닫거나 일정시간 아무런 동작도 하지 않는다면 당연히 저장된 값은 삭제될 것이다.
만약 데이터가 삭제되지 않길 바란다면 위에 나와있는 localStorage를 사용하기 바란다. 아래의 사용방법은 localStorage와 거의 동일한 메소드와 프로퍼티를 갖는다. 즉, 동일한 방법으로 사용이 가능하다 하겠다. 그럼 아래 예제를 참고하자.\
(참고로 세션을 사용한 저장방법은 보안 및 중요한 데이터의 경우 무방비로 노출되는 경우를 피하기 위해서 사용되는 경우가 많다.)
```
sessionStorage.setItem("domain", "webisfree.com");
// domain이란 키(key) 값을 사용하여 해당 텍스트를 저장함
sessionStorage.getItem("domain");
// 키에 저장된 값을 반환. 여기서는 webisfree.com 출력됨
sessionStorage.removeItem("domain");
// domain 키와 데이터 모두 삭제
sessionStorage.clear();
// 저장된 모든 값 삭제
```
#### ! 참고사항
인터넷 익스플로러 IE(Internet Explorer)는 10MB의 공간을 사용할 수 있고, 그 외 브라우저는 **대부분 5MB의 공간을 사용할 수 있다**. 사실 로컬 또는 세션스토리지 모두 사용되는 부분이 한정적이고 대부분 텍스트 공간을 차지하므로 용량이 부족하다던가의 이슈는 대부분은 없을 것이다.
# React 블로그 - 로그인 구현
[**https://electricburglar.tistory.com/155**](https://electricburglar.tistory.com/155)
**React로 블로그 만들기 #8**
**- 로그인 구현(5) 새로고침 후 로그인 유지 -**
**1. 로그인 유지**
\- 로그인을 한다고 해도 자동으로 로그인 상태가 유지되지 않는다.\
\- 브라우저를 닫거나 새로고침할 시 스토어 값이 초기화되므로 페이지에 다시 들어왔을 때 로그인을 유지하는 로직이 필요하다.
\- TodoApp에서는 쿠키를 이용하여 로그인을 유지하였지만, 블로그 앱에서는 HTML5에서 제공하는Web Storage API를 사용한다.
\- 또한 로그아웃 시 소셜로그인으로 발급받은 토큰을 제거하도록 로직을 추가해야함.
**2. localStorage vs sessionStorage**
\- Key와 Value 값으로 저장.
\- 문자열이 아닌 객체도 저장이 가능하며 5MB까지 저장 가능함.
\- 쿠키와 다르게 만료기간을 지정할 수 없으며, 서버로 전송되지 않음.
\- 자동로그인을 원하면 localStorage를 사용하고 브라우저를 닫으면 로그인이 풀리는 것을 원하면 sessionStorage를 사용
1\) localStorage
\- 사용자가 지우지 않는 이상 영구적으로 계속 브라우저에 남아있음.
\- 따라서 지속적으로 필요한 정보를 저장한다. (자동로그인 등)
2\) sessionStorage
\- 윈도우나 브라우저를 닫는 경우 사라지며 뿐만 아니라 브라우저 내에서 탭을 생성하는 경우에도 별도의 영역으로 할당됨.
\- 잠시동안 필요한 정보를 저장한다. (일회성 로그인 등)
**3. 구현하기**
1\) src/Components/Login.js
\- 소셜로그인 성공 시 받은 정보를 세션스토리지에 저장함.
```
import React, { Component } from 'react';
import { GoogleLogin } from 'react-google-login';
import KakaoLogin from 'react-kakao-login';
import styled from 'styled-components';
import { withRouter } from "react-router-dom";
class Login extends Component {
constructor(props) {
super(props);
this.state = {
id: '',
name: '',
provider: '',
}
}
// Google Login
responseGoogle = (res) => {
this.setState({
id: res.googleId,
name: res.profileObj.name,
provider: 'google'
});
this.doSignUp();
}
// Kakao Login
responseKakao = (res) => {
this.setState({
id: res.profile.id,
name: res.profile.properties.nickname,
provider: 'kakao'
});
this.doSignUp();
}
// Login Fail
responseFail = (err) => {
console.error(err);
}
doSignUp = () => {
const { id, name, provider } = this.state;
window.sessionStorage.setItem('id', id);
window.sessionStorage.setItem('name', name);
window.sessionStorage.setItem('provider', provider);
this.props.onLogin();
this.props.history.push('/');
}
render() {
return (
);
}
}
const Container = styled.div`
display: flex;
flex-flow: column wrap;
`
const KakaoButton = styled(KakaoLogin)`
padding: 0;
width: 190px;
height: 44px;
line-height: 44px;
color: #783c00;
background-color: #FFEB00;
border: 1px solid transparent;
border-radius: 3px;
font-size: 16px;
font-weight: bold;
text-align: center;
`
export default withRouter(Login);
```
2\) src/App.js
\- componentDidMount함수에서 세션스토리지에 id가 있는 경우 onLogin함수를 실행하고 없을 경우에는 onLogout함수를 실행하여 로그인을 유지함.
\- 또한 로그아웃 시, 소셜로그인으로 부터 전달받은 토큰을 제거하고 세션스토리지에 저장된 정보를 모두 삭제한다.
```
import React, { Component } from 'react';
import styled from 'styled-components';
import Header from './Layout/Header';
import Navigation from './Layout/Navigation';
import Router from './Routes/Router';
import Store from './Store/store';
class App extends Component {
constructor(props) {
super(props)
this.state = {
logged: false,
onLogin: this.onLogin,
onLogout: this.onLogout
}
}
// Login Func
onLogin = () => {
this.setState({
logged: true
});
}
// Logout Func
onLogout = () => {
this.setState({
logged: false
});
const provider = window.sessionStorage.getItem('provider');
//Google AccessToken Remove
if(provider === 'google') {
const auth2 = window.gapi.auth2.getAuthInstance();
auth2.signOut().then(function() {
console.log('Goolge Logout.');
});
}
// Kakao AccessToken Remove
else if(provider === 'kakao'){
window.Kakao.Auth.logout(function() {
console.log("Kakao logout");
});
}
//SessionStorage Clear
window.sessionStorage.clear();
}
componentDidMount() {
const id = window.sessionStorage.getItem('id');
if(id) {
this.onLogin();
}
else {
this.onLogout();
}
}
render() {
const { logged, onLogout } = this.state;
return (
);
}
}
const Layout = styled.div`
margin: 0 auto;
display: flex;
width: 100%;
flex-flow: row wrap;
`
const Content = styled.div`
margin: 0 auto;
`
export default App;
```
# Spring Security
# Spring Security 회원가입 / 로그인 구현
스프링 부트 환경에서 BCryptPasswordEncoder를 이용한 회원가입 암호화 / Spring Security를 이용한 로그인 구현
## 시큐리티의 구조
웹에서 스프링 시큐리티는 기본적으로 아래와 같이 필터 기반으로 동작한다.
많은 필터들이 존재하며, DispatcherServlet 을 호출하기 전에 거치게 된다.
setOrder로 필터간의 순서나 우선순위를 정해서 커스터마이징 할 수도 있다.
## 프로젝트에 Spring Security 적용하기
Maven
```
org.springframework.boot
spring-boot-starter-security
```
Gradle
```
compile("org.springframework.boot:spring-boot-starter-security")
```
위와 같이 디펜던시를 추가한 다음에 적절한 패키지를 생성하고, SecurityConfig 클래스를 추가한다. 패키지는 스프링 프로젝트의 패키지 하부에 있어야 한다.
```
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
}
```
위와같이 설정해주면, 이제 사이트 전체가 잠겨서, 비밀번호를 쳐야 접근할 수 있게 된다. 원활한 프로젝트 진행을 위해 일단 페이지의 인증을 해제하자.
```
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Override
public void configure(WebSecurity web) throws Exception
{
web.ignoring().antMatchers("/css/**", "/script/**", "image/**", "/fonts/**", "lib/**");
}
@Override
protected void configure(HttpSecurity http) throws Exception
{
http.authorizeRequests()
.antMatchers("/admin/**").hasRole("ADMIN")
.antMatchers("/**").permitAll();
}
}
```
위처럼 자원에 대한 접근을 풀고, 밑에서는 세부적인 설정을 따로 넣어준다. 일단은 원활한 진행을 위해 모든 경로에 대해 permitAll을 줬다.
## 적용된 Security 기반 회원가입 로직 추가하기
회원가입 이전에, 먼저 User정보를 구성할 테이블을 생성해야하는데 Security의 내부적으로 사용하는 클래스의 이름이 User이다. 겹치기 때문에 Account나 Member라는 이름을 사용해서 구현하자.
Member.java
```
@Getter
@Setter
@Entity
@EqualsAndHashCode(of = "uid")
@ToString
public class Member {
@Id
@GeneratedValue
private Long id;
@Column(nullable = false, unique = true, length=50)
private String uid;
@Column(nullable = false, length=200)
private String upw;
@Column(nullable = false, unique = true, length=50)
private String uemail;
@CreationTimestamp
private Date regdate;
@UpdateTimestamp
private Date updatedate;
@OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER)
@JoinColumn(name="uid")
private List roles;
}
```
`@OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER)` 설정은, cascade의 경우에는 엔티티들의 영속관계를 한번에 처리하지 못하기 때문에 이에 대한 cascade 설정을 추가하는것이고, member와 member\_role을 둘다 동시에 조회하기 위해서 fetch 설정을 즉시 로딩으로 EAGER 설정을 주어야 에러가 발생하지 않습니다.
MemberRole.java
```
@Getter
@Setter
@Entity
@EqualsAndHashCode(of = "rno")
@ToString
public class MemberRole {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long rno;
private String roleName;
}
```
MemberRepository.java
```
public interface MemberRepository extends CrudRepository {
}
```
Member가 제대로 동작하는지 확인을 위한 테스트 코드 작성
```
@RunWith(SpringRunner.class)
@SpringBootTest
@Log
public class MemberRepositoryTest {
@Autowired
MemberRepository memberRepository;
@Test
public void insertTest() {
for(int i=0; i<100; i++) {
Member member = new Member();
member.setUid("user" + i);
member.setUpw("pw" + i);
member.setUemail("hihi@" + i);
MemberRole role = new MemberRole();
if(i <= 80) {
role.setRoleName("BASIC");
}else if(i <= 90) {
role.setRoleName("MANAGER");
}else {
role.setRoleName("ADMIN");
}
member.setRoles(Arrays.asList(role));
memberRepository.save(member);
}
}
@Test
public void testMember() {
Optional result = Optional.ofNullable(memberRepository.findOne(85L));
result.ifPresent(member -> log.info("member " + member));
}
}
```
## 회원가입 로직 구현하기
위에서 제작한 Member와 MemberRole을 기반으로 회원가입 로직을 구현해보자.
MemberController.java
```
@Controller
@RequestMapping("/member")
public class MemberController {
@Autowired
MemberRepository memberRepository;
@PostMapping("")
public String create(Member member) {
MemberRole role = new MemberRole();
BCryptPasswordEncoder passwordEncoder = new BCryptPasswordEncoder();
member.setUpw(passwordEncoder.encode(member.getUpw()));
role.setRoleName("BASIC");
member.setRoles(Arrays.asList(role));
memberRepository.save(member);
return "redirect:/";
}
}
```
스프링 시큐리티에서 지원해주는 BCryptPasswordEncoder를 이용해 회원 비밀번호를 암호화하고, MemberRole을 정의해 Member에 넣어주고 save를 했다.
signUp.html
```
```
각각 Member의 파라미터에 해당하는 값을 매칭하고, thymeleaf를 사용한 csrf 토큰 관련 설정을 추가해주면 된다. 이후 Get으로 signUp페이지에 연결하고 회원가입을 진행하면 정상적으로 회원가입이 될 거다.
정상적으로 구현했다면, 위와같이 암호화된 비밀번호가 저장된것을 확인할 수 있다.
## 스프링 시큐리티 로그인 기능 구현하기
스프링 시큐리티에서 로그인 처리를 구현하려면 SecurityConfig에서 AuthenticationManagerBuilder를 주입해서 인증에 대한 처리를 해야 한다.
```
@Autowired
public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
}
```
위와같은 설정을 SecurityConfig에 넣고, 저기서 UserDetailsService를 이용해 로그인 인증 처리를 해주어야 한다.
이 과정에서 우리의 데이터베이스를 바탕으로 인증을 처리하기 위해서는 UserDetailsService를 구현하고 이를 HttpSecurity객체가 사용하도록 지정하면 우리가 만든 인증 로직을 바탕으로 동작하게 된다.
CustomUserDetailsService를 구현하면서 MemberRepository와 연동해 우리의 데이터베이스에 저장된 회원정보를 바탕으로 인증을 구현해야하는데 스프링 시큐리티의 User와 우리의 Member, GrantedAuthority와 우리의 MemberRole의 타입이 일치하지 않는 문제가 생긴다.
```
public class CustomUserDetailsService implements UserDetailsService{
@Autowired
MemberRepository memberRepository;
@Override
public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
return null;//반환할 타입이 Member와 맞지 않는다.
}
}
```
위처럼 loadUserByUsername 메소드는 UserDetails를 반환하는데, MemberRepository에서 얻어온 Member와는 타입이 맞지 않는다. 이 타입을 맞춰주기 위해 Spring Security의 User를 상속하는 커스텀 유저 클래스를 추가해주자.
* **SecurirtyMember 구현(SpringSecurity의 User 상속)**
```
@Getter
@Setter
public class SecurityMember extends User {
private static final String ROLE_PREFIX = "ROLE_";
private static final long serialVersionUID = 1L;
public SecurityMember(Member member) {
super(member.getUid(), member.getUpw(), makeGrantedAuthority(member.getRoles()));
}
private static List makeGrantedAuthority(List roles){
List list = new ArrayList<>();
roles.forEach(role -> list.add(new SimpleGrantedAuthority(ROLE_PREFIX + role.getRoleName())));
return list;
}
}
```
위에서 SecurityUser의 생성자로 Member를 받아서 Spring Security의 User타입과 우리가 구현한 Member의 값들을 매칭시켜 주자.
* **CustomUserDetailsService 구현(UserDetailsService 구현)**
위에서 구현한 SecurityMember를 바탕으로 아까 타입이 맞지않아 구현하지 못한 CustomUserDetailsService를 구현하자.
```
@Service
public class CustomUserDetailsService implements UserDetailsService{
@Autowired
MemberRepository memberRepository;
@Override
public UserDetails loadUserByUsername(String email) throws UsernameNotFoundException {
return
Optional.ofNullable(memberRepository.findByUemail(email))
.filter(m -> m!= null)
.map(m -> new SecurityMember(m)).get();
}
}
```
`@Service` 어노테이션으로 빈으로 등록해주어야 정상적으로 작동하게 된다.
* **Config 파일에 인증 관련 설정 추가하기**
```
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
@Autowired
public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
auth.userDetailsService(customUserDetailsService).passwordEncoder(passwordEncoder());
}
```
auth에 userDetailsService에 우리가 만든 customUserDetailsService를 등록하고, passwordEncoder에 우리가 회원가입 로직을 만들때 사용한 Encoder를 등록해주자.
* **Login Url 등록하기**
```
@Override
protected void configure(HttpSecurity http) throws Exception
{
http.authorizeRequests()
.antMatchers("/admin/**").hasRole("ADMIN")
.antMatchers("/**").permitAll()
.and().formLogin()
.loginPage("/login")
.loginProcessingUrl("/login")
.defaultSuccessUrl("/")
.failureUrl("/login")
.and()
.logout();
}
```
`loginPage`는 로그인 뷰 페이지를 연결하고, `loginProcessingUrl`은 Post로 로그인을 처리할 Url
`SucessUrl`은 로그인 성공 후 이동할 페이지, `failureUrl`은 실패 후 이동할 페이지를 지정한다.
```
```
이제 로그인 뷰 페이지에 username으로 name을 지정해주어야 정상적으로 받을 수 있다.
그리고 csrf 관련 설정을 위해 thymeleaf를 이용해 csrf토큰을 추가해주어야 요청을 정상적으로 받을 수 있다.
## 로그인 성공시의 부가적인 작업 추가하기
로그인 성공 시, 리다이렉트되기 전의 페이지로 이동시켜준다거나 하는 부가작업을 추가하기 위해서는 SecurityConfig의 successHandler에 핸들러를 등록해주어야 한다, 등록할 핸들러의 타입은 `AuthenticationSuccessHandler` 타입이기 때문에 `AuthenticationSuccessHandler`를 구현하면서 로그인 성공시 사용되는 핸들러인 `SavedRequestAwareAuthenticationSuccessHandler`를 상속받아 구현하고 SecurityConfig에 등록시켜 주면 된다.
그 전에, prevPage를 세션에 등록해서, 이전 페이지 정보를 저장해두자.
* **로그인 페이지 컨트롤러에서 세션에 이전 페이지 정보 넣기**
Referer 요청 헤더는 현재 요청된 페이지의 이전 페이지의 주소 정보를 포함한다. [Referer 관련 mozilla문서](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Referer)
```
@GetMapping("/login")
public String loginForm(HttpServletRequest req) {
String referer = req.getHeader("Referer");
req.getSession().setAttribute("prevPage", referer);
return "login";
}
```
* **이전 페이지 정보를 받아 Redirect하는 `SavedRequestAwareAuthenticationSuccessHandler` 구현하기**
`AuthenticationSuccessHandler`인터페이스를 구현하는 `SimpleUrlAuthenticationSuccessHandler`를 상속하는 `SavedRequestAwareAuthenticationSuccessHandler`를 상속해서 구현하면 된다.
```
public class CustomLoginSuccessHandler extends SavedRequestAwareAuthenticationSuccessHandler {
public CustomLoginSuccessHandler(String defaultTargetUrl) {
setDefaultTargetUrl(defaultTargetUrl);
}
@Override
public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response,
Authentication authentication) throws ServletException, IOException {
HttpSession session = request.getSession();
if (session != null) {
String redirectUrl = (String) session.getAttribute("prevPage");
if (redirectUrl != null) {
session.removeAttribute("prevPage");
getRedirectStrategy().sendRedirect(request, response, redirectUrl);
} else {
super.onAuthenticationSuccess(request, response, authentication);
}
} else {
super.onAuthenticationSuccess(request, response, authentication);
}
}
}
```
* **SecurityConfig에 해당 핸들러 등록하기**
SecurityConfig.java에 successHandler를 등록하고, 빈 형태로 등록해두면 된다.
```
http.successHandler(successHandler())
@Bean
public AuthenticationSuccessHandler successHandler() {
return new CustomLoginSuccessHandler("/");//default로 이동할 url
}
```
이후 로그인 시에만 해당 페이지로 접근 가능하도록 막아두려면 아래와 같은 설정을 추가하면 된다.
```
.antMatchers("/board/**").authenticated()
```
이제 /board의 경로에는 로그인 시에만 접근이 가능하도록 막히게 된다.
다른 페이지에서 board에 접근해보고, 로그인 시에 원하는 페이지로 정상적으로 이동되는지 테스트해보자.
### 전체 SecurityConfig 파일
```
@EnableWebSecurity
@EnableOAuth2Client
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Autowired
CustomUserDetailsService customUserDetailsService;
@Autowired
OAuth2ClientContext oauth2ClientContext;
@Override
public void configure(WebSecurity web) throws Exception
{
web.ignoring().antMatchers("/css/**", "/script/**", "image/**", "/fonts/**", "lib/**");
}
@Override
protected void configure(HttpSecurity http) throws Exception
{
http.authorizeRequests()
.antMatchers("/admin/**").hasRole("ADMIN")
.antMatchers("/board/**").authenticated()
.antMatchers("/**").permitAll()
.and().formLogin()
.loginPage("/login")
.loginProcessingUrl("/login")
.defaultSuccessUrl("/")
.successHandler(successHandler())
.failureUrl("/login")
.and()
.logout()
.and()
.addFilterBefore(ssoFilter(), BasicAuthenticationFilter.class);
}
@Bean
public AuthenticationSuccessHandler successHandler() {
return new CustomLoginSuccessHandler("/defaultUrl");
}
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
@Autowired
public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
auth.userDetailsService(customUserDetailsService).passwordEncoder(passwordEncoder());
}
private Filter ssoFilter() {
CompositeFilter filter = new CompositeFilter();
List filters = new ArrayList<>();
filters.add(ssoFilter(facebook(), "/login/facebook"));
filters.add(ssoFilter(github(), "/login/github"));
filter.setFilters(filters);
return filter;
}
private Filter ssoFilter(ClientResources client, String path) {
OAuth2ClientAuthenticationProcessingFilter filter = new OAuth2ClientAuthenticationProcessingFilter(path);
OAuth2RestTemplate template = new OAuth2RestTemplate(client.getClient(), oauth2ClientContext);
filter.setRestTemplate(template);
UserInfoTokenServices tokenServices = new UserInfoTokenServices(
client.getResource().getUserInfoUri(), client.getClient().getClientId());
tokenServices.setRestTemplate(template);
filter.setTokenServices(tokenServices);
return filter;
}
class ClientResources {
@NestedConfigurationProperty
private AuthorizationCodeResourceDetails client = new AuthorizationCodeResourceDetails();
@NestedConfigurationProperty
private ResourceServerProperties resource = new ResourceServerProperties();
public AuthorizationCodeResourceDetails getClient() {
return client;
}
public ResourceServerProperties getResource() {
return resource;
}
}
@Bean
@ConfigurationProperties("github")
public ClientResources github() {
return new ClientResources();
}
@Bean
@ConfigurationProperties("facebook")
public ClientResources facebook() {
return new ClientResources();
}
@Bean
public FilterRegistrationBean oauth2ClientFilterRegistration(
OAuth2ClientContextFilter filter) {
FilterRegistrationBean registration = new FilterRegistrationBean();
registration.setFilter(filter);
registration.setOrder(-100);
return registration;
}
}
```
#### [**https://xmfpes.github.io/spring/spring-security/**](https://xmfpes.github.io/spring/spring-security/)
# Untitled
# Untitled