Django 글쓰기 권한: staff 검사와 저장·공개 흐름 분리

관리자 화면 밖에 글쓰기 화면을 만든 이유

초기에는 Django 관리자에서 글을 작성했다. 이후 제목·카테고리·본문·태그·썸네일을 한 흐름에서 다루고 싶어 별도 작성 화면을 만들고, 사이드바에 관리·글쓰기 진입점을 추가했다. 당시 본문 편집에는 Toast UI를 사용했다. 현재는 별도의 v2 편집기가 있어 당시 화면과 입력 방식이 달라졌다.

화면을 옮기면서 먼저 확인한 것은 작성 권한이다. 개인 블로그에서 방문자가 글을 읽는 권한과 운영자가 글을 저장하는 권한은 분리돼야 한다. 메뉴에서 글쓰기 버튼을 숨기는 것만으로는 직접 URL에 접근하거나 저장 요청을 보내는 일을 막을 수 없다.

로그인 여부와 운영자 여부는 다른 조건이다

현재 저장소의 글쓰기 뷰는 staff_member_required로 보호한다. 이 데코레이터는 활성 상태이면서 staff인 사용자에게 뷰 실행을 허용하고, 조건을 만족하지 않으면 로그인 화면으로 보낸다. 특정 모델의 추가·수정 권한을 따로 검사하는 기능과는 구분된다. Django 공식 설명

현재의 핵심 구조를 줄이면 다음과 같다. 아래 코드는 권한 검사의 위치를 보여주는 설명용 예시이며 실제 저장 처리는 생략했다.

from django.contrib.admin.views.decorators import staff_member_required

@staff_member_required
def content_write_v2(request):
    # GET 화면과 POST 저장 요청 모두 이 검사 뒤에 처리한다.
    ...

화면뿐 아니라 저장 요청도 확인하기

2026년 9월 21일 코드에서 /manager/posts/write-v2/의 GET과 POST는 같은 뷰를 사용한다. 편집 화면, 기존 글 수정, 미리보기에도 staff 검사가 붙어 있다. 예전 /write/ 경로 역시 별도 검사 대상이다. 새 작성 화면만 보호하고 이전 주소를 남겨두면 우회 경로가 될 수 있기 때문이다.

점검할 때에는 로그인하지 않은 상태, 일반 회원, 활성 staff를 나눠 본다. 비로그인·일반 회원의 화면 접근과 저장 POST는 로그인 주소로 돌아가야 하며 글이 생성되면 안 된다. staff는 화면에 접근할 수 있지만 빈 제목 같은 입력은 저장 단계에서 거절돼야 한다. 이는 로컬 테스트로 확인할 수 있는 범위이며 운영 서버의 계정·프록시·세션 설정까지 대신 검증하지는 않는다.

CSRF 검사도 별도 역할을 한다. 현재 v2 화면은 저장 요청에 CSRF 토큰을 전달한다. staff 검사는 “누가 쓸 수 있는가”, CSRF 검사는 “이 요청을 허용할 수 있는가”를 다루므로 하나가 다른 하나를 대체하지 않는다.

작성 완료와 검색 노출을 분리하기

현재 v2 저장 뷰는 제목·카테고리·본문 존재와 요약 길이를 확인한 뒤 글을 저장한다. 본문은 에디터가 만든 HTML이며 이 경로의 content_markdown은 빈 값으로 저장된다. 예전 Markdown 입력 경로와 같다고 가정하면 수정 도중 본문 형식을 혼동할 수 있다.

색인 상태는 별도 입력이다. 새 글에서 값을 생략하거나 허용되지 않은 값을 보내면 noindex를 사용하고, 초안 상태인 글도 noindex로 처리한다. 공개 버튼을 눌렀다는 이유만으로 검색·광고 노출 검토까지 끝난 것으로 보지 않기 위한 구분이다. noindex는 접근 권한이나 비밀글 기능을 대신하지 않는다.

개인 운영에서 여러 작성자로 확장할 때

현재 구조는 staff가 글을 작성하는 개인 운영 방식에 맞춰져 있다. 여러 작성자에게 권한을 줄 때에는 본인 글만 수정 가능한지, 검토 전 공개를 막을지, 누가 색인 상태를 바꿀지 추가로 설계해야 한다. staff_member_required만 붙이면 이러한 역할 구분까지 자동으로 생기지는 않는다.

이번 기록은 글쓰기 화면의 접근·저장 경계를 설명한다. 썸네일 처리 과정은 게시글 이미지 선택 기록에, 브라우저 임시저장과 서버 저장의 차이는 신규 에디터 기록에 이어서 정리했다.