1. Create

  • URL : <domain>/<version>/user
  • Method : POST
  • Request Header
    • Content-Type: application/json
  • Request Body (format = JsonObject)
    • Userinfo(userid, username, password, email, phone_number, address,  ... ) - JsonObject
    • secretHash HMAC(signing_key(clientSecret, sha256)[clientId + username]) - String
  • Response

    • If success, 
    • If failed, response is HTTP status code with customed error message

 

2. Read

  • URL : <domain>/<version>/user/me
  • Method : GET or POST
  • Request Header :
    • Authorization: Bearer <YOUR_ACCESS_TOKEN>
  • Response
    • If success, response is HTTP status code with userinfo that matched with access token.
    • If failed, response is HTTP status code with customed error message.

2.1. Read by List

  • URL : <domain>/<version>/users
  • Method : GET or POST
  • Request Header : 
    • Authorization: Bearer <YOUR_ACCESS_TOKEN>
    • Content-Type: application/json
  • Request Body
    • Query Parameters - JsonObject

 

 

 

3. Update(덮어쓰기? 부분업데이트?)

  • URL : <domain>/<version>/user/me
  • Method : PUT
  • Request Header
    • Authorization: Bearer <YOUR_ACCESS_TOKEN>
    • Content-Type: application/json
  • Request Body
    • Updated UserInfo - JsonObject
  • Response
    • If Success, return requester's id
    • If failed, response is HTTP status code with customed error message.

 

 

 

4. Delete

  • URL : <domain>/<version>/user/me
  • Method : DELETE
  • Request Header
    • Authorization: Bearer <YOUR_ACCESS_TOKEN>
  • Response
    • If Success, return customed message that user delete is completed.
    • If failed, return HTTP status code with customed error message.

 

 

 

 

 

5. User Table

  • DB : mysql
  • Storage Engine : InnoDB (Transaction이 많이 일어나기 때문에 MyISAM보다 InnoDB가 유리)
  • Schema : portal_user 
  • 향후 잘못되었다 판단한 부분은 빨간색으로 표시

 

Column Type Nullable PK 설명
id varchar(255)    O 사용자 고유 식별자
name varchar(50)     사용자 이름
email varchar(100)     사용자 이메일
authorities varchar(255) → ????     권한 → 역할의 조합이므로, 테이블을 따로 빼서 관리한다.
password varchar(255)     암호화된 비밀번호
role varchar(30) → ????     역할 → 권한에 종속되는 개념이므로, 정규화가 필요함.
last_logined_date datetime     마지막 로그인된 날짜 및 시간
account_create_date datetime     계정 생성 날짜
account_last_update_date datetime     마지막 계정 정보 수정 날짜 → 로그성임. 
credential_last_update_date datetime     비밀번호 마지막 변경 날짜 → 바로 밑 항목과 비슷한 성격이다.
비밀번호 만료일을 가지고 계산할 수 있는 항목임.
credential_expire_date datetime     비밀번호 만료일 → last update를 이 컬럼으로 대체 할 수 있음.
is_account_enabled bit(1)     계정 활성화 여부
is_account_locked bit(1)     계정 잠금 여부
is_credential_expired bit(1)     비밀번호 만료 여부 → 이 컬럼이 필요한가?
is_account_expired bit(1)     계정 만료 여부 (spring security isEnabled()와 매칭되는 column)

 

 

 

5.1. DB Table 설계시, 참고자료

https://github.com/spring-projects/spring-security/blob/master/core/src/main/java/org/springframework/security/core/userdetails/UserDetails.java

 

 

5.2. 찾은 문제점

  • Spring Security의 Default UserDetails를 보고 필드를 설계를 하였으나, 설계한 필드들이 "왜"쓰이는 필드들인지 이해를 하지 못하였다.
  • 오버헤드가 걸리지 않는 선에서 충분히 credential expire date에 대해 판별할 수 있지만, credential_expire_date와 is_credential_expired와 같은 중복케이스가 첫 설계시 존재했다.
  • 데이터에 비해 불필요하게 크기를 잡았다. 불필요한 데이터 크기 설계는 자제하도록 하자.
  • mysql 데이터 타입을 잘 모르다 보니 효율적인 데이터 타입에 대한 선택을 하지 못했다.
  • 정규화를 하지 못했다.

 

 

 

6. 20200423 개선된 DB 설계

 

6.1. User Schema

Column Type Nullable PK 설명
id varchar(20)    O 사용자 고유 식별자
name varchar(10)     사용자 이름
email varchar(30)     사용자 이메일
password varchar(255)     암호화된 비밀번호
last_logined_date datetime O   마지막 로그인된 날짜 및 시간
account_create_date datetime     계정 생성 날짜
account_last_update_date datetime     마지막 계정 정보 수정 날짜
credential_expire_date datetime     비밀번호 만료일
is_account_enabled bit(1)     계정 활성화 여부
is_account_locked bit(1)     계정 잠금 여부
is_account_expired bit(1)     계정 만료 여부

 

 

6.2. Authority Schema(복합 PK)

Column Type Nullable PK FK 설명
id varchar(20)   O User.id User Table로부터의 외래키
role varchar(10)   O   User에게 부여된 역할

+ Recent posts