| 일 | 월 | 화 | 수 | 목 | 금 | 토 | 
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 | 
| 13 | 14 | 15 | 16 | 17 | 18 | 19 | 
| 20 | 21 | 22 | 23 | 24 | 25 | 26 | 
| 27 | 28 | 29 | 30 | 31 | 
- Front-End
 - TypeScript
 - 수제비
 - 백엔드개발자
 - JS
 - VUE
 - frontend
 - 자바스크립트
 - Authentication
 - 스프링부트
 - TS
 - useState
 - React
 - JWT
 - Redux
 - 웹개발자
 - 프론트엔드
 - It
 - spring boot security
 - Node.js
 - spring
 - 큐넷
 - spring boot
 - security
 - JavaScript
 - 정보처리기사 실기
 - 백엔드
 - 정보처리기사
 - 타입스크립트
 - 리액트
 
- Today
 
- Total
 
목록2024/10 (3)
솔적솔적
오늘의 글은window.location.reload()가 위험할 수 있는 이유와,React 프로젝트에서의 더 좋은 새로고침 전략에 대해서 정리해보고자한다. 버튼 클릭 시 “새로고침”이 필요하다는 요구사항을 종종 만납니다. 흔히 떠올리는 건 바로window.location.reload();하지만, 구현하면서 항상 생각해야한다.이 코드가 우리 프로젝트에 적합한 코드인가? 왜 섣부른 전체 리로드가 위험할까 🤔상태 손실이 되어도 괜찮은가: 메모리 기반 상태(React state, Zustand 등 사용 시) 전부 초기화된다.현재 참여 중인 프로젝트는 i18n을 적용해 한국어/일본어 다국어 선택 기능을 제공하고 있는데,단순히 window.location.reload()를 사용하면 이 상태들도 모두 초기화..
웹에서 '로그인 상태 유지' 또는 '자동 로그인' 기능을 구현할 때어느 저장소에 무엇을 두느냐는 보안, 편의성 균형의 문제다. 1편에서 저장소 종류와 특성을 정리했다면2편에서는 공격 벡터인 XXS/CSRF를 기준으로 실전 방어법과설계 패턴을 이리저리 생각하고 구글링한 결과를 정리해볼 예정이다. (*이건 그저 구현하며 저의 생각을 정리하는 내용이지 정답은 아닙니다.)- Access Token, Refresh Token 같은 것은가능한 클라이언트쪽에서 JS접근 불가한 HttpOnly 쿠키 + Secure + SameSite 설정으로 관리하는 것으로하는 것이 좋다생각한다.- Access Token은 가능한 **메모리(짧은 수명)**에서 관리하고 필요 시 refresh cookie로 재발급한다.- 비민감..
자동로그인, 로그인 상태 유지 기능을 구현할 때 고민했던 문제이다. 브라우저 저장소를 어떤 걸 적용할 지 결정할 때,아, 나 로컬스토리지 써봤으니까 그거 써야겠다~라는 생각은? 않하느니만 못하다~git에 푸시 전에 불안하잖아~정말 이 선택이 맞는지~ HTTP의 기본 특성부터먼저, 서버와 클라이언트가서로 소통할 때 지켜야할 규약인 HTTP, HTTP는1. 클라이언트가 request를 보내고2. 서버가 클라이언트한테 받은 request대한 response를 보내고 접속을 종료한다.(통신 끝) 이는 인증에 쓰이는 상태정보를 유지하지 않는 무상태(Stateless) 프로토콜, 비연결성, 무상태성 특징이 있다.이 특징(비지속적인 통신 연결)때문에 자원 낭비가 줄어드는 것은 장점이지만통신을 할 때마다 다시 요청해서..