Computation suite

서론 웹 개발 환경에서 FE 개발자와 BE 개발자는 상대의 업무를 서로 이해하게된다면  좀 더 총괄적인 서비스의 흐름과 병목지점을 파악할 수 있다. 때문에 이 둘의 협업 과정은 자연스럽게 Full-stack을 지향하고 있는 과정이라고 생각한다. 24년 12월부터 Django fullstack 사이드 프로젝트를 시작했다. 본론 시행착오 python django 코드 뿐 아니라 html + css + js도 함께 커버하기에 작업에 상당한 context switch가 있었다. 머릿속에 그린 것을 도식화나 문서화하지 않고 무작정 뛰어들었기 때문에  디자인 중인 화면을 확인할 곳이 없었다는 흠이 있었다. 특히 wireframe, 화면설계서가 없으니까  백엔드 작업시 하나의 기능을 완성하기 전까지 제대로 빌드가 되지 않기 때문에  dribble이라는 디자인 사이트를 많이 참고했다. 중복 작업과 반복 작업 중복, 반복 작업 django template language에서 상속을 지원하기 때문에 베이스 템플릿을 상속받아서 페이지를 제작할 수 있다. 템플릿에서 내부에서 여러번 쓰이는 컴포넌트가 불편하다면 공통 컴포넌트를 만들어주면된다. 그러나 컴포넌트를 FE 프레임워크 레벨 정도로 관리하기는 쉽지 않다. 공통 컴포넌트를 관리하려면 프레임워크의 틀을 따라가야하는데 이 시점이 프론트엔드 프레임워크 선정을 할 타이밍이라고 생각한다. JS로 모든 것을 control한다는 것의 간결함 FE UI 프레임워크에서는 html로 작성한 class, id 명을 js에서 검색하여 따르기보다 js로 직접 동적으로 문서 객체를 생성한다. 참조하기도 간편하고 관리하기도 쉽다. js는 bom(부분적으로)과 dom을 컨트롤 할 수 있다. 결론 결국 아주 간결한 landing page 외에는 JS 기반 프레임워크를 사용해야한다. 나는 왜 바로 FE 프레임워크로 뛰어들지 않았나? 더 깊고 가파른 학습을 위해 컴퓨터공학이나 소프트웨어학과의 교육 커리큘럼도 그렇고 프레임워크 이...

Form 통신 특성에 초점을 맞추어 작성하였습니다. Form 통신 HTML Form 데이터를 가공하여 웹 서버에 전달한다. MIME-type UUEncode에서 개선된, 인코딩 방식을 명시하는 값. MIME은 문서, 파일 또는 바이트 집합의 성격과 형식을 나타낸다. <RFC 6838> 다양한 미디어 타입에 대해서는 다음을 참고한다. https://developer.mozilla.org/ko/docs/Web/HTTP/MIME_types 별도의 헤더로 존재하는 것이 아니라 content-type에 포함된다. Content-Type HTTP 메시지에서 Content-Type헤더는 HTTP 통신에서 미디어 데이터의 오리지널 타입(MIME type)을 알려주는 값이다. html form에서는 enctype에 있다. 예는 아래와 같다. Content-Type: text/html; charset=utf-8 Content-Type: multipart/form-data; boundary=ExampleBoundaryString 텍스트 파일을 텍스트 파일로 읽는 데에는 문제가 없으나 문자 파일 뿐 아니라 다양한 확장자를 가진 바이너리 파일은 종단간에 ASCII 코드 텍스트를 해석하던 방식만으로는 읽을 수 없다. 바이너리 파일 -> 텍스트 파일로 인코딩 텍스트 파일 -> 바이너리 파일로 디코딩 을 위해 이 필드의 명시가 필요하다. 클라이언트에서 content-type 헤더를 명시한다면 서버로 보낼 컨텐츠의 타입을 지정하게 되고 서버로부터 돌아오는 response의 content-type 헤더에는 사용자가 받을 컨텐츠의 타입이 지정된다. type 제한이 엄격하다면 415 에러가 리턴된다. multipart/form-data 특히 서로 다른 content-type을 가진 html form에서(text + image) 하나의 http request body로 전송할 때 사용하며, 파일 업로드에 사용. application/x-www-form-urlencoded fo...

CSRF CSRF(Cross Site Request Forgery), 사이트 간 요청 위조 사용자의 의지와 무관하게 공격자가 사용자로 하여금 특정 웹사이트에 공격자가 의도한 행위를 요청하게 하는 공격. CSRF가 요청을 위조하는 방법 참여자들 일반 사용자/ 공격자 / 타겟 서버 전제 상태 1. 사용자는 서버에 성공적으로 로그인을 하여 서버는 사용자를 확인할 수 있는 문자열을 포함하여 사용자에게 응답한 상태이고 2. 서버 영역에서는 세션 정보가 생성된 상태. 3. 사용자는 정상적인 응답을 받았으므로 session ID가 사용자의 브라우저 쿠키 영역에 저장됨. 이 때, 공격자가 서버를 공격하기 위한 요청 패턴에 대해 미리 알고 있다면 필요한 정보는 사용자 브라우저의 쿠키 영역에 저장된 session ID 뿐임. 이것을 헤더에 실어서 임의를 패킷을 만드는 것은 쉬운 일. 공격자는 어떻게 쿠키 영역의 정보를 탈취할까? 쿠키 영역 정보 탈취 1. 공격자는 악성 스크립트 페이지를 누르도록 유도한다. 서버가 직접적으로 해킹당하지 않았더라도 정상적인 게시글에 악성 스크립트를 실행시키는 클릭 유도 낚시 링크를 달면 유저가 클릭하게 되고 유저의 정보가 악성 스크립트가 의도대로 행동하게된다. 2. 서버는 쿠키에 담긴 session ID를 해석해서 정상적인 요청이라고 인지한다.(사용자의 session ID는 훼손된 것이 아니므로) 3. 서버는 인가된 사용자임을 인지하고 요청을 처리한다.    (하지만 정상 사용자는 이 요청을 의도하고 보내지 않았다.) CSRF 방어법 사용자 의심되는 URL, 신뢰할 수 없는 사이트의 URL, 출처가 명확하지 않은 곳으로부터 온 메일의 URL 등을 클릭하지 않도록 한다. 서버 개발자/운영자 - CSRF토큰 검사   세션에 임의의 값을 저장한 뒤 사용자에게 return하여,   모든 요청마다 해당 값이 있는지 검사함. - Header의 referer 필드 값 검사   referer 필드는 현재 요청을 보낸 ...

요즘 이모지가 잘 나와서 icon을 제작해서 쓰는 것보다 친숙하고  시인성도 좋고 글 맥락에 적절하다. django github https://github.com/django/django/blob/main/tests/model_fields/test_textfield.py 를 참고한다. django/tests/model_fields/test_textfield.py class TextFieldTests(TestCase): def test_emoji(self): a = modelA(text = '😊') a.save() 이런 식으로 저장하면 됨