En~MoniWiki › MoniWikiDiscussion › MoniWiki/AccessControl
모니위키는 여러가지 방식으로 사용자의 권한을 조절할 수 있다.
chmod ¶
가장 기초적인 페이지 권한 조정 방식 ?action=chmod를 이용하여 페이지의 권한을 조정할 수 있다.
이 방식은 간단히 파일 권한을 조정하는 방식이므로 제일 간단한 구현이다.
SecurityPlugin ¶
chmod 방식은 개개의 페이지 파일에 대한 권한 조정방식인 반면 SecurityPlugin은 페이지에 대한 여러가지 액션의 권한을 조정한다.
여기서 액션이라 함은 ?action=info, diff 등등을 말한다.
위키위키에서의 권한 ¶
위키위키가 최초 창제되었을 무렵. 위키앞에서 만인이 평등했다. 모든 사람이 어떠한 페이지라도 지울 수 있었고 만들 수 있었다.
위키위키를 제약하는 것은 위키즌의 암묵적인 에티켓과 인간의 지성이었다.
그러나 인터넷이 더욱 널리 사용되게 되자 위키위키에 여러가지 안전장치가 필요해졌다. 그리하여 페이지 히스토리를 보관하는 장치가
고안되고, 위키즌의 권한을 제한할 수 있도록 하고 위키 관리자의 권한이 강화되게 된다.
이렇게 되어 결국은 위키위키의 원래 탄생의도와는 다르게 위키사용자의 권한이 점점 제한되는 방식으로 흐르게 된다. 안전장치는 강화되었지만
오히려 사용자의 권한과 권리도 축소되게 된 것이다.
모니위키도 처음 만들어졌을 때부터 어떻게 하면 위키위키의 철학을 해치지 않고 위키위키를 실현할 수 있을까 하는 고민을 거듭하고
있었으나, 최근에는 읽기마져 제어 가능하도록 바뀌어졌다.
이것은 모니위키의 원래 만든 목적이 개인사용자의 편이성에 있었기 때문에 위키위키의 철학과 충돌하는 부분이었지만, 과감히 사용자의
요구를 선택한 까닭이다.
Bug reports ¶
사용버전: 1.0.2, 1.0.1 ...
chmod 액션이 제대로 되지 않습니다. 권한을 양쪽다 끌 수 없고, 한쪽만 끌 수 있습니다. 그래서, 읽기권한을 꺼 두었을 때 
EditText로 페이지를 고칠 수 있게됩니다. 고치면 RecentChages에 새 페이지로 등록되고, 나중에 읽기권한을 켠 다음에는 다시 내용을 복구를 해야합니다. 양쪽다 끌수 있거나, 읽기 권한을 끄면 자동으로 쓰기 권한도 끄게 해야한다고 생각합니다. --kebil
EditText로 페이지를 고칠 수 있게됩니다. 고치면 RecentChages에 새 페이지로 등록되고, 나중에 읽기권한을 켠 다음에는 다시 내용을 복구를 해야합니다. 양쪽다 끌수 있거나, 읽기 권한을 끄면 자동으로 쓰기 권한도 끄게 해야한다고 생각합니다. --kebil
chmod는 매우 저자동성의 액션입니다. 유닉스의 chmod와 완전히 동등합니다. 말씀하신 것도 유닉스에서 작동방식과 일치합니다. 좀 더 고급의 제어를 원하신다면 chmod를 사용하지 마시고 입맛에 맞는 SecurityPlugin을 설정해보세요. -- WkPark 2009-01-10 03:02:18
Discussion ¶
![/!\](/imgs/smile/alert.png "/!\")
아래 내용은 모니위키 1.0.x에 관련된 토론입니다.
이번에 끄적끄적 위키 설치하려고 돌아다녀보니 MoniWiki가 마음에 들더군요. 그래서.. 버그 리포팅입니다. -_-; --임현택
.png ":)")
기본적으로 읽기 (read 혹은 show)는 security 플러그인을 통과하지 않습니다. 즉, 읽기는 모두 가능하다는 뜻이지요. 읽기마저 안 되게 만드는 것은 위키위키의 정신에 위배된다고 생각했으므로, 그것마져 막을 수 있게 해놓지는 않았습니다. 물론, AccessControl이 필요한 경우가 있고 지원할 계획도 있습니다만, 개인위키를 목표로 했기 때문에 우선순위가 낮습니다. --WkPark
- action이 ""이거나 "show"이면 security plugin을 거치지 않고 무조건 action이 허용됩니다. 이 action도 plugin에서 조절할 수 있으면 좋겠습니다. wiki.php:2856
- 여러 기본 security plugin의 함수들에서 $action="read"라는 말이 나오는데, 혹시 $action="show"가 아닌지요?
기본적으로 읽기 (read 혹은 show)는 security 플러그인을 통과하지 않습니다. 즉, 읽기는 모두 가능하다는 뜻이지요. 읽기마저 안 되게 만드는 것은 위키위키의 정신에 위배된다고 생각했으므로, 그것마져 막을 수 있게 해놓지는 않았습니다. 물론, AccessControl이 필요한 경우가 있고 지원할 계획도 있습니다만, 개인위키를 목표로 했기 때문에 우선순위가 낮습니다. --WkPark
저같은 경우에 개인 홈페이지를 만들려고 쓰는데요, 완전히 열린 sandbox/guestbook, 긴 내용을 담고 있어 로그인한 사람만 고칠 수 있는 글들, 저만 보고 고칠 수 있는 개인 글로 나눠보려고 했거든요. 저는 일단 소스를 고쳐서 써야겠네요. 서버에서 url을 보고 막을 수는 없는 난감한 구성이라서요. (나중에 추가:) 생각해보니 backup action + uploaded files action 같은 부분 때문에 개인 글 유지가 힘들겠군요. 아예 위키를 분리하지 않으면.
read를 제외한 모든 action은 security plugin으로 제어할 수 있습니다.
혼자만 볼 수 글이라면 개인 위키에 올리지 마시고 StandaloneWiki를 고려해 보세요.
소스상으로 $action이 없는 경우는 $action=read라고 생각을 하므로, 다음과 같이 몇 줄 추가하고 security 플러그인을 자신에 맞게 고치면,
혼자만 볼 수 글이라면 개인 위키에 올리지 마시고 StandaloneWiki를 고려해 보세요.
소스상으로 $action이 없는 경우는 $action=read라고 생각을 하므로, 다음과 같이 몇 줄 추가하고 security 플러그인을 자신에 맞게 고치면,
#wiki.php에서 다음 줄을 찾아서 추가.
+ if (!$DBInfo->security->is_allowed('read',&$options)) {
+ do_invalid($formatter,$options);
+ return;
+ }
#$formatter->get_redirect();
$formatter->pi=$formatter->get_instructions();
이러한 방식으로 소스를 고쳐서 read를 security 플러그인으로 제어할 수는 있지만 TWiki의 AccessControl과 같이 웹상에서 사용자별로 세밀하게 제어할 수 있는 기능을 넣지 않는 이상 쉘상에서 소스를 고치가나 config.php를 수동 편집하는 방법을 써야 되겠지요. AccessControl을 제대로 지원하게 될 시점에서 이 문제는 자연히 사라질 것입니다만, AccessControl을 편리하게 지원하려면 ??? --WkPark
조금 위험한 방법이지만 개념적으로 살펴주세요: 어떤 특정 wiki 글 안에 여러 rule이 들어있도록 해서, 웹으로 그 글을 편집하면 권한 수정이 가능하도록 하는 방법이요. 포맷이 깨져서 security 플러그인이 Control 규칙을 인식하지 못할 수도 있다는 것이 문제입니다만, 권한 추가/삭제/변경은 마치 blog를 moni에서 쓰듯이 macro+action을 통해서만 한다면 다소 나아지겠고.. 그외 문제는 1.속도가 다소 느리다 2.권한 지정 권한의 분산이 까다롭다 3.??? --임현택
last modified 2009-01-10 03:02:18
Processing time 0.1016 sec