xor eax, eax

protected void resultRedirectStrategy(final HttpServletRequest request, final HttpServletResponse response, final Authentication authentication) throws IOException, ServletException { SavedRequest savedRequest = (SavedRequest) request.getSession().getAttribute("SPRING_SECURITY_SAVED_REQUEST"); if (authentication.getAuthorities().contains(new SimpleGrantedAuthority("ROLE_ADMIN"))) { redirectStrat..

스프링 시큐리티를 적용하고나서부터 로그인을 하지 않은 anonymousUser일때 계속해서 login 요청이 날라가는 문제가 생겼다. 정확히는 http://localhost:8080/null로 먼저 요청이 날라가고 그 이후에 내가 설정해둔 로그인 페이지인 http://localhost:8080/auth/login으로 redirect 되는 것이다 (하지만 redirect가 되지는 않음) 그래서 어떤 페이지를 들어가려고 하든 로그인 요청이 한번씩 꼭 날라갔고 로그인 페이지를 요청하면 로그인 요청을 2번씩 하는 문제가 발생하였다. 이 문제가 그냥 사용하는데에 있어 어떤 문제를 발생시키는건 아니었지만 항상 정상적인 요청 이후에 null 요청이 한 번 더 날라갔기때문에 스프링 시큐리티에서 기억하는 "SPRING_..

코드 출처: https://velog.io/@peppermint100/Spring-Boot-%EC%98%88%EC%99%B8-%EC%B2%98%EB%A6%AC 스프링부트의 예외 처리에 있어서 가장 핵심은 값에 대한 validation을 계속 순차적으로 진행하면서 생기는 exception을 단 하나의 객체에서만 처리하고 그 객체를 위로 던지는 것이다. @PostMapping("/login") //모든 exception을 담아줄 response객체를 return. public ResponseEntity login(@RequestBody LoginRequest loginRequest) throws Exception { //service layer에서 login 처리 후 token을 리턴 String token..

AOP란 핵심 기능과 핵심적이지 않은 기능을 분리해서 '반복적이고 소모적이며 귀찮은' 일을 반복하지 말자는 의미의 기능이다. 부가적으로 코드의 가독성을 올려주며 재사용성을 올려준다. 스프링에서의 AOP는 런타임에 프록시 객체를 생성하여 공통 기능으로 삽입하는 방식으로 구현되어있다. AOP의 주요 용어로는 Advice - 핵심 로직에 AOP를 언제 적용할 것인지 나타냄 JoinPoint - Advice를 적용할 지점을 나타낸다. (스프링에서는 프록시를 이용하기에 메서드에 대한 호출에 대해서만 가능) Aspect - 여러 객체에 공통으로 적용되는 AOP를 말함 등등이 있다. //AOP로 사용할 클래스라는 것을 명시 @Aspect //클래스를 스프링 빈으로 등록 @Component public class Ti..

값의 변화점을 예측하기 힘들어지기에 무지성 Setter는 지양해야 한다. 지금 당장에는 문제가 생기지 않을지라도 이후에 Setter에 의한 문제가 발생할 여지를 남겨두는 것은 좋지 않다. 그러면 Setter없이 어떻게 Entity를 update 할 수 있을까? 핵심은 한가지다. update가 필요한 값만을 받는 메서드를 따로 생성해서 그것을 명시적으로 사용하는 것. 코드로 보면 간단하다. @RestController ... @PostMapping("/update/{id}") public void updateCategory(@PathVariable("id") Long id, @RequestBody CategoryDto categoryDto) { categoryService.updateById(id, cat..

빈 배열만 출력된다는 것은 [ {}, {}... {} ]으로 보이지만 실제 값은 [ { "id" : null, "username" : null} ]처럼 보여 빈 배열로 출력되는 것처럼 보이는 것이다. 이 문제는 객체에 접근해야하는 Hibernate와 HttpMessageConverter가 Entity의 property에 접근하지 못하여 null값을 반환하게 되는 것이다. @Getter(AccessLevel.PUBLIC) 해결 방법은 Getter를 생성해주고 접근 레벨을 public으로 해주는 것이다.

@PreAuthorize()는 메서드를 실행하기 전에 하는 권한 검사 @PostAuthorize()는 메서드를 실행하고 클라이언트에게 응답을 하기 직전에 하는 권한 검사 라는 차이점을 가지고 있다. hasRole([role]) : 현재 사용자의 권한이 파라미터의 권한과 동일한 경우 true hasAnyRole([role1,role2]) : 현재 사용자의 권한디 파라미터의 권한 중 일치하는 것이 있는 경우 true principal : 사용자를 증명하는 주요객체(User)를 직접 접근할 수 있다. authentication : SecurityContext에 있는 authentication 객체에 접근 할 수 있다. permitAll : 모든 접근 허용 denyAll : 모든 접근 비허용 isAnonymou..

JPA에서는 @Embeddable 애너테이션을 이용하여 해당 클래스가 다른 Entity에 의해 프로퍼티 값으로 들어갈 수 있음(embedded)을 의미한다. public class Company { private Integer id; private String name; private String address; private String phone; private String contactFirstName; private String contactLastName; private String contactPhone; // standard getters, setters } 회사라는 클래스에 있는 평범한 프로퍼티들이지만 연락할 수 있는 인원에 대한 정보는 따로 빼는 것이 좋아 보일때 @Embeddable p..

@SQLDelete(sql = "UPDATE USER SET deleted=true where id=?") soft deletion은 유저의 입장에서는 삭제되어 보이지 않는 값이지만 DB에는 삭제하지 않고 남겨두는 방식이다. 해당 Entity 테이블에 deleted라는 컬럼에 flag와 같이 true, false로 나타내어 구현한다. JPA에서는 해당 어노테이션이 있으면 delete를 수행하는 대신 update를 통해 flag를 true로 하여 외부로는 보이지 않게 해주어 간단하게 구현할 수 있다. @SQLDelete(sql = "UPDATE user SET deleted=true WHERE id=?") @Where(clause = "deleted=false") 매번 deleted=false인 데이터만 ..

IoC를 통한 DI를 받는 방법은 @Autowired를 통한 방법과 생성자를 기반으로 받을 수 있다. @RequiredConstructor를 통해(혹은 그냥 생성자를 통해) private final Repository repository와 같이 주입을 받게 되면 불변성을 얻게 되어 실행 중 객체가 변하는 것을 막을 수 있고 이로 인해 오류를 방지할 수 있다. 코드의 품질도 높아지며 순환 참조를 방지하는 등의 부가적인 이득도 있다. Autowired를 지양하고 private final을 생성자로 생성하도록 하자