repository 가 제공하는 save 메소드를 사용중 문제가 발생했다.
save진행시 null값들을 제외하지않고 업데이트 해버려서 내가 생각하는 결과와는 달랐다. 따라서 직접 update Query를 작성하고 사용해야했다.
public interface MemberRepository extends JpaRepository<MemberEntity, String> {
@Modifying
@Transactional
@Query(value="update Member m set m.status = 'N' where m.user_id = :id", nativeQuery = true)
int deleteMember(@Param("id") String id);
}
update query는 @Modifying 어노테이션을 사용한다.
콜론(:)은 메소드의 매개변수를 사용할때 사용한다.
natvieQuery를 true 값으로 해줘야 이 query가 jpql이 아닌 native query라고 알게된다.
transactional 어노테이션은 트랜잭션을 자동으로 관리해주게끔 해준다.
int 형을 사용하면 어떤 행에 영향이 갔는지 갯수를 반환한다.
근데 이 코드를 chat-gpt에게 보여드리니 이친구가 sql injection 공격에 취약하니 jpql 또는 Criteria API을 사용하여 쿼리를 작성하는 것이 권장된다고 한다.
sql injection
sql 삽입공격은 흔히 이뤄지는 공격으로써 입력데이트럴 필터링하여 방어할 수 있다고한다.
sql 삽입공격에 대한 예제를 보았는데 사용자가 query에대해 직접 접근할 수 없는데 jpa에서 이 문제가 발생할 수 있나 ?? ... 흠 ... 잘 모르겟다 일단 사수 gpt님께서 있다고 하시니 수정해야겟다.
JPQL
JPQL은 엔티티 객체를 조회하는 객체지향 쿼리이다. 테이블을 대상으로 쿼리하는것이 아니라 엔티티를 대상으로 쿼리한다.
적으면서 생각해본건대 이러면 외부에서 db에 대한구조를 알 수 없으니 보안에서 강한건가 싶다. -> 알아보니 맞는말이라더라
JPQL은 결국 SQL으로 변환된다.
JPA에서 제공하는 메소드 호출만으로 섬세한 쿼리 작성이 어렵다는 문제에서 JPQL이 탄생된 것이다.
Criteria api
객체지향 쿼리 빌더라고 한다. 이걸 사용하면 코드로 jpql을 작성할 수 있고 컴파일 단계에서 sql에러를 잡아낼 수 있는 장점이 있다고한다.
결론
jpql을 사용하자.
jpql을 사용하니 sql injection예제에 있는 내용을 적어도 문제가 발생하지 않는다.
근데 이 문제는 생각해보니 내가 userId로 먼저 조회해보고 query를 날리니 생길수가 없는 문제다... 그래도 이런 문제가 생길 수 있는지 알아서 다행이다....
