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) | 사용자 이름 | ||
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 설계시, 참고자료
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) | 사용자 이름 | ||
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에게 부여된 역할 |
'IT > 삽질 로그' 카테고리의 다른 글
[삽질 프로젝트 계획] 티스토리 유입자 대시보드 만들기 - 밑그림 (0) | 2020.06.16 |
---|---|
[삽질 프로젝트 설계] 티스토리 유입자 대시보드 만들기 - NOSQL 설계 초안 (0) | 2020.06.09 |
[삽질로그] OAuth2.0 with Spring Security기반 UserInfo 테이블 및 API 설계 (0) | 2020.04.26 |