[TIL] 20240604 77일차

base.html 공통 기능 논의 / 앞으로 할 일 논의

[기술적 의사결정]

 

base.html 공통 기능 논의

로그인이 필요한 컨텐츠인 경우 모달창 출력하도록 하기 (별점 모달창 응용) -> base.html, base_no_search.html 모두 적용하기

-> 적용 완료 ( setModal() )

aSend 공사

• header 옵션 넣을 수 있게
• response.status로 분기 처리 -> 성공 관련 코드(2xx)일 경우 return await response.json() -> 실패 관련 코드(4xx)일 경우 error 메시지를 따로 전달하는 경우 모달창으로 처리 or console.log 찍을 수 있게 -> 서버 실패 관련 코드(5xx)일 경우 console.log로 보일 수 있도록 --> base.html, base_no_search.html 모두 적용하기

-> 보류 (우선순위 후순위): 이미 커스텀이 필요한 부분은 fetch로 작성해서 정상 동작이 되고 있음. 시간 여유가 생기면 리팩토링하면서 고려할 것

Footer

• contact us 내용이 들어가는 footer를 base.html에 포함시키기

→ 적용 완료

앞으로 할 일 논의 (6 / 5)

• [ ] 메인 메뉴판(태그 모음) 만들기
• [ ] 게임 디테일 페이지 수정 -> 스크린샷만 사라짐(요건 확인해보기 남기는것)
• [x] 게임 디테일 페이지 수정 -> 검수 완료를 제외한 다른 상태일 때 게임 플레이 영역을 다르게 표시하기
• [ ] 회원가입 페이지 -> 제한 조건을 상세하게 표시 (특히 비밀번호 조건)
• [ ] PostgreSQL migration

 

게임 디테일 페이지 수정/삭제 버튼 구현

[오류 개선]

 

수정 / 삭제 버튼 구현

버튼 요소의 style 속성 display: none/block 으로 버튼의 보이는 여부를 컨트롤했는데

이렇게 하면 사용자가 악용해서, 개발자 도구로 html 상에서 속성을 조작하면 분명 그 유저가 사용할 수 없는 기능임에도 사용할 수 있게 되는 문제가 있다.

따라서 JS로 권한이 있는 사용자일 경우에만 요소를 직접 생성해서 보여줘야, 권한이 없을 경우에는 해당 요소를 html 상에서 확인할 수 없다.

이렇게 해도 Script 태그 안에 있는 함수를 확인해서 브라우저 콘솔로 함수를 실행해볼 수도 있다. 그래서 백엔드에서도 해당 사용자가 정말 권한이 있는지 이중으로 체크를 해서 권한이 없다면 400번대 응답 코드를 response 한다. 프론트, 백 모두에서 이중 삼중으로 체크해야 하는 이유가 여기에 있다.

 

 

6월 4일자 hotfix

[오류 개선]

 

게임 디테일 페이지 ‘텍스트 영역’ 누락된 부분 수정

 

기획에 게임 설명을 표시하는 텍스트 영역을 배치해뒀는데

텍스트 영역을 보이게 하는 작업을 누락했다. hotfix로 수정했다.

base.html, base_no_search.html 의 navbar의 불필요한 카테고리(버튼) 삭제

bootstrap의 html 태그들을 그대로 가져와서 사용했다보니 navbar에 프로젝트에서 사용하지 않는 항목들이 표시되고 있었다. 이들을 삭제했다.

검색 페이지에서 gm_q 옵션이 제대로 동작하지 않았던 점 수정

검색 페이지에서 ‘게임+작성자’ 옵션으로 검색을 진행했을 때 이미 삭제처리된 글이나(is_visible=false) 등록 대기중or등록 거부 상태(register_state≠1) 글들이 목록에 같이 보여지는 문제가 있었다. 확인해보니 api view 함수에서 gm_q 쿼리스트링에 대한 처리로 filter를 걸어주는 부분에서 register_state=1 과 is_visible=True 조건이 누락되어있어서 이를 수정했다.

게임 디테일 페이지 댓글 부분 수평선 누락된 부분 해결

 

 

6월 4일자 기능 구현/수정한 부분

[기능 구현]

 

게임 디테일 페이지에 있던 formatTime() 함수를 base.html 및 base_no_search.html로 옮겨서 해당 템플릿을 상속받는 템플릿이면 formatTime() 함수를 사용할 수 있도록 하였음

formatTime() 함수는 api 응답으로 받은 데이터 중 created_at 과 같은 datetime 타입의 데이터를 보기 좋게 변환해주는 함수이다.

base.html의 formatTime()을 이용해서 게임 디테일 페이지와 유저 프로필 페이지의 시간 데이터 보여주는 부분을 보기 좋게 변경했다.

유저 프로필 페이지에서 데이터를 table 요소를 이용해서 정렬해서 보여주게 했고, 데이터 중 게임 제목과 제작자 이름을 클릭하면 각각 해당 게임 디테일 페이지로 이동하거나 제작자의 프로필 페이지로 이동하도록 구현했다.

유저 프로필 페이지에서 내가 등록한 게임 목록을 볼 때 검수 중 및 검수 거부 상태인 게임의 디테일 페이지를 확인할 수 있도록 했는데, 해당 디테일 페이지를 로드할 때 검수 완료 상태가 아니면 게임 빌드 파일(gamepath)을 서버에 저장하지 않았기 때문에 게임 플레이 영역에 404 에러 페이지가 보였다. 따라서 게임 플레이 영역이 검수 완료 상태가 아니면 ‘서비스 준비 중입니다’ 라는 글씨가 있는 회색 영역으로 표시하도록 변경했다.

 

 

AWS RDS PostgreSQL migration

[기능 구현]

 

Amazon RDS 에서 새로운 데이터베이스를 생성

데이터 생성 방식을 선택할 때 ‘표준 생성’ 옵션을 선택해야 데이터베이스 이름을 설정할 수 있다. ‘손쉬운 생성’ 선택 시 데이터베이스 이름을 설정할 수 없어 DB에 접근하기가 어렵다.

데이터베이스를 생성한 후, AWS EC2 인스턴스를 하나 새로 생성해서,

해당 인스턴스에서 프로젝트 파일을 git clone 한 뒤에

PostgreSQL 데이터베이스로 연결할 수 있도록 settings.py에 아래와 같이 내용을 작성했다.

# Database
# <https://docs.djangoproject.com/en/4.2/ref/settings/#databases>

# DATABASES = {
#     'default': {
#         'ENGINE': 'django.db.backends.sqlite3',
#         'NAME': BASE_DIR / 'db.sqlite3',
#     }
# }
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'HOST': config.DATABASES["host"],
        'PORT': config.DATABASES["port"],
        'NAME': config.DATABASES["database"],
        'USER': config.DATABASES["user"],
        'PASSWORD': config.DATABASES["password"],
    }
}

중요한 내용들은 config.py에 정의했다.

위와 같이 설정 후에, 필요한 패키지들을 모두 설치하고,

python3 manage.py migrate를 통해 프로젝트에 있던 migration 파일들을 이용하여 PostgreSQL 데이터베이스에 테이블들을 생성했고

ubuntu로 PostgreSQL 데이터베이스에 접속해서 \d로 생성된 테이블 목록을 확인하는 것까지 완료했다.

앞으로 해야 할 작업:

• nginx - postgreSQL 연결 작업
• 배포 서버에서 postgreSQL을 어떻게 접근해야 하는지 알아야 함
• 위 2가지 해결이 어려울 경우 튜터님께 도움받을 예정