스프링 Security ACL Owner 검사

넵 친절한 답변 감사합니다.

말씀해주신 키워드로 세부적인 것들은 찾아보겠습니다.

정말 진심으로 감사드려요!

게시글의 작성자를 판단하는 로직을 URL에 의존하는게 안전한지 잘 모르겠습니다. URL은 아무나 /boards/random/ 이런식으로 시도해볼 수도 있을텐데 결국엔 DB를 조회해야 하는 일이 발생할꺼라.. DB 조회 없이 인증처리를 하고 싶으신 건 이해하지만, 현실적으론 어려워 보이네요.

친절한 답변 감사합니다.

한가지 더 질문이 있습니다.

만약 spring security oauth2 를 이용해서 인증 / 인가 처리를 할경우

게시글의 작성자만 수정할 수 있는 로직을 구현할때

boards/{username} // 이런 api url을 갖는다고 하면

이렇게 컨트롤러에서 얻은 username 기반으로 해당 토큰의 소유자가 username가 일치하는지 판단하는 식으로 해야하는 건가요?

아니면 정말 데이터베이스에서 조회해서 username을 비교해야하는 걸까요?

이번에도 "해당 게시물의 소유자만이 게시물을 변경한다"라는 요구 사항을 구현하는 방법이 여러가지가 있을 수 있는데요. 말씀하신대로 ACL을 사용해서 구현할 수 있습니다.
기본적으로 그 방법은, ACL 관련 정보 (어떤 엔티티가 어떤 유저 또는 어떤 권한에 어떤 오퍼레이션을 허용하는가)를 DB에 저장하고, 그 정보를 스프링 시큐리티 ACL과 연동하고 최종적으로 코드에서는 메소드 시큐리티를 이용해서 처리하는 방법이 있습니다.
참고: http://www.baeldung.com/spring-security-acl
하지만 스프링 시큐리티 ACL을 적용하면 프로젝트 복잡도가 꽤 상승하기 때문에, 저라면, 메소드 시큐리티만 사용하고 ACL 부분은 커스텀 익스프레션을 만들어 쓸 거 같습니다. 그것도 간단하진 않지만, 스프링 시큐리티 ACL 적용보다는 덜 복잡해 보여서요.
참고: http://www.baeldung.com/spring-security-create-new-custom-security-expression
(두번째 질문에 대해서) 네, 세션을 사용하는 겁니다. 브라우저에 JSESSIONID 쿠키에 해당하는 세션을 서버쪽에 세션 애트리뷰트로 만들어 관리하고 있는겁니다. 그래서 서버를 여러개 사용할 경우에는 spring-session이라는 프로젝트를 적용해서 Redis 저장소에 세션 정보를 넣고 여러 서버가 공유해서 쓰는 방식으로 만들거나, 라우팅을 할 때 어떤 클라이언트의 요청을 처음 받았던 서버로만 계속해서 요청이 가도록 라우팅 룰을 설정 해야합니다.
참고: https://www.haproxy.org/download/1.5/doc/configuration.txt (역기서 balance 알고리듬 확인)
(세번째 질문에 대하여) OAuth2 기반 토큰 인증 방싱을 쓴다면, 세션 정보는 안 쓰느냐? 라는 질문이신거죠? 네 다르죠. OAuth2를 쓰면 요청에 들어온 토큰이 있는지, 그게 유효한지만 확인하고, 그게 유효하다면 인증된 요청으로 간주하기 때문에 그때는 세션 애트리뷰트나 JSESSIONID가 필요하진 않습니다만 그건 설정하기 나름입니다. OAuth2랑 다른 인증 방식도 같이 지원하실꺼면 세션도 쓸 수 있습니다.
좋은 질문 감사합니다. :)