기존 User 엔티티에는 암호화가 걸려있지않았음.
그래서 AttributeConverter 구현체를 하나 만들어서 특정 필드들은 entity 영속화할때와 꺼내올때 aes256방식의 암/복호화가 되게 구현했음
그런데
기존에 querydsl로 유저정보를 select해오던 페이지에 아까 암호화 converter등록한 필드들이 복호화가 안된 상태로 나타나는 문제가 발생함.
생각해봤더니 querydsl에서 @QueryProjection으로 바로 dto에 매핑하는게 문제였음.
해결방법을 생각해봤는데
1. 그냥 유저를 엔티티로 가져와서 dto 변환
-> 가장 쉬운 방법
-> 그러나 원하는 데이터만 select해올 수 없다는 단점이 있음
2. response dto 생성 메서드에 복호화 로직 만들기
-> 현재 코드 대부분 유지한채로 문제 해결가능한 방법
-> 암호화된필드가 있는 모든 dto에 로직실어야하는 문제
-> 암복호화 로직이 converter와 dto 양분되어있어서 깔끔하지않아보임
이 두가지인데 둘 다 마음에 들지를 않는다..
다른 방법은 없을까 고민중인데 의견있으면 달아주면 감사
그래서 AttributeConverter 구현체를 하나 만들어서 특정 필드들은 entity 영속화할때와 꺼내올때 aes256방식의 암/복호화가 되게 구현했음
그런데
기존에 querydsl로 유저정보를 select해오던 페이지에 아까 암호화 converter등록한 필드들이 복호화가 안된 상태로 나타나는 문제가 발생함.
생각해봤더니 querydsl에서 @QueryProjection으로 바로 dto에 매핑하는게 문제였음.
해결방법을 생각해봤는데
1. 그냥 유저를 엔티티로 가져와서 dto 변환
-> 가장 쉬운 방법
-> 그러나 원하는 데이터만 select해올 수 없다는 단점이 있음
2. response dto 생성 메서드에 복호화 로직 만들기
-> 현재 코드 대부분 유지한채로 문제 해결가능한 방법
-> 암호화된필드가 있는 모든 dto에 로직실어야하는 문제
-> 암복호화 로직이 converter와 dto 양분되어있어서 깔끔하지않아보임
이 두가지인데 둘 다 마음에 들지를 않는다..
다른 방법은 없을까 고민중인데 의견있으면 달아주면 감사
진짜 엔티티 다른 필드에 들어 있는 값들이 뒤지게 많아서 과부하 오는거 아니면 1번 해도 상관 없지 않을까요
1번 방식을 택해도 과부하가 올거같진 않아요 다만 좀 더 최적화할 방안이 없을까 고민중입니다. 그렇지만 repository에서는 entity를 반환하고 service에서는 dto를 반환한다는 규칙을 지킬 수 있는건 장점같네요. 현재는 JpaRepository는 entity를 반환하고 querydsl에서는 dto로 반환하고 있거든요.
영한좌께서는 항상 그정도의 트레이드오프 비교는 필요하다고….
강의 다시 들으러갑니다..
중대한 오류가 있었음. querydsl에서 dto로 바로 매핑해도 attributeConverter가 동작하는것을 확인했다. querydsl에서 엔티티로 가져오고 service단에서 dto로 변환시키도록 로직을 짰는데도 암호화가 안풀리길래 설마해서 데이터 다시 넣었더니 잘됨 시발..
chat gpt4와 stackoverflow에서 querydsl으로 dto매핑 바로 시켰을때는 converter가 작동안한다는 정보를 줘서 착각하고 있었다. 그런데 왜 dto로 바로 매핑하는데 converter가 작동하는거지? 이유를 찾아봐야겠다.. 패치가 된건가?