•  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
더 보기
0 역링크 토론 편집 역사 ACL

ACLGroup

분류
1. 개요2. 목록
2.1. 차단된 사용자(★)2.2. 우회수단
2.2.1. VPNGate2.2.2. 로그인 허용 차단2.2.3. IDC
2.3. 편집요청 차단2.4. 소명 거부2.5. 권한 요청 거부(★)
2.5.1. 중요 권한 요청 거부(★)
2.6. 인증된 사용자(★)2.7. 관리자(★)
3. ACL의 허용규칙4. 관련 문서

1. 개요[편집]

더시드위키의 ACL 그룹에 대한 설명이다. 2024년 2월 25일 기준 존재하는 ACL 그룹에는 ★로 표시

2. 목록[편집]

https://theseed.io/aclgroup
admin 권한이 없는 이용자도 ACL 페이지 자체는 열람할 수 있다. 다만 기본적으로 존재하는 ACL 그룹의 열람이 불가능하며, 이는 나무위키 등의 다른 더시드 계열 위키도 마찬가지.
예를 들어 나무위키는 차단된 사용자, VPNGate, IDC, 로그인 허용 차단의 ACL 그룹을 열람할 수 없다.

aclgroup 권한이 없으면 ACL 그룹의 생성과 삭제가 불가능하다.

2.1. 차단된 사용자(★)[편집]

더시드 계열 모든 위키에 있는 기본 ACL 그룹. 삭제가 불가능하다. 차단된 사용자 ACL에 있는 경우 편집 내역이나 토론 스레드에 적힌 아이피나 닉네임에 취소선이 붙는다.
  • 예시
    • 8.8.8.8(아이피)
    • PPPP(사용자)
    • namu(admin 권한 사용자)

admin 권한만 보유하고 있을 시 이 ACL 그룹에만 추가가 가능하며 aclgroup 권한만 보유하고 있을 시에는 이 ACL 그룹에 추가할 수 없다.

2.2. 우회수단[편집]

아이피 전용 ACL이다. 해당 ACL 그룹 사용자 거부를 로그인 사용자(perm:member) 허용보다 뒷순위에 배치하기 때문에 로그인된 사용자에 해당 ACL을 추가한다고 해서 달라지는 건 없다. 더시드위키에서는 거의 사용되지 않는다.

2.2.1. VPNGate[편집]

말 그대로 VPNGate로 분류되는 아이피를 모아놓는다. 나무위키에서는 해당 ACL에 추가된 아이피가 노란색으로 변한다.

2.2.2. 로그인 허용 차단[편집]

통신사 아이피나 반달이 빈번하여 로그인해야 사용할 수 있는 아이피는 여기에 배치한다. 다른 우회수단 ACL과 달리 로그인하면 아무 문제 없고 비로그인 상태에서의 편집 요청은 가능하다는 것이 특징.

2.2.3. IDC[편집]

IDC 대역도 우회수단으로 사용되어 나무위키에서는 우선적으로 차단한다. VPNGate처럼 아이피가 노란색으로 표시되나 약간 다르다고 한다.

2.3. 편집요청 차단[편집]

편집요청 권한을 없애 편집요청을 하지 못하게 한다. 차단된 사용자와는 달리 기본적으로 있는 ACL 그룹이 아니며, 따로 설정해 주어야 한다.

2.4. 소명 거부[편집]

더시드위키에만 있는 ACL 그룹. 더시드위키:차단 소명 게시판의 토론 발제 및 댓글 권한을 제한시켜 차단 소명을 하지 못하게 한다.

2.5. 권한 요청 거부(★)[편집]

더시드위키에서 테스트 권한 남용, 아무런 추가 근거 없이 거부된 권한을 반복적으로 요청하는 등의 이유로 이 그룹에 추가될 수 있다. 더시드위키:권한 요청 문서의 토론 발제 권한을 제한시켜 권한 요청을 하지 못하게 한다.

2.5.1. 중요 권한 요청 거부(★)[편집]

해당 그룹에 추가된 사용자는 중요 권한(nsacl, login_history, aclgroup)을 부여받을 수 없다.

2.6. 인증된 사용자(★)[편집]

에 대한
자세한 내용은 더시드위키:인증 요청 문서를 참고하십시오.

더시드위키 내 잦은 반달로 인해 해당 그룹에 추가된 사용자만이 더시드위키에서 활동 할 수 있다.

2.7. 관리자(★)[편집]

정식 관리자와 다른 권한이 있는 이용자를 구분하기 위한 ACL이다. 일부 문서는 이 ACL에 추가되어 있는 사용자만이 편집 혹은 토론 발제가 가능하다.

3. ACL의 허용규칙[편집]

참조 문서 : ACL 용어

먼저 문서의 편집, 문서의 이동 등 특정 위키행위에 접근하려는 이용자가 있으면 이용자가 소속되는 ACL그룹들이 무엇인지를 알아야 한다. 가령 로그인된 이용자의 경우 perm:any, perm:member에 소속되며 perm:ip에는 소속되지 않는다. 집합과 원소의 관계로 보자면, 로그에 기록될 수 있는 이름을 모두 모아놓은 한개의 전체적인 집합을 생각해볼 수 있는데 이 때 ACL그룹들은 각기 "집합(부분집합)"이 된다. 이런 '집합'은 기본적으로 perm:member[1]과 같이 시스템상 특정 규칙에 따른 (조건제시법) 집합이거나, 필요에 따라 이름을 짓고 소속할 대상을 원소로 추가함으로써 (원소나열법) 개설되는 집합이 된다. 접근하려는 이용자는 각 ACL집합의 원소가 되는지 아니한지를 볼 수 있다.

이를 이용하여 ACL그룹(집합)을 언급하는 모종의 허용규칙을 만들 수 있다. 만일 규칙이 하나도 존재하지 않으면 어느 이용자라도 행위의 접근이 거부된다.[2] 이용자가 행위에 접근하게 되면 규칙에 기입된 ACL 그룹의 순서대로 대조된다. 대조하면서 규칙에서 지정된 ACL그룹에 접근하려는 이용자가 소속되는지 되지 않는지[3]를 보게 된다.

소속되는 경우, 해당 그룹(집합)에 해당되는 이용자의 접근을 허락하(allow)[4]거나 거부하(deny)는 처리 규칙에 따라 접근하려는 이용자가 특정 위키행위에 대한 접근 허가 또는 거부가 결정된다. 먼저 허용 또는 거부로 결정되면 앞에서 결정한 사항과 반대되는 결정을 아무리 많이 적어놓아도 앞의 결정된 ACL에는 영향을 주지 않는다. (이로 보자면 규칙 내 그룹 언급은 일종의 필터링처럼 적용된다.)

소속되지 않는 경우, 다음 목록으로 지정돤 ACL 그룹과 그에 따른 규칙에 대조된다. 모든 규칙을 대조했을 때 (특정 ACL그룹에 대하여) 거부하는 규칙이 없다 하더라도 최종적으로 이용자가 그 어느 지정된 ACL 그룹에도 소속되지 않는다면 이용자의 접근이 거부된다.
  1. 문서 ACL 허용규칙의 유무.
    1. 있는 경우 : 기입된 순서대로 대조가 시작된다. 걸리는 규칙에 따라 접근의 허용 또는 거부가 결정된다. 거부 규칙이 없어도 최종적으로 어느 허용 목록에도 해당되지 않는 경우 접근이 거부된다.
    2. 없는 경우 : 네임스페이스 ACL 규칙이 적용된다. 문서 ACL 란에 "규칙이 존재하지 않습니다. 이름공간 ACL이 적용됩니다."라는 문구가 나온다.
  2. 네임스페이스 ACL 허용규칙의 유무.
    1. 있는 경우 : 문서 ACL처럼 기입된 순서대로 처리된다. 먼저 걸리는 규칙에 따라 접근의 허용 또는 거부가 결정된다. 거부 규칙이 없어도 최종적으로 어느 허용 목록에도 해당되지 않는 경우 접근이 거부된다.
    2. 없는 경우 : 모든 이용자의 접근이 거부된다. 이름공간 ACL 란에 "규칙이 존재하지 않습니다. 모두 거부됩니다."라는 문구가 나온다.

없는 ACL 그룹에 대하여 허용규칙을 넣으려 할 시 invalid_aclgroup이라는 오류 메세지가 출력된다. aclgroup 권한을 이용하여 강제로 해당되는 이름으로 만든 다음 허용규칙을 넣는 일은 가능은 할지도.

4. 관련 문서[편집]

[1] perm:member={x∣x is a member}=\left\{x|x \text{ is a member}\right\} (조건제시법)[2] 아무래도 접근이 허용되는 이름의 목록이 없는 상태(=∅=\empty)에서 시작해서 포함배제 과정을 거치는 모양.[3] 이용자∈\in(지정된 ACL 그룹) 이 성립하는지 아니하는지[4] 겉보기에는 ⊃\supset(지정된 ACL 그룹) 같겠지만 다르다.