테스트 계정 이메일 : [email protected]
테스트 계정 비밀번호 : test1234
※ 개발 중인 모듈 전체를 첨부파일에 첨부함
1. 아래와같이 간단한 form을 만들었습니다.
2. 생성 버튼을 누르면 "procCreateProject" action으로 전송되도록 하고, "createProjct" 라는 ruleset을 적용했습니다.
<form ruleset="createProject" action="/" method="post">
<input type="hidden" name="module" value="btb_smart_flow" />
<input type="hidden" name="act" value="procCreateProject">
<input type="hidden" name="success_return_url" value="{getRequestUriByServerEnviroment()}">
<input type="hidden" name="xe_validator_id" value="modules/btb_smart_flow/createProject">
<input type="text" name="projectName" title="{$lang->projectName}" required>
<input type="submit" value="{$lang->cmd_make}">
</form>
<action name="procCreateProject" class="Controllers\Projects" standalone="false" permission="member" ruleset="createProject" />
3. /modules/모듈명/ruleset/createProject.xml 경로에 룰셋 파일을 생성했습니다.
<?xml version="1.0" encoding="utf-8"?> <ruleset version="1.5.0"> <fields> <field name="projectName" required="true" rule="alpha_number"> </fields> </ruleset>
4. 컨트롤러에도 적절한 더미 코드를 작성했습니다.
public function procCreateProject()
{
$this->setMessage('success_registed');
$this->setRedirectUrl(Context::get('success_return_url'));
}
5. 다른 모듈들과 xe 메뉴얼을 최대한 참고하여 위 단계까지 완료했습니다.
6. 제가 원하는 것은, form 내부의 "projectName" input에 "alpha_number" 룰셋이 작동하길 원합니다.
7. 룰셋에 위배되는 값을 넣고 submit을 실행하면 룰셋에 차단되지 않고 컨트롤러 메소드가 바로 실행됩니다.
▼
8. 어떻게 하면 룰셋을 적용할 수 있을까요?
혹시 룰셋이 deprecated 되었나요?
1. 룰셋 XML 파일의 5번째 줄에 /> 태그가 닫히지 않아서 제대로 인식하지 못하는 것이 아닐까 생각됩니다.
2. 위의 문제와는 별개로, XML로 정의한 룰셋이나 필터에 의존하는 것은 권장하지 않습니다.
룰셋이 없다면 룰셋에 의존하는 오래된 자료에 보안취약점이 발생할 수도 있기 때문에, 라이믹스에서 룰셋 지원을 중단하게 될 가능성은 무척 낮습니다. 그러나 신규 자료에서는 룰셋을 사용하지 마시기 바랍니다.
룰셋으로 표현할 수 있는 규칙에는 근본적인 한계가 있습니다. 기본적인 형식만 검증할 수 있고, "A가 B인 경우 C는 D여야 하고, 그렇지 않다면 C는 E와 같지 않아야 한다. F는 로그인 사용자인 경우 G여야 하지만, 관리자는 예외로 한다."와 같이 복잡한 조건을 선언할 수도 없습니다. 예전에는 룰셋에서 eval을 사용할 수도 있었지만, 이제는 그것도 곤란하고요. 심지어 위와 같이 룰셋을 잘못 작성하더라도 오류가 나지 않고 그냥 패스하는 흠좀무한 작동 방식입니다.
이런 한계 때문에 많은 자료들이 일부 변수는 룰셋으로, 나머지 변수는 컨트롤러에서 PHP로 검증하는 어정쩡한 방법을 사용하게 되었습니다. (게다가 module.xml에도 변수를 체크하는 기능이 있어요...) 보안과 직결되는 기능이 이렇게 여기저기 흩어져 있으면 코드 리뷰할 때 문제가 될 만한 경우의 수를 캐치하기가 무척 어렵습니다. 한 눈에 들어오지 않으니까요. 처음부터 100% PHP로 작성했어야 하는 로직을 굳이 XML로 만들어서 오히려 해를 끼치는 사례입니다. CMS나 프레임워크의 보안성이라는 것은 자기 코드만 잘 쓴다고 되는 것이 아니라, 사용자가 올바른 코딩 습관을 들이도록 돕고, 올바르지 않은 코드가 쉽게 눈에 띄도록 하는 것까지 포함하는 광범위한 개념인데 말이지요.