일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- Spring
- 프로래머스
- springboot
- 프로그래머스
- 백준 17779
- 백준 16235
- java
- Spring Boot
- re.split
- Coroutine
- java 기술면접
- JPA
- MSA
- 백준 17626
- Kotlin
- 웹어플리케이션 서버
- 백준
- with recursive
- 백준 16236
- sql 기술면접
- 파이썬
- 백준 15685
- JVM
- 백준 파이썬
- 백준 19238
- 백준 16719
- spring oauth
- MySQL
- spring security
- spring cloud
- Today
- Total
목록Programming/Spring (39)
시작이 반
https://github.com/tmdrl5779/login-boilerplate Spring Boot Spring Security JWT : Token Redis : For RefreshToken sava Kotlin : Language JPA : ORM H2 : DataBase
코드를 개발하다 보면 같은 로직이 필요한 부분이 여러군데 있을 것이고 이러한 부분을 함수로 분리해서 처리한다. 이와 비슷하게 Spirng에서 흐름상 공통으로 처리해야 하는 부분이 있을 것이고 이를 위한 것이 필터, 인터셉터, AOP이다. 필터, 인터셉터, AOP의 공통점은 공통된부분을 따로 빼내어 처리하는 것이다. 필터(Filter) 필터는 스프링 컨테이너 외부에서 실행되는 공통 로직이다. 웹 컨테이너에 의해서 관리가 된다. 요청, 응답을 정제할 수 있으며 Dispatcherservlet 이전에 실행이 된다. (Spring과 분리되어야 하는 기능, 공통된 인증/인가 기능 등) 필터 메소드 - init() : 필터 객체 초기화 - doFilter() : 필터 전/후 처리 - destory(): 필터 객체 ..
Authentication 인증 : 로그인(spring security) -> jwt생성(유저정보로) -> SecurityContextHolder 인증객체 설정 Authorization 인가 : api 접근 -> jwt filter : 토큰 유효한지 확인 수행, 정상 수행 -> SecurityContextHolder에 인증 설정 Token Provider : 토큰의 생성, 토큰의 유효성 검증 등을 담당 Jwt filter : httpRequest 헤더에서 토큰을 가져와서 securityContextHolder에 저장 JwtSecuritConfig : Custom한 필터(JwtFilter)를 Security로직에 추가 JwtAuthenticationEntryPoint : 유효한 자격증명이 아니면 401에러..
@Valid : 객체의 값을 검증해준다. @PostMapping("/members/new") public String create(@Valid MemberForm form) { Address address = new Address(form.getCity(), form.getStreet(), form.getZipcode()); Member member = new Member(); member.setName(form.getName()); member.setAddress(address); memberService.join(member); return "redirect:/"; } @Getter @Setter public class MemberForm { @NotEmpty(message = "회원 이름은 필수 입..
ex) H2 test 폴더안에 resources폴더를 생성한다. 기존에 main폴더에 있던 application.yml을 그대로 복사하여 test의 resources폴더 안에 넣는다. (테스트에서 할 설정과 운영의 설정은 다르기 떄문에 분리하는게 맞음) Cheat Sheet에 가보면 in-Memory 에 jdbc:h2:mem:test 가 있다. url을 jdbc:h2:mem:test 로 바꿔주면 메모리 모드로 동작한다. 그런데 Spring Boot는 별도의 설정이 없을 경우 메모리 모드로 동작한다. 이렇게 주석처리해도 메모리 모드로 동작함
싱글톤 패턴일때 스프링 빈의 이벤트 사이클 "스프링 컨테이너 생성" -> "스프링 빈 생성" -> "의존관계 주입" -> "초기화 콜백" -> "사용" -> "소멸전 콜백" -> "스프링 종료" 프로토 타입 스프링의 3가지 생명주기 콜백 인터페이스(InitalizingBean, DisposableBean) : 옛날 방식 해당 클래스에 InitalizingBean, DisposableBean인터페이스 implements afterPropertiesSet() : 의존관계 주입이 끝나면 호출되는것 destroy() : 빈이 소멸전 호출 설정 정보에 초기화 메소드, 종료 메소드 지정 : 외부 라이브러리에 적용할때 사용 @Configuration이 붙은 설정 정보에 빈등록시 메소드 지정하여 초기화 콜백, 소멸전 ..
업무 로직 빈 : 컨트롤러, 비지니스 로직이 있는 서비스, 레포지토리 등 비지니스 요구사항을 개발할 때 기술 로직 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 점점 자동 빈 등록으로 가는 추세이다. 빈이 많아지고 설정 정보를 관리하는 것 자체가 부담이 된다. 자동빈을 사용해도 OCP, DIP를 모두 지킬 수 있기 떄문에 업무 로직에 관해서는 자동을 사용하는 것이 좋다. 기술 로직같은 경우 업무 로직에 비해 수가 적고 광범위하게 영향을 미치고 기술 로직같은 경우 잘 되고 있는지 아닌지 파악하기 어려운 경우가 많기 때문에 수동빈을 사용해서 명확하게 나타내는 것이 좋다. 또한 비지니스 로직에서 다형성을 적극 활용할 때 수동 등록을 사용해서 한번에 보기 쉽게 하는 것이 좋지만 그래도 자동 빈을 쓰고..
@Autowired를 통한 의존관계 주입 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 생성자 주입 - 생성자 호출시점에 1번만 호출되는 것이 보장 - 불변, 필수 의존관계에 사용 - 해당 class가 빈으로 등록되어 있고 생성자가 한개 있을때 @Autowired 생략 가능 @Component public class MemberServiceImpl implements MemberService{ private final MemberRepository memberRepository; @Autowired public MemberServiceImpl(MemberRepository memberRepository) { this.memberRepository = memberRepositor..