[week2] 블로그 작성 (chanhee)

[frontman-git]

No description provided.

[github-actions]

Chat GPT's review

Blog Link: https://frontman-dev.tistory.com/1
블로그 제목: Cookie가 없던 시절, 로그인 세션은 어떻게 유지되었을까?

블로그 요약: 이 블로그 글은 웹 브라우저와 쿠키의 등장 시기에 대해 언급하며, 현대의 세션 유지 방식과 이전에 사용되던 방식을 비교합니다. 클라이언트 측에서 데이터를 저장하는 방법이 없었던 시대에는 어떻게 인증을 유지했는지에 대해 설명하고 있습니다.

피드백:

1. 글의 목적: 글의 목적은 명확하게 전달되지만, 요약이 추가로 필요한 부분도 있습니다.
2. 구조와 전개: 글은 웹 브라우저 및 쿠키의 역사부터 현대의 세션 유지 방식에 이르는 과정을 설명하고 있으며, 전개가 일관되고 구조화되어 있습니다.
3. 명확성과 가독성: 글은 기술적인 내용을 다루고 있어 가독성이 중요합니다. 각 단락을 좀 더 구분짓고 필요한 경우 요약을 추가하여 명확성을 높일 수 있을 것입니다.
4. 어조 및 스타일: 글의 어조는 전문적이며 기술적인 내용을 설명하고 있어 적합합니다. 스타일은 적절하고 객관적입니다.
5. 개선 사항 및 총평: 전체적으로 기술 블로그로서의 글을 잘 풀어냈으나, 요약이 더 간결하고 명확하게 되면 독자들에게 더 쉽게 전달될 것입니다. 또한, 목차나 그래픽 요소를 추가하여 시각적 요소를 강화할 수 있을 것입니다. 좋은 글이지만 조금 더 개선의 여지가 있습니다.

[eunjjungg]

안녕하세요 찬희님 !! 글 잘 읽었습니다 🫡

저는 쿠키랑 웹 브라우저가 동시에 등장했을 거라고 막연하게 생각했는데 . . 그게 아니었군요 ! 🫨

전반적으로 글 연결이 너무 너무 좋았어요..

1. 세션 유지에는 쿠키가 필요한데, 쿠키가 없었을 때가 존재했다는 걸 알려줌.
2. 인증 상황에서 클라이언트에서 정보 유지는 반드시 필요함.
3. 쿠키도 없고 JS도 아직 없던 시절 울며 겨자먹기로.. 세션 정보를 유지 & 이용할 때 사용한 방법 소개.
4. 그래서 쿠키 등장. (+ 인증 구현에서의 쿠키 사용 방식) 

뭐라고 해야하지 ... ㅋㅋㅋㅋ 지식이 점차 확장 된다고 해야되나..
연결이 너무 매끄러워서 .. 이해하기 정말 쉬웠습니다.
글의 초입에서 제시했던 의문(글의 목적)을 마지막에는 확실히 풀어주시더라구요 !

추가로 읽기 쉬운 문장은 어떻게 써야 되는지 배워볼 수 있었던 것 같아요 .
왜 읽기 쉬울까 ? 생각해봤는데, 불필요한 미사여구가 단 하나도 없어서 그런 것 같아요.
중요한 정보로만 문장이 이뤄지니까 읽을 때 훨씬 덜 부담스럽더라구요 !
(이런 스킬.. 쓱 퍼가겠습니다 . . . 저도 담에 글 쓸 때는 좀 더 잘 쓸수 있을거 같아요 ㅋㅋㅋㅋ !)

그런데 한 가지 궁금한 점이 있습니다.

1. 클라이언트에서 로그인을 한다.
2. 서버에서 session id를 내려준다.
3. 전달 받은 id를 클라이언트에서 유지한다.
4. 서버로 요청을 할 때 3에서 유지하던 id를 첨부해서 보낸다.
   a. get 요청은 URL 리라이터 방식
   b. post 요청은 숨겨진 폼 필드 방식

쿠키가 없던 시절 이런 순서로 세션 유지를 했다!는 이해를 했습니다.
근데 3번에서 클라이언트가 session id를 가지고 있는 방식이 혹시 글에 나왔는지가 궁금합니다 ! ㅎ..
id를 받자마자 바로 폼 필드에 박아넣어서 데이터 유지를 한다는 말씀이신거 같기두 하고요 . .
약간 요 부분이 모호해서 질문 드렸습니다 ㅎ.ㅎ 🫠

마지막으로 ! 찬희님 글 피드백 대상이 될 수 있어서 너무 다행이었습니다 !
이해하기 쉬운 글 구조 & 문장이 뭔지 배울 수 있었습니다 !
그리고 마지막에 쿠키가 그래서 뭐 하는 �친구냐면 ~~도 정리해주셔서 너무 친절한 글이었어요... 🫨
글 잘 읽었습니다 찬희님 !

[frontman-git]

@eunjjungg 님, 리뷰 감사합니다! 서버에서 세션 ID를 전달하는 방식이 다소 모호하게 작성된 것 같네요 :) 관련하여 부연 설명을 드리자면,

이때 사용한 방식은 서버에서 정적 HTML 문서를 생성하여 클라이언트에 전달하는 SSR 방식이었습니다. 서버가 정적 HTML 문서를 생성할 때, URL 리라이터 방식의 경우 href 속성에, 숨겨진 폼 필드 방식의 경우 value 속성에 세션 ID를 직접 삽입하여 응답했습니다. 클라이언트에서 세션ID를 받아 동적으로 붙이는 형태가 아닌 것이죠.

이렇게 세션 ID가 포함된 정적 HTML 문서를 클라이언트로 전달하기 때문에, 개발자 도구에서 요소를 검사하면 속성에 세션 ID가 그대로 노출되는 보안 취약점이 있었습니다.

부족한 글임에도 칭찬 가득 정성 가득한 리뷰 정말 감사드립니다ㅋㅋㅋㅋ

[eunjjungg]

@frontman-git 님 ! 일단 결론부터 말씀 드리면 이해 됐습니다 !! 😌

SSR 방식이라는 걸 몰랐어서 조금 모호하다고 느껴졌나봐요. SSR 방식을 사용해서 렌더링한다고 생각하니까 이해 됐습니다 !

너무 신기하네요.. 예전에는 갖고있다가 동적으로 붙이는게 없었군요 . . . 옛날엔 진짜 ㅋㅋㅋ 위험했겠어요.. 🫢

친절한 답변 감사합니다 ! 지식 여럿 배워갑니다 〰️〰️ 👍