상품 정보 수정은 3단계의 기능으로 나뉜다.
각 기능과 목적에 적합하도록 URI 설정
/**상품 정보 수정 페이지*/
@GetMapping("/register/product/{id}")
public ResponseEntity<ResponseProduct> editProduct(@PathVariable Long id, HttpServletRequest request){
User user = (User) request.getAttribute("user");
ResponseProduct product = productService.editProduct(id, user);
return (product != null) ?
ResponseEntity.status(HttpStatus.OK).body(product) :
ResponseEntity.status(HttpStatus.BAD_REQUEST).body(null);
}
판매등록한 모든 상품이 아닌 특정 상품의 상세 정보만 사용자에게 보여주도록 하는 요청
/register URI로 판매자 권한이 있는지 체크, URI 끝에 있는 상품 id에 해당하는 상품 정보 return
@Override
@Transactional
public ResponseProduct editProduct(Long id, User user) {
Product product = productRepository.findById(id).orElse(null);
if(product == null) {
return null;
}
// product 를 등록한 유저아이디와 받은 jwt 의 유저 아이디가 같은지 확인
if (product.getUser().getUsername().equals(user.getUsername())) {
return ResponseProduct.builder().product(product).build();
} else {
return null;
}
}
Spring Data Jpa의 findById 함수 사용, findById 의 return 타입은 Optional 클래스이기 때문에 orElse(null) 로 설정
위의 Controller쪽에서 요청을 보낸 유저가 판매자권한을 갖고있는지 체크는 했지만 실제 이 상품을 등록한 유저가 이 요청을 보낸 유저가 맞는지 체크 해주는 과정 필요
정상적인 유저라면 본인이 등록한 상품 목록을 조회하고 그 중 하나를 클릭해 해당 요청을 보낼테니 당연히 본인이 등록한 상품이겠지만 악의적이던 예상치못한 오류상황이던 판매자 권한을 가진 다른 유저가 본인이 등록하지 않은 상품에 대한 요청을 보낼 수 있다. 이런 상황은 서버에서 막아야하기 때문에 이런 과정이 필요하다.
체크에 통과하면 조회해온 Entity를 Dto로 변환하여 return
@PutMapping("/register/product/{id}")
public ResponseEntity<ResponseProduct> updateProduct(@PathVariable Long id, @RequestBody RequestProductModify requestProductModify, HttpServletRequest request) {
User user = (User) request.getAttribute("user");
requestProductModify.setId(id);
requestProductModify.setUsername(user.getUsername());
ResponseProduct product = productService.updateProduct(requestProductModify);
return (product != null) ?
ResponseEntity.status(HttpStatus.OK).body(product) :
ResponseEntity.status(HttpStatus.BAD_REQUEST).body(null);
}