본문 바로가기

프로젝트40

리팩토링 2 - 결제 검증과, XSS 등에 대한 방어 테스트 개인적으로 생각했던, 결제의 핵심은 검증과 검사였다. 여러가지 경우에 대해 방어 테스트를 진행했었지만, 리팩토링 과정에서 추가하고자 했던 검증 과정등을 정리하여보겠다.  현재 결제 과정은 1. member에 결제 요청 -> 2. 사용자 포인트가 결제 금액보다 작은지 검증 -> 3. 작다면, 그만큼 다시 front end로 전달-> 4. front end에선, 그 부족한 금액만큼 결제 진행 -> 5. 그 결제 금액을 검증받고, 저장, 승인 -> 6. purchase 부에서 다시 member 부로 전달(product의 상태 변경, 사용자 포인트 변경 등 수행) 1. 1000원을 결제하고, 100000포인트를 넣어달라는 악의적인 요청 이러한 경우는 JSON BODY로 악의적인 DATA를 전송하였거나,혹은 코드.. 2024. 4. 19.
코드 리팩토링 1 - 코드 정리, 가독성 증가 구조 정리 1. 수 많은 dto들의 위치를 정리하였다. 현재 우리의 프로젝트는 MSA 구조이기 때문에, 서로의 동작을 약속하고 개발 과정은 완전히 독립적이다. 남이 보기에도 명확하게, 한눈에 보기 쉽게 DTO를 정리하였다. 2. SERVICE가 아닌 METHOD 단위의 분할을 진행하였다. 설계 과정에서 SERVICE의 범위를 최대한 세밀하게 분리하자는 생각에 따라 각 SERVICㄷ들이 1개의 메소드를 지니게 아주 잘게 서비스를 분할하였는데, 리팩토링 과정에서 해당 과정에 따른 높은 결합도의 문제에 대한 의견을 들었다. 전체적인 결제의 검증과 저장을 한 SERVICE로 묶었다. 해당 SERVICE들은 사실 메소드의 개수가 많지 않기 때문에 분할하여도 되었지만, 서비스의 범위 자체가 요청을 보내는 부 , 요.. 2024. 4. 18.
1차 완성, 코드 리뷰 1차적으로 프로젝트가 완성 되었다. https://github.com/stophyeon/Darakbang.git GitHub - stophyeon/Darakbang: 오픈 마켓 서비스 오픈 마켓 서비스. Contribute to stophyeon/Darakbang development by creating an account on GitHub. github.com 우리가 원하던 대로 , Spring Cloud, API GATEWAY 등을 활용하여 MSA 구조의 마켓의 구축을 성공했다. 해당 구축 이후엔 코드 리뷰를 진행했다. 사실 코드 리뷰라는 기회 자체가 정말 얻기 쉽지 않은 기회이지만, 다행히도 팀장역할을 하신 분의 지식이 깊어 코드 리뷰를 받을 수 있었다. 코드 리뷰 내용 1. 가독성이 너무 떨어진.. 2024. 4. 16.
Spring Security (MSA)를 하며 만난 문제들 현재 우리 프로젝트 구조는 ApiGateway -> Eureka확인 -> 후 해당 service들에게 요청을 보내는 형식이다. 즉, ApiGateway에서 jwtfilter를 통한 인증,인가를 하고 있다. 프로젝트 과정에서 MSA 구조로 프로젝트를 올려야 했고, 이 과정에서 인증 문제가 발생해 계속 401 UNAUHTORIZED가 발생했다. 이를 해결해보자 . JWTFILTER만 있는것이 아니다. JWTFILTERCHAIN 뿐만 아니라, CORS, 기본 SecurityFilter등이 존재한다. @Configuration @EnableWebSecurity public class SecurityConfig { private final JwtProvider jwtProvider; private final Me.. 2024. 4. 8.
RESTFUL URL 규칙 + 협업시 지켜야 할 것들 프로젝트를 진행하며, 혼자 개발 했던 경험과는 큰 차이가 있음을 배우고 있다. 그 과정에서 배웠던, URL 규칙을 정리하고자 한다 . URL 규칙 1. 소문자를 사용하자. 대문자는 가끔 문제가 발생되기도 한다. 2. 마지막이 /로 끝내지 않게 하자 3. 동사를 지양하자. 동사를 사용하면 사용자가 지금 어떤 행위를 하고있는지 직접 확인이 가능하다. 지양하고 GET, POST, PUT , PATCH등을 활용하여 해당 내용을 전달하자 4. BACKEND에 관련된 내용인데, REQUESTPARAM과 PATHVARIABLE의 활용엔 고민하자. 사실 둘다 URL의 전달이 목적이 되면, 어떤것을 사용해도 기능상 문제가 되는 경우는 많지 않다 (하지만, PATHVARIABLE은 하나만 가능하다는 단점도 있기는 하다. .. 2024. 4. 6.
@builder/ 모든 생성자 정보처리기사를 공부하며 , 빌더 패턴이라는 패턴을 확인하였다. 실제로 프로젝트를 위한 협업을 진행하며 @builder라는 어노테이션을 확인하였고, 어떨때 생성자 대신 해당 @builder를 사용하는지, 그 이유는 무엇인지 정리하기로 하였다. @builder의 장점 @Table(name = "product") @Entity @Getter @RequiredArgsConstructor @AllArgsConstructor public class Product { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "product_id") private Long productId ; @Column(name = "product_name") .. 2024. 4. 3.
DELETE , UPDATE 쿼리 관련 동시성 문제 문제점 : 상품을 작성하던 중 PAGIGNG 혹은 조회 과정에서 글이 삭제 되거나 , 수정되었을 때는 어떻게 진행할지에 대한 의견이 나왔다. 단순히 상품, 전체 만을 조회 할 때는 글이 삭제 수정되는 것만으로 그칠 수 있는 문제지만 후에 해당 상품을 구매하는 경우에는 구매 도중 글을 삭제하거나 취소할 수 있다는 문제까지 유발 될 것으로 예측되어 해당 부분에 대한 고민을 생각했다. 생각한 해결방안 : 각 요청시마다 검사 너무 많은 요청과 잦은 검사가 필요하게 된다. 또한 DATA의 문제를 BACKEND단에서 모두 검증하는 방식이, DATA는 DB영역에서 관리하고 서비스는 BACKEND 영역에서 관리하는 분리에 대한 개념에서 벗어났다고 느꼈다. 낙관적 LOCK(S-LOCK) 구매 과정에서, 특히 DB의 VE.. 2024. 3. 30.
결제 과정 완료 기존, 결제를 원하는 상품을 즉시 구매하는 형태로 구현하려 하였으나, 기술이 아닌 정책상의 문제(개인 사업자 만이 사용 가능, 사용자의 카드정보를 개인이 보유 금지)로. 이를 해결할 방안을 찾게 되었다. 해당 과정을 진행하며 주의했던 점 1. 결제 검증 결제 자체는 open api호출 만으로 쉽게 진행할 수 있다.( 앞서 상기한 정책상 이유로, test channel만 가능) 하지만 증권사 시스템을 분석하며, 결제 등의 프로세스에서 가장 중요한 것은 검증이라는 생각을 했다. front단이 전송한 결제 정보가, 사실과 다를 수도 있다는 가정을 하며 검증을 진행하였다. 2. front, backend 단의 분리 사용자의 카드 정보를 backend 단에서 보유할 수 없다. 이러한 이유로 front 단에서 어쩔.. 2024. 2. 27.
프로젝트 TEST public void SavePaymentInfo(String paymentid, String status, String paytime, String ordername, int totalamount) { OffsetDateTime offsetDateTime = OffsetDateTime.parse(paytime); Timestamp requestedAtTimestamp = Timestamp.from(offsetDateTime.toInstant()); Payment payment = new Payment( paymentid,status,requestedAtTimestamp,ordername,totalamount ) ; paymentRepository.save(payment) ; } 해당 내용을 TEST 하.. 2024. 2. 25.
SERVICE/CONTROLLER단 분할, 그에 따른 비동기적 형태 변경 이전 목표에 따라 , 1. TOKEN을 매 요청마다 생성(POSTONE 측의 TOKEN이, 굉장히 자주 만료된다) 2. SERVICE와 CONTROLLER단, 그리고 내부적인 역할 분담을 진행하겠다. @Service @NoArgsConstructor @Slf4j public class AccessTokenService { private final WebClient webClient = WebClient.builder().baseUrl("https://api.portone.io").build(); private final ObjectMapper objectMapper = new ObjectMapper(); public Mono GetToken() { PortoneTokenRequest portoneToke.. 2024. 2. 23.

티스토리툴바