BE Study 13th

Receiving JSON body of the HTTP request


1. @RequestBody

Using RequestBody, you can receive the body of the request as a JSON: Content-Type: application/json

Without RequestBody, the parameter will be mapped via @RequestParam(@RequestParam is omitted).



@PrePersist Problem

Two ways of initializing the field of the entity.

1.
public Comment(
@NonNull String postId,
@NonNull String authorId,
String content
) {
this.postId = postId;
this.authorId = authorId;
this.content = content;
this.createdDate = LocalDate.now();
}


2.
public Comment(
@NonNull String postId,
@NonNull String authorId,
String content
) {
this.postId = postId;
this.authorId = authorId;
this.content = content;
}

@PrePersist
public void prePersist() {
createdDate = LocalDate.now();
}


The latter(2) is recommended, in terms of entity lifecycle and persistence context and DB's consistence.

3. Bi-Directional VS Uni-Directional


4.
@Column(name = "POST_ID")

The above means that you will set the name of the column as "post_id".

@JoinColumn(name = "BOARD_ID")

The above means that you will set the field of the given attribute's primary key as a foreign key, and set the name of the column as "Board_id".


    @OneToMany(mappedBy = "board")

The above means that the opponent(which has @ManyToOne)'s attribute name is "board".


5. Use of DTO
When we should use DTO? view-controller? controller-service? both? 
There's no magic-answer. But there's one good practice.
1. calling an entity from field is preferred to be held in service layer.
2. you can use many DTOs for dependency elimination between layers.

6. JWT

JWT is a most used token-based sign-in method. It's process is simple
1. When the sign-in is successful, the server grants the client the 'access token'
    Access token has data like expiration date, issued date, etc.
2. Client holds the access token, and every time when it sends API Request, it sends the token attached to the request's header.
3. If the access token is valid(not expired, and carries the right key), sends the response

However, you might see the problem. You don't have any solution if the token is stolen. You can set the lifetime of the access token very short, but it'll be very interrupting because it requires frequent sign-in.

So, there's a solution called 'Refresh Token'. The access token expires in very short time, while the lifetime of refresh token is much longer.
1. When the sign-in is successful, the server grants the client two different tokens, 'access token' and 'refresh token'.
2. Client holds two tokens, but every time when it sends API Request, it sends only the access token attached to the request's header.
3. If the access token is valid(not expired, and carries the right key), the server sends the response
4. If the client didn't get the fair response(if got 401 unauthorized response), the client sends the same request again, but this time with the refresh token attached.
5. If the refresh token is valid, the server sends the response and the new access token.

As you can see, the access token which is frequently transmitted expires in very short time, while the lifetime of refresh token is much longer; amazon's access token only lasts for an hour. You should also keep in mind that the server that gets API Request(resource server) and the server that issues the refresh token(authorization server) can be different.

This helped preventing access token stolen during transmission. However, as you can see, still the problem exists: what if the refresh token is stolen?

To solve such problem, there's an algorithm called 'refresh token rotation'. With RTR, refresh token is disposable: when the new access token is issued with refresh token, the refresh token is expired immediately and issues new refresh token for the client. So, you can know that the refresh token might be stolen if someone uses expired refresh token; either the client or the thief would use the expired refresh token. However, what would you do if you know the refresh token is stolen? There's several solutions.

1. You can expire all of the tokens issued for the client. For such expiration process, the server should make and hold a 'token chain'.
2. You can expire the token so that it cannot be used next time. For such, you should use db or storage that holds the valid refresh token mapped with each client. 

 However, the hacker can still steel the unexpired refresh token and use it and both the solutions have to give up the advantages of statelessness.

댓글

이 블로그의 인기 게시물

Interface of Java

Data Analytics Overview(OLTP vs OLAP)

Leetcode