권한별 롤관리 재질문2
- 작성자 :
- 박*호
- 작성일 :
- 2014-09-02 14:44:10
- 조회수 :
- 701
- 구분 :
- 실행환경
- 진행상태 :
- 완료
Q
기존 답변 감사합니다.
말씀하신대로
\A/manage/.*\.do.*\Z 라는 롤이
ROLE_ADMIN1과 ROLE_ADMIN2 각각 부여해둔 상태라
DEF_ROLES_AND_URL_QUERY를 조회해보면
\A/manage/.*\.do.*\Z이 두개가 뜨는 상황입니다. 권한은 물론 ROLE_ADMIN1과 ROLE_ADMIN2이구요.
보다보니 DEF_ROLES_AND_URL_QUERY에서 나온 리스트의 상위부터 한줄씩 내려가면서
접근 URL과 등록된 롤을 비교하면서 매치가 되면 매치가 된 권한코드를 리턴 시켜주고,
리턴된 권한코드가 현재 로그인된 사용자에게 부여된 권한인지 아닌지 비교를 하여 접근을 막는 것 같은데요.
문제는 유저별로 동일한 롤을 각각 등록 시켰을때 DEF_HIERARCHICAL_ROLES_QUERY에서
위와 같이 동일한 롤이 여러개가 있을때 리스트에서 한줄한줄 비교하다가 URL과 매치가 되면 그 다음줄 부터는 비교를 하지 않고
접근권한 코드를 리턴 시켜버려서 이런 문제가 생기는 것 같습니다.
예를들어 \A/manage/.*\.do.*\Z의 롤을 ROLE_ADMIN1과 ROLE_ADMIN2 권한에 각각 등록을 시킨 상태에서
ROLE_ADMIN2로 로그인 하여 접근할 경우 DEF_ROLES_AND_URL_QUERY의 리스트에서 ROLE_ADMIN1과 매치되는
데이터가 상위에 있으니 거기서 비교를 끝내 버려서 ROLE_ADMIN2에도 접근 권한이 있는지는 아예 비교조차 안되고
ROLE_ADMIN1만 리턴 시키고 막혀 버리는 것 같습니다.
위와 같이 동일한 롤을 여러권한에 부여했을때 이런 문제가 생기지 않게 할 방법이 없을까요?
한개의 롤이 여러권한에 등록이 되어있으면 ROLES_AND_URL_QUERY에서 멀티컬럼이나 멀티로우 형식으로 리턴이 되어야
정상적으로 작동을 할 것 같은데 현재는 그런 구조가 아닌 듯 하네요.
말씀하신대로
\A/manage/.*\.do.*\Z 라는 롤이
ROLE_ADMIN1과 ROLE_ADMIN2 각각 부여해둔 상태라
DEF_ROLES_AND_URL_QUERY를 조회해보면
\A/manage/.*\.do.*\Z이 두개가 뜨는 상황입니다. 권한은 물론 ROLE_ADMIN1과 ROLE_ADMIN2이구요.
보다보니 DEF_ROLES_AND_URL_QUERY에서 나온 리스트의 상위부터 한줄씩 내려가면서
접근 URL과 등록된 롤을 비교하면서 매치가 되면 매치가 된 권한코드를 리턴 시켜주고,
리턴된 권한코드가 현재 로그인된 사용자에게 부여된 권한인지 아닌지 비교를 하여 접근을 막는 것 같은데요.
문제는 유저별로 동일한 롤을 각각 등록 시켰을때 DEF_HIERARCHICAL_ROLES_QUERY에서
위와 같이 동일한 롤이 여러개가 있을때 리스트에서 한줄한줄 비교하다가 URL과 매치가 되면 그 다음줄 부터는 비교를 하지 않고
접근권한 코드를 리턴 시켜버려서 이런 문제가 생기는 것 같습니다.
예를들어 \A/manage/.*\.do.*\Z의 롤을 ROLE_ADMIN1과 ROLE_ADMIN2 권한에 각각 등록을 시킨 상태에서
ROLE_ADMIN2로 로그인 하여 접근할 경우 DEF_ROLES_AND_URL_QUERY의 리스트에서 ROLE_ADMIN1과 매치되는
데이터가 상위에 있으니 거기서 비교를 끝내 버려서 ROLE_ADMIN2에도 접근 권한이 있는지는 아예 비교조차 안되고
ROLE_ADMIN1만 리턴 시키고 막혀 버리는 것 같습니다.
위와 같이 동일한 롤을 여러권한에 부여했을때 이런 문제가 생기지 않게 할 방법이 없을까요?
한개의 롤이 여러권한에 등록이 되어있으면 ROLES_AND_URL_QUERY에서 멀티컬럼이나 멀티로우 형식으로 리턴이 되어야
정상적으로 작동을 할 것 같은데 현재는 그런 구조가 아닌 듯 하네요.
A
안녕하세요. 박강호님.
DEF_ROLES_AND_URL_QUERY에 의해 조회된 데이터는 매칭을 위하 사용하는 것이 아니라
URL 패턴별로 할당된 ROLE을 찾는 것이라 끝까지 처리됩니다.
즉, 사용자가 URL을 접근할 때에 비교하는 부분의 처리가 아니라 처음 초기화 될 떄에 URL 패턴에 대하여 할당된 ROLE을 지정하는 것입니다.
이 부분은 내부적인 처리에 의해 동일한 패턴이 있는 경우 순서적으로 같이 나와야 하나의 패턴에 여러 ROLE이 부여됩니다.
그런 다음 사용자가 URL을 접속 할 때에 해당 URL에 매칭되는 ROLE을 비교하는 형태입니다.
만약 manage/*.do 패턴에 대하여 2개가 순서적으로 붙어 있었다면,
사용자 접근 시 로그 정보가
URL: /manage/bbb.do; ConfigAttributes: [ROLE_ADMIN1,ROLE_ADMIN2]
형태로 처리되어 접근이 가능하도록 처리되었을 것입니다.
순서 및 데이터 확인 부탁드립니다.
해당 패턴 자체가 매핑이 2개의 ROLE로 되어 있는 경우 무조건 순서가 붙어있지만, 패턴 자체가 2개되어 각각 다른 ROLE에 매칭된 경우는 sort order에 의해 순서가 붙어있지 않을 수 있습니다.
그럼, 즐거운 하루되십시오.
감사합니다.
DEF_ROLES_AND_URL_QUERY에 의해 조회된 데이터는 매칭을 위하 사용하는 것이 아니라
URL 패턴별로 할당된 ROLE을 찾는 것이라 끝까지 처리됩니다.
즉, 사용자가 URL을 접근할 때에 비교하는 부분의 처리가 아니라 처음 초기화 될 떄에 URL 패턴에 대하여 할당된 ROLE을 지정하는 것입니다.
이 부분은 내부적인 처리에 의해 동일한 패턴이 있는 경우 순서적으로 같이 나와야 하나의 패턴에 여러 ROLE이 부여됩니다.
그런 다음 사용자가 URL을 접속 할 때에 해당 URL에 매칭되는 ROLE을 비교하는 형태입니다.
만약 manage/*.do 패턴에 대하여 2개가 순서적으로 붙어 있었다면,
사용자 접근 시 로그 정보가
URL: /manage/bbb.do; ConfigAttributes: [ROLE_ADMIN1,ROLE_ADMIN2]
형태로 처리되어 접근이 가능하도록 처리되었을 것입니다.
순서 및 데이터 확인 부탁드립니다.
해당 패턴 자체가 매핑이 2개의 ROLE로 되어 있는 경우 무조건 순서가 붙어있지만, 패턴 자체가 2개되어 각각 다른 ROLE에 매칭된 경우는 sort order에 의해 순서가 붙어있지 않을 수 있습니다.
그럼, 즐거운 하루되십시오.
감사합니다.