25-03-10

📌 Daily Report

https://github.com/ssginc-be/DOKI/issues/56

📌 프로젝트 상황

2시간 반 잤다. 더 이상의 설명은 생략한다.

피곤함과 별개로, 지금 코드 안짜면 진짜 망할수도 있다는 생각이 드니까 초인적인 집중력이 나오고 있다.

그리고 엔드포인트로 돌릴 수 있는건 다 돌려서, 카프카 / 유레카 전부 클라우드 서버로 돌리고 로컬은 최대한 자원을 아끼려 하고 있다.

Java로 개발된 IDE에서 Java로 개발된 프레임워크를 돌리고 거기에 크롬까지 탭 낭낭하게 띄워놨다?

8GB가 고작 좀 버벅거리는 것으로 끝남에 감사해야 한다;

제발 올해는 노트북 RAM 확장을 하자.

📌 @Value와 Constructor 주입

CoolSMS로 문자 발송 기능 구현하다가 다시 한번 상기하게 된 부분인데,

다음과 같이 생성자 주입을 하면 @Value로 주입하려는 값들은 생성자 주입 시점에 null이다.

그 이유는, 이 레퍼런스에서 답을 찾을 수 있다.

Spring won't inject the properties' values until the object is fully instantiated.

정리하면, 생성자 호출 -> 인스턴스화 -> property 값 주입 순으로 일어나기 때문이다.

SmsUtil.java

@Component
public class SmsUtil {

    @Value("${coolsms.apiKey}")
    private String SMS_API_KEY;

    @Value("${coolsms.secret}")
    private String SMS_SECRET;

    @Value("${coolsms.sender}")
    private String SMS_SENDER; // 발신 번호

    @Value("${coolsms.enable}")
    private boolean SMS_ENABLED; // false면 로그만 찍히고 실제 문자 전송은 스킵됨

    // ...

    // CoolSMS API 설정
    private final DefaultMessageService messageService;
    
    public SmsUtil() {
        this.messageService = NurigoApp.INSTANCE.initialize(SMS_API_KEY, SMS_SECRET, "https://api.coolsms.co.kr");
    }
    // ...
}

따라서 상단의 코드에서는 다음과 같은 에러를 맞게 된다.

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [com.ssginc.commonservice.util.SmsUtil]: Constructor threw exception
    at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:222)
    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:122)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1337)
    ... 50 common frames omitted
Caused by: java.lang.NullPointerException: Parameter specified as non-null is null: method net.nurigo.sdk.NurigoApp.initialize, parameter apiKey

그러므로 다음과 같이 생성자를 수정해야 한다.

SmsUtil.java

@Autowired
public SmsUtil(@Value("${coolsms.apiKey}") String SMS_API_KEY, @Value("${coolsms.secret}") String SMS_SECRET) {
    this.messageService = NurigoApp.INSTANCE.initialize(SMS_API_KEY, SMS_SECRET, "https://api.coolsms.co.kr");
}

📌 문자 발송 기능 구현시 주의사항

번호도용 문자차단서비스에 가입되어 있을 수 있음.........

해지 신청 넣어도 반영까지 최소 1~2일 걸린다고 하니 직전에 급하게 구현하지 말 것.

📌 인증 성공하면, 그 다음은?

보안적인 측면을 생각해보면, 사용자가 이메일 인증 번호 인증까지 마쳤는데

그 상태에서 페이로드를 조작해서 회원가입 REST 요청을 보낼 수도 있다.

무슨 소리냐면, 이메일 인증 성공 -> 휴대폰 인증 성공 -> 가입 버튼 활성화됨 -> 가입 페이로드 조작하여 API request

이럴 수도 있다는 것이다.

그래서 진짜 견고한 시스템을 구상해본다면,

회원가입 페이지 진입 -> 고유 코드의 JWT 발급해서 Set-Cookie (30분 후 만료)
이메일 인증 성공 -> JWT에 해당 이메일 기록해서 Set-Cookie
휴대폰 번호 인증 성공 -> JWT에 해당 휴대폰 번호 기록해서 Set-Cookie

이런 식으로 가야 클라이언트 측의 변조 위험성을 원천 차단할 수 있지 않을까 싶다.

📌 JPA 메소드로 중계테이블의 id 접근하기

카테고리 필터 목록 조회 구현하다가 혹시나 싶어 시도해봤는데, 놀랍게도 작동하더라.

원래 FK 관계는 underscore와 Pascal case로 나타내는 메소드 네이밍 컨벤션이 있는데, 중계 테이블이 있어도 이걸 그대로 따르는 것 같다.

---

참고로, Store에는 storeCategoryList라는 중계테이블과의 @OnetoMany 매핑관계가 있고,

중계테이블인 StoreCategory에는 category라는 @ManyToOne 매핑관계가 있다.

그리고 Category의 PK 필드명은 categoryId 이다.

---

따라서 다음의 네이밍은 Store의 categoryList의 category의 categoryId를 WHERE절로 잡아 매칭하고, LIMIT으로 페이징하는 쿼리가 된다(!)

StoreRepository.java

public interface StoreRepository extends JpaRepository<Store, Long> {
    Page<Store> findAllByStoreCategoryList_Category_CategoryId(Long categoryId, PageRequest pageRequest);
}

📌 어쩌다보니 SPA

팝업스토어 카테고리 목록 조회를 비동기 방식으로 구현했는데

그러다보니 전체 목록 조회 방식이랑 달라서 history가 좀 꼬이는 것 같다.

demo에는 문제 없지만 마음에 안들어서 추후에 보수를 좀 해야겠음...

DOM은 JS 객체로 다루는게 안정적인 것 같은데 워낙 태그도 많고 해서, 현 시점에선 깡 문자열 처리가 불가피 해보인다.

특히 테이블 다룰 때 좋더라~(?)