스프링 시큐리티 [Spring Security] http 네임스페이스 쓰려면 필터 이름은 항상 고정(?) http://static.springsource.org/spring-security/site/docs/3.0.x/reference/appendix-namespace.html#nsa-http-attributes <filter> <filter-name>securityFilterChain</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>
스프링 시큐리티 [Spring Security] sec:authentication 참조: http://static.springsource.org/spring-security/site/docs/3.0.x/reference/taglibs.html 스터디의 각 모임에는 댓글을 달 수 있습니다. 삭제 기능이 필요해져서 댓글 삭제 기능을 만들었는데 이것을 일반적인 User-Role 기반 Voter를 사용해서 권한 처리하는것이 그렇게 단순하지는 않습니다. 관리자 권한이 있는 사람만 삭제할 수 있게 할까요? 아님
테스트 [Spring Security] Method Security Test @PreAuthorize(“hasRole(‘ROLE_MEMBER’)”) public boolean write(String contents) { while (graffitiRepository.getTotalRowCount() >= GRAFFITI_LIMIT_COUNT) { graffitiRepository.deleteFirstGraffiti();
권한 설계 [권한] 3단 구조 봄싹은 권한 관리는 3단계로 설계했습니다. 사용자 – 역할 – 권한 Member *—->1 Role *—->1 Right 현재 봄싹의 권한 관리 구조와 Role을 주로 사용하고 있습니다. 따라서 *와 **등을 이용해서 여러 URL을 큰 뭉탱이로 ROLE_ADMIN, ROLE_MEMBER로 구분하고 있죠. 굉장히 Coarse-grained 한 설정이죠. 이런 상태라면
스프링 시큐리티 스프링 시큐리티 맞춤확장(customization) - 파트 1. UserDetail 또는 GrantedAuthority 맞추기 참조 및 번역: http://blog.springsource.com/2009/01/02/spring-security-customization-part-1-customizing-userdetails-or-extending-grantedauthority/ 이번 글은 스프링 시큐리티 맞춤확장과 관련된 실용적인 예제 중심의 여러 작은 글들의 시리즈 중 첫 번째 글이다. 이번 맞춤확장 요구 사항은 상상에서 온 것이 아니라 전부 현장에서 요구한 것이다. 다음과 같은 요구사항이 있다고 가정해보자. 역할(role) 목록이 있고 각각의