잡담
정신없이 코딩하다보니 어느새 6일차가 되어있다.
항해를 시작하면 TIL을 해야지 해야지 해놓고 끝나면 바로 잠들기에 바빴다 ;;
처음 1일차에 내가 팀장이라는 사실에 너무 당황스러웠다. 내가 팀장이라니..
그래도 팀원분들 모두 열정 넘치시는 분들이라 수월하게 팀프로젝트를 진행 하였다.
지난5일동안 정말 많은 ERROR 녀석들을 만났고 해결해 나갔다.
오늘은 그간 있었던 심경을 나타내는데에 중점을 두기로 했다.
마주친 error
우선 제일 골치 아프게 했던 녀석은 바로 깃허브이다.
깃허브에 대한 기본적 지식이 없었고, 어중간하게 이해하고 있다보니
마스터 브랜치가 남아나질 않았다 ㅋㅋㅋ 그래도 어찌저찌 우리팀만의 전략을 세워서 하다가 완성되어갈 즈음에 결국 돌이킬 수 없는 마스터 브랜치가 되어버려서
결국 손수 Ctrl + c / Ctrl + v .. 손수 깃허브 역할을 해냈다!! 그후 팀원 모두 GitHub에 대해서 공부하기 시작했다 자세한 내용은 깃헙 게시판에 적었다.
다음으로는 AWS에 프로젝트를 올리면서
우리 코드 app.py 에
app.run(debug=True)
app.run('0.0.0.0', port=5000, debug=True)
이렇게 두줄로 들어가 있어서 서버가 열리질 않았다 .... 결국 팀원분이 하나씩 지워가면서 알아낸 해답은 위의
app.run(debug = True)를 지워주는 것이었다.
정말 행복했지만 허무했다.
이녀석 때문에 4명이서 몇시간을 헤맸는데!!
ERROR는 우리에게 희망을 보여주고는 절망을 안겨준다. 채찍과 당근을 잘 아는 녀석이다.
aws의 ubuntu 서버 환경으로 파일을 실행 했는데 우리가 만든 웹페이지의 환경이 제대로 동작하지 않았다.
정말 다들 절망에 빠져있을 때에 팀원 한분께서 우분투에
pip install pyjwt
위의 명령어를 입력 해보라고 하셨다. 아!!!! 이걸 왜 까먹었을까
로컬 파이참 환경에서 Python Interpreter 를 이용해 JWT를 다운받았었는데
그걸 똑같이 ubuntu에서 pip install 을 통해 해야한다는것을 까먹고 있었다.
이런!
마지막으로
프로젝트를 제출하여 다른 사람들도 서버에 접속할 수 있게 되었는데,
악성 유저가 나타났다!
우리 웹사이트의 취약점을 제대로 공략해 스크립트를 심어버렸다 ㅋㅋㅋ
다 끝내고 자려 했는데 팀원분의 긴급 호출로 핫픽스를 진행했다.
메인페이지에 들어가자마자 alert이 뜨면서
'하하 멍청한 관리자놈!'
이라는 문구가 뜨는게 아닌가.. DB를 찾아보니
입력란에
<script> alert('하하 멍청한 관리자놈!!')</script>를 넣었는데 이게 그대로 db에 저장된 모양이다.
입력란에 특수문자 제한기능을 넣고 사건은 마무리 되었다ㅋㅋㅋ
기분이 나쁘면서도 완성도를 높일 수 있게 되어서 고맙고 재밌었다.
이것 외에도 정말 많지만,
잊지 못할만한 1조의 위기 순간들을 꼽아서 적어봤는데 너무 길어졌다.
느낀점
너무 피곤하고 내가 초췌해지고 있다는것을 느끼지만,
이번 1주차 팀프로젝트를 하면서 GatherTown을 이용했는데 생각보다 유용했고 재밌었다. 팀원분들을 잘 만난덕에 더 그렇게 느낀것 같다.
---수정 7일차
마지막 주를 마무리 하면서 이번 프로젝트 구현에 있었던 JWT 기능과 API 에 대해서 간단하게 다뤄보려 한다.
JWT란.
JSON Web Token 의 줄임말이다.
로그인 기능에서 요긴하게 사용 했었는데, 로그인 했을 때 서버에서 토큰을 넘겨받아 회원을 특정하는데에 사용되었다. 그 토큰 값은 특정한 사용자만 부여받을 수 있는 값이기 때문에 다른 사용자는 받을 수 없다.
API
우리는 이번 프로젝트에서 HTTP 프로토콜을 이용해서 서버에 데이터를 요청하였다.
REST API는 POST, GET, PUT, DELETE 가 있는데
우린는 POST 와 GET 을 사용하였고
그 둘을 설명하자면
GET 방식
데이터를 요청할때 요청하는 데이터가 url에 담겨서 전송된다. 그래서 전송 요청시 url 상단에 ? 뒤에 데이터가 붙어 request를 보내는 것이다.
예를 들어 구글의 날씨에 대한 데이터를 요청할 때 검색 엔진에 이를 검색해보면 url에는 https://www.google.com/search?q=오늘의 날씨
라고 뜬다. 따라서 이러한 방식은 url 공간에 그대로 데이터가 담기기 때문에 보낼 수 있는 데이터 크기 자체가 제한적이고, 보안측면을 고려해야 되므로 각각의 상황에서 GET 방식은 적절하지 않을 수 있다.
POST방식
GET과는 다르게 body부분에 데이터를 담아 전송한다. 따라서 GET과는 달리 제한적인 크기, 보안의 측면에서 더 낫다.(암호화를 하지 않는다면 썩 좋지는 않다고 한다..)
