전체 글

SQL Injection이란? SQL Injection은 웹의 취약점을 이용한 해킹기법 입니다. SQL = 데이터베이스에 명령을 내리는 언어 Injection = 주입 그래서 SQL Injection은 데이터베이스에 명령을 내리는 언어를 악의적으로 주입해서 실행시켜 데이터베이스가 비정상적인 동작을 하도록 만드는 것을 의미합니다. SQL Injection의 원리와 여러 공격방식 그럼 SQL인젝션은 어떤 방식으로 어떤 구조로 주입이 이뤄질까요? 아래 사진을 보겠습니다. 이 사진은 로그인 페이지에서 아이디 비밀번호를 입력하고 로그인버튼을 눌렀을 때 실행과정이 그려져 있는데 위쪽에는 SQL언어가 자리잡고 있습니다. 저렇게 아이디와 비밀번호에 입력한 문자열값이 그대로 입력되게 됩니다. 만약 저대로 AAAA' --..

오늘 한 일 오늘은 조건검색기능을 QueryDSL을 이용해서 만들었다. 자바 백엔드 기술은 Spring Boot와 Spring Data JPA를 함께 사용한다. 하지만, 복잡한 쿼리, 동적 쿼리를 구현하는 데 있어 한계가 있다. 이러한 문제점을 해결할 수 있는 것이 QueryDSL이다. QueryDSL이 등장하기 이전에는 Mybatis, JPQL, Criteria 등 문자열 형태로 쿼리문을 작성하여 컴파일 시에 오류를 발견하는 것이 불가능했다. 하지만, QueryDSL은 자바 코드로 SQL 문을 작성할 수 있어 컴파일 시에 오류를 발생하여 잘못된 쿼리가 실행되는 것을 방지할 수 있다. 난 이 자바코드로 써서 코드에서 에러를 바로 찾아주는 부분이 정말 신세계 였다. 먼저 QueryDSL을 사용하기 위해서는..

오늘은 객체지향 프로그래밍에대한 내용부터 SOLID원칙까지 테크톡 준비를 해서 스터디 팀원들에게 발표했다. 그래서 이 글은 배운 객체지향의 원칙 5가지 SOLID원칙에 대한 정리 내용이다. 1. SRP(Single responsibility principle)​ 단일 책임 원칙​ 먼저 단일 책임 원칙이다. 1번 원칙은 단어를 하나씩 떼어서 생각해보면 직관적으로 뜻을 이해할 수 있는 원칙이다. 단일 : 하나의 객체(클래스) 책임 : 해당 클래스가 할 수 있는 기능, 혹은 정보만 원칙 : 원칙 정도로 정리가 되는데, 하나의 클래스는 하나의 책임만 가지며, 클래스가 가지는 모든 서비스는 그 책임을 수행하는데 집중되어 있어야 한다. 라는 원칙인데, 이것만 들어보면 잘 이해가 안 될 수 있다 아래를 보자 ​ 고양..

초반 S3 로직을 작성을 한 뒤 테스트를 했었을 때는 Get, Put, Delete가 성공적으로 작동을 하여서 PR을 보냈다. 추가적인 로직 작업이 생겨서 S3 로직에 추가작업을 한 뒤 테스트를 해보았는데, AccessDenied발생... AWS에 접속하여 IAM, S3 권한을 확인해 보았는데 권한 역시 아무문제가 없었고, S3에 사진을 생성하는 로직조차 문제가 없었다. IAM정책 중 건드린적 없는 불순물 발견... AWSCompromisedKeyQuarantineV2 PR당시 실수로 application.properties에 AWS AccessKey와 secretKey를 노출한 적이 있는데 이때 AWS가 Key가 노출되어서 과금이 발생할 수도 있다고 추가해준것이다. 해결법은 AccessKey를 재발급 ..

오늘 한 일 오늘은 Redis조회수 로직을 짰는데, 구조상 문제가 생겨 팀원들과 회의를 했다. 먼저 Redis를 이용해서 조회수 로직을 짠 이유는 조회수가 증가할 때마다 DB에 직접 조회수 증가(변경) 요청을 보내주는게 낭비라고 생각했다. 그리고 항상 조회수가 올라가는걸 방지하기위해 Redis에서 키밸류값으로 해당 게시글과 유저의 id를 가지고, 일정시간이 지나면 사라지도록 해두고 체크하여 같은 유저가 무한히 새로고침으로 조회수를 올릴 수 있는 문제를 해결하였다.(한 유저당 포스트마다 1시간에 한번씩만 조회수가 증가하도록 설정) 그래서 Redis라는 캐시메모리를 이용해서 성능을 개선해 조회수를 관리하기로 생각했다. 근데 문제는 Redis는 말 그대로 캐시 메모리기 때문에 다운되거나 꺼지는 순간 데이터가 ..

오늘한 일 오늘은 팀원들 코드를 pull받아서 기능 수정과 팀원들에게 코드를 조금 더 깔끔하게 바꿔달라는 요청을 받아서 코드들을 다 수정했다. 시간이 가장 많이 걸린건 모든곳에 다 쓰이는 주요 엔티티 이름 자체를 처음부터 잘못 지었다는 것이다... 이것 바꾼다고 시간을 많이 썼지만 이제 코드가 가독성도 좋아지고 깔끔해진 느낌이 들었다(이게 클린코드 인가...?) 메서드 명도 알아보기 힘들다며 혼남... 실수로 입력 안 하고 지나간 부분을 팀원이 집어줘서 더욱 클린한 코드로 개선했습니다! 엔티티 이름도 같이 고민했습니다! 내일할 일 내일은 비로소 조회수를 구현해서 완성하고, 시간이 남는다면 채팅기능까지 조금 공부해보도록 하겠다.. 바이...

오늘한 것 오늘 아침부터 팀원들과 회의 하고 ERD를 조금 손보면서 CRUD를 완성하고, 공동구매 신청기능인 ApplicationUsers작성을 완성했다. 해당 부분 ERD가 수정되었다. 할것도 많고 하는 시간이 많이 길지 않아 한번에 많은 기능은 못 만들고 있다. 아마 D-day가 다가오면 더 급하게 하게 되겠지... 내일할 일 내일은 본격적으로 공동구매 게시글 쪽 검색기능을 제외한 모든기능 완성을 생각해두고 있고, Redis를 이용한 조회수에대해서 조금 알아보겠다!

오늘한 일 사이드 프로젝트 혼자 살 때 1일차 API명세를 작성하고 팀원들과 회의를 한 뒤 공동구매 게시글의 생성을 만들었다. API설계 같이 살 때 fairs 게시글 전체 조회 GET /home/fairs?page=0&size=0 X X [ { title max_user current_user_count multipartFile(FormData) per_user_price enumShare address }, { title max_user current_user_count multipartFile(FormData) per_user_price enumShare address } ] 같은 지역 유저 데이터만 조회 기본값은 판매완료 빼기 게시글 생성 POST /home/fairs Bearer ~~ title..