Spring Security 구성에서 충돌 발생 에러
에러 로그
•
원인) WebSecurityConfigurerAdapter와 SecurityFilterChain 모두 발견됨
•
해결) 최신 버전에서 사용하는 SecurityFilterChain 방식으로 아예 바꿔줌
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
...
Java
복사
public class WebSecurityConfig {
@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
...
Java
복사
dto에 붙이는 annotation
@Getter
@NoArgsConstructor
@AllArgsConstructor
@Builder
Plain Text
복사
에러 로그(request에 @NoArgsConstructor @AllArgsConstructor 안 붙였을 때)
에러 로그(response에 @getter 안 붙였을 때)
•
의문점
◦
어떤 dto는 builder, getter 어노테이션만 붙여도 괜찮은데 어떤 dto는 Builder, Getter는 물론 Constructor 어노테이션까지 붙여야 에러가 안남
◦
resposneDto는 getter를 쓰는 곳이 없는데 getter 안 붙이면 에러가 남
JWT 토큰 서버 Postman에서 테스트
•
환경변수 설정
◦
우측 상단에 빨간색으로 표시된 부분 클릭 후 environment에 Add 클릭
◦
변수명에 token 적고 save 눌러주기
◦
설정 끝. 이제 다시 API 테스트하는 화면으로 돌아와서 우측 상단에 No Envrionment를 방금 만든 DEV로 바꿔주기 (매우매우매우매우매우매우 중요. 이거 까먹고 안된다 하는 사람들 많음.. 매번 페이지 다시 들어갈 때마다 해주어야 하니 혹시 포스트맨으로 인증 테스트가 잘 안된다면 No environment로 되어 있지 않은지 항상 확인하자.)
•
로그인 API
◦
아래와 같이 입력해 토큰 값을 환경 변수에 저장하게 해줌
var data = JSON.parse(responseBody);
pm.environment.set("token", data.accessToken);
pm.test(data.accessToken, function() {
});
Java
복사
•
인증 필요한 API
◦
예를 들면 회원정보조회와 같은 API에 Authorization 값으로 방금 생성한 환경변수 token을 넣어줌
•
테스트해보자 → 잘 된다. 굳
◦
로그인 API 실행
◦
회원정보조회 API 실행
BaseEntity 적용
•
main() 들어있는 클래스에 @EnableJpaAuditing 붙이기
@EnableJpaAuditing
@SpringBootApplication
public class BackendApplication {
public static void main(String[] args) {
Java
복사
•
baseEntity 클래스 생성
@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
@SuperBuilder
@NoArgsConstructor
public abstract class BaseEntity {
@CreatedDate
private LocalDateTime createdDate;
@LastModifiedDate
private LocalDateTime modifiedDate;
}
Java
복사
•
적용할 Entity 클래스들에 extends BaseEntity 붙이기
public class Score extends BaseEntity {
Java
복사
Redis로 로그아웃 처리
•
logout 요청 시 해당 accessToken을 blacklist로 등록함
◦
이때, redis에 무수히 많은 logout 요청이 계속해서 남아있으면 안되니 자동 삭제 기간을 설정함
redisTemplate.opsForValue().set(accessToken, "blackList", expiration, TimeUnit.MILLISECONDS);
Java
복사
•
API 요청 시 토큰이 blacklist인지 검증함
에러
클린 코드를 작성하기 위한 약속
1.
예외 처리 method 따로 빼서 분리하기
2.
dto 객체 이름은 request나 response로 하기
3.
response dto를 생성하는 아래와 같은 코드는 Controller 혹은 Service단에서 처리하기!
AuthJoinResponse response = AuthJoinResponse.builder()
.id(member.getId())
.loginId(member.getLoginId())
.email(member.getEmail())
.nickname(member.getNickname())
.build();
return response;
Java
복사
3-1. 3을 결정한 이유는 좀 더 찾아보니 아래와 같은 내용이 있었기 때문입니다.
Response 클래스가 데이터 전송 객체(Data Transfer Object, DTO)로 사용되고 있는 경우, 이를 도메인 레이어에 위치시키는 것은 권장되지 않습니다.
도메인 레이어는 비즈니스 로직을 처리하기 위한 핵심 로직을 구현하는 곳이며, DTO와 같은 데이터 전송 객체는 해당 로직에서 직접 사용되지 않고, 데이터 전송을 위한 용도로 사용되는 객체입니다. 이러한 이유로 DTO와 같은 객체는 주로 서비스 레이어 또는 컨트롤러(Controller)와 같은 레이어에 위치시키는 것이 좋습니다.
컨트롤러(Controller)는 클라이언트에서 전달된 요청(Request) 데이터를 처리하고, 응답(Response) 데이터를 생성하는 역할을 담당합니다. 따라서, 컨트롤러에서는 클라이언트의 요청에 대한 응답(Response) 데이터를 생성하기 위해, DTO 객체를 이용하는 것이 일반적입니다.
서비스(Service) 레이어는 주로 비즈니스 로직을 처리하는 역할을 담당합니다. 따라서, 서비스(Service) 레이어에서 DTO 객체를 생성하고, 응답(Response) 데이터를 생성하는 것은 비추천되는 방법입니다. 이러한 로직은 컨트롤러(Controller)에서 처리하는 것이 더욱 적절합니다. 하지만, 특정한 경우에는 서비스에서 Response DTO를 생성하는 것이 더 편리한 경우도 있습니다. 예를 들어, 비즈니스 로직에서 여러 개의 데이터를 조합해서 반환하는 경우 등입니다.
따라서, Response DTO를 생성하는 위치는 상황에 따라 다르며, 개발자의 판단에 따라 선택하는 것이 좋습니다.
결론은, SRP 원칙을 어길 위험을 아예 방지하기 위해선 Response Dto 생성을 컨트롤러에서 하는 게 맞기에 기본적으론 컨트롤러에서 하겠습니다!
다만 여러 데이터를 조합해서 반환하는 경우엔 예외적으로 서비스에서 하는 거로 할게요!
Response DTO의 Validation, JSON 변환 등을 Service Layer에서 처리하면 SRP 원칙을 위반할 가능성이 있다고 합니다. 그런 부분 조심하면 될 거 같아요!
위와 같이 이전에 생각했었지만,,
•
결론, 현재는 requestDto와 responseDto 채우는 건 모두 service에서 하고 있다.
하루 정리
TIL 작성하기