(03.20) 수정됨.
목표
1개 project에서 2개 이상의 사이트 구동하기
- 장고에서는 이미 The “sites” framework라는 것을 제공하고 있다. 그러나 이것은 1개 project를 설정을 달리해서 2개, 3개 실행해 다수의 사이트를 1개 project에서 관리할 수 있도록 하는 것이다. 내가 원하는 것은 1개 project를 실행해서 2개, 3개 이상의 사이트를 작동하게 할 수 있게 하는 것이다.
URL dispatcher
URL dispatcher를 살펴보면, 방문자에게 적용할 urlconf를 조작하는 것이 가능하다.
사이트마다 별도 urlconf를 작성하고, 접속 도메인에 따라 이를 변경할 것이다.
여기에 사이트별 database를 분리하는 것까지 한다면 통해 접속 도메인에 따라 노출할 내부 링크와 게시물을 물리적으로 나눌 수 있게 된다.
User model
multiple site를 1 app으로 운영하는 경우 가장 큰 문제는 User model이다.
User model 역시 사이트별로 나누어서 만들 수 있으나, 장고에서 User model을 지원하기 위해 AUTH_USER_MODEL 옵션에서는 1개의 User model만 연결이 가능하다.
물론 AUTH_USER_MODEL을 임의로 설정하고 사이트별로 이를 상속받는 별도의 abstract model...보다는 OneToOneField를 이용한 별도 프로필을 이용하게 하는 방법을 사용할 수는 있으나, 개인적으로 이런 방법은 관리 측면에서 번거롭다.
개인적으로는 사이트마다 별도 pk가 적용되는 것이 아니라는 점이 제일 거슬린다.
a 사이트에 10명의 user가 존재하면 b 사이트에는 1번째 user라고 하더라도 pk는 1이 아닌 11을 부여받게 된다.
아무런 문제가 없지만 그냥 거슬린다.
그 대신, 1개의 project에서 1개의 root domain을 사용한다는 가정 하에 1개 User model을 사용하게 만들고, 사이트별로 개별 프로필을 작성하여 사용할 수 있도록 하는 방법을 생각하고 있다. User model(default database) -> Profile model(site database) 같은 느낌.
구현
프로필은 얼추 구현이 되었다.
프로필 별도 구현보다 네이버 로그인 구현하는게 더 오래 걸렸다.
네이버에 제공하는 가이드 문서가 있긴 한데, 내용이 너무 쓸데없이 길어 내게 필요한 내용을 찾아야 하는 번거로움이 있고, 또한 예제가 당장 갖다 쓸 수 있는 것들이 아니었기 때문에 그것까지 반영하는데 시간이 걸렸다.
소셜 로그인의 경우 csrf protect가 어려운데, state로 전달하는 값을 세션에 보관하는 방식으로 처리했다.
차단, 메세지, 쪽지 기능
메세지, 쪽지 기능이 필요하다.
유저간 쪽지 또는 제재 등의 알림 용도로 사용하기 위함이다.
차단 기능 또한 추가하여 차단한 유저에게서는 메세지를 받지 않을 수 있도록 해볼 예정이다.
쪽지 기능
우선 쪽지 기능을 만들었다.
그냥 이대로 사용하면 쪽지와 알림을 1개 모델로 사용할 수도 있고, 쪽지와 알림을 별도로 분리하여 사용하는 것도 가능하다.
차단 기능
차단 기능도 얼추 완성했다.
이용자 제재 기능
이용자 제재 기능도 추가했다.
제재 중인 이용자가 로그인을 시도하는 경우, 이미지와 같이 제재 알림을 띄운다.
관리자인 경우, 최근 제재 기록을 조회할 수 있게 만들었다.
1:1 문의 기능 추가
관리자에게 1:1로 문의할 수 있는 문의 게시판 기능을 추가했다.
마지막으로 생성된 댓글 작성자의 관리자 여부를 통해 답변 여부를 확인할 수 있도록 하였고, 문의하기에 댓글이 달리면 문의자에게 알림이 가도록 설정했다.
게시물 신고가 가능한 필드를 모델 내부에 추가해두었기 때문에, 추후 신고 기능을 사용한다면 문의글이 작성될 수 있도록 해두었다.
게시글 기능 구현
게시판 기능 구현은 몇 번을 해도 어렵다.
단순히 글 작성, 조회만 있는게 아니라 댓글, 투표, 태그, 비밀번호, 조회 기준, 카테고리 등 연결된 부가 기능까지 관리해줘야 하기 때문이다.
기능 구현보다 이런 모델들을 어떤 식으로 구현하고 연결할지 고민하는게 시간을 엄청 잡아먹는다.
거기에 더해 라우터가 아니라 접속 도메인에 따라 사용하는 db를 구분하는 것이 정말 큰 난관이었는데, 이 경우 forms.py에서 어느 db를 봐야 하는지 구현해줘야해서 시간이 더 걸렸다.
특히 foreign key와 many to many field를 사용하는 경우 중심이 되는 model에서 사용하는 db가 아니라 라우터에서 정해진 db를 조회하려 하기 때문에 이것도 따로 구현해야했다.
일단 기본적인 글쓰기만 구현하고, editor와 댓글, 투표 기능을 추가하는 작업들이 남았다.
WYSIWYTG 에디터 적용 및 목록 템플릿 개선
html 위지위그 에디터를 적용하고, 목록 뷰를 개선했다.
최근에 작성되거나 수정된 글이 위에 노출된다.
변경 기록 조회 기능 추가
나무위키의 글 변경 역사 기능처럼 글을 수정하는 경우 기존 내용을 보관하도록 만들었다.
댓글 기능 추가
댓글을 달 수 있도록 기능을 추가했다.
댓글 역시 게시글과 마찬가지로 변경 로그를 보관하도록 만들었기 때문에 댓글 변경과 변경 기록 조회 기능을 구현해야 한다....
기능 자체는 심플한 것 같은데 구현은 왜이리 오래걸리는 것인지 모르겠다.
추천 비추천 기능 구현 + 답글 기능 구현
댓글에 답글(대댓글) 기능을 추가하고, 게시글과 댓글에 추천/비추천을 표시하도록 추가했다.
추천 카운트는 annotate를 사용하고 있는데, 희한하게 count시 distinct=True 옵션을 주지 않으니까 추천 수가 아니라 댓글 수를 카운트해서 추천수로 집계하는 현상이 발생했다.
찾아보니 장고의 고질적인 버그라는데.. 이거때문에 annotate 코드를 모두 찾아 distinct 옵션을 추가하는게 상당히 번거로웠다.
투표 기능 추가
투표 기능을 추가했다.
설정에 따라 복수 선택도 가능하게 했고, 투표 취소도 가능하게 만들었다.
신고 기능 추가
게시물 신고 기능을 추가했다.
신고 기능을 통해 글을 작성하면 문의가 작성된다.
장고에서 제공하는 ContentType을 활용해서 만들어보았다.
공지사항 기능 추가
공지사항 app을 추가해 공지사항 관리 기능을 추가했다.
context_processor와 base.html을 통해 공지사항 페이지가 아닌 페이지에서도 공지 목록이 노출되도록 했다.
포스트 기능 추가
포스트 directory를 추가했다.
근본은 게시판과 동일하지만, 공개시간, 외부 비공개 등 게시글에 별도의 속성이 추가되었다.
또한 글 목록에서 썸네일이 표시되도록 하였다.
검색 기능과 페이지네이션 추가
object를 여러개 생성하는게 귀찮아서 페이지네이션을 추가하지 않았었는데, 추가했다.
페이지네이션은 이동 가능한 페이지 리스트를 나열하는 것이 아니라 이전, 현재, 다음 페이지 버튼을 제공하고, 이동할 페이지를 입력해서 이동할 수 있는 것까지 2개를 제공하는 것을 적용했다.
조회수 기능 추가
조회수 기능을 추가했다.
모델 작성과 오브젝트 생성, 조회수 측정과 조회수 가져오기 작업이 너무나도 번거롭기 때문에 일단은 수치를 추가하는 것까지만 구현했다.
방문기록을 조회할 수 있는 페이지 구현은 아직이다.
방문 통계 기능 추가
방문통계 페이지 view를 구현했다.
통계 그래프에는 chart.js를 사용했고, 이런저런 방문 기록들을 정리해서 볼 수 있도록 해두었다.
부트스트랩 적용 및 사이트별 권한 관리 기능 추가
생각한 기능들은 얼추 만들어졌고, ui 개선과 기존 view 코드를 정돈하고 있다.
현재 프로젝트의 목표는 1개 프로젝트 구동으로 1개의 루트도메인 + 2개 이상의 서브도메인 운영이기 때문에 관리자 권한을 각 사이트마다 별도로 설정하도록 분리했다.
관리자 전용 게시판이나 익명 게시판, 특정 권한을 가진 회원만 접근 가능한 게시판 기능도 추가하고 싶은 욕심이 들긴 하는데.. 우선 코드 정리가 우선이다.
메세지 암호화
회원간 메세지(쪽지)는 db에 보관하기 전 암호화 처리를 하도록 변경했다.
ai한테 물어보니 일반적인 게시물이 아닌 1:1 쪽지는 개인정보 관련해서 법적 문제가 될 수도 있다고 했기 때문이다.
관리자라 하더라도 타인의 쪽지를 조회할 수 없도록 해두면 될 줄 알았는데, 생각해보면 찝찝했기 때문에 암호화처리를 하게 되다.
최근 개인정보 유출 사건으로 떠들썩한데, 보면 민감정보를 암호화하지 않고 보관하던게 더 큰 문제가 되고 있다.
또한 운영자가 쪽지 열람을 하고 이러한 사실을 들키거나 쪽지 내용을 외부에 공개(...)하는 경우도 실제로 존재하기 때문에 앞으로도 수신자 외의 쪽지 열람 기능은 구현하는 일은 없지을 듯 하다.
온라인 커뮤니티 '더쿠', 해킹 공격으로 아이디·비밀번호 등 개인정보 유출
'주민번호 암호화 미흡'…개보위, 롯데카드에 과징금 96억
아무튼 쪽지 관련 내용은 암호화처리를 했으니 db를 가져가더라도 복호화하지 않으면 내용을 확인할 수 없다.
약관 동의 기능 구현
로그인한 이용자가 약관에 동의하지 않은 경우, 약관 동의 페이지로 강제 이동(리다이렉트)하도록 했다.
이로써 약관에 동의해야지만 활동이 가능하도록 제한할 수 있게 되었다.
삭제 기능 구현
작성자의 삭제 요청이 있으면 게시물을 지워줘야 한다고 ai가 그래서 삭제 기능을 구현했다.
단, 게시물이 삭제된다고 해서 게시물 페이지에 접근하지 못하게 되는 것은 아니다.
게시물 모델과 게시물의 내용이 들어있는 내용 모델이 별도로 존재하기 때문에 내용 모델만 삭제하고 게시물 모델은 유지하는 형태로 구현했다.
내용 모델이 없으면 페이지 조회에 문제가 생기기 때문에 어떤 내용으로 삭제된 것인지를 기록으로 남기고, 그 내용을 볼 수 있도록 했다.
