정보/WEB (8) 썸네일형 리스트형 npx 명령 시 의존성 트리가 변하는 이유 npm을 사용하는 도중 npx라는 흥미로운 명령이 있어서 한번 살펴봤다. npm(node package manager)node.js 를 통한 프로젝트를 진행할 때 모든 패키지를 관리하기 위해 사용한다.npm 에서 특정 라이브러리, 모듈을 사용하고 싶다면 이를 설치 후 실행하는 방식으로 진행이 된다. 하지만 계속해서 쓰는 것이 아니라 실험적으로 써보거나이후에 사용하지 않거나 하는 패키지가 존재할 수도 있다.그리고 이를 반복적으로 하려면 package.json과 package-lock.json이 수많은 패키지로 인해 비대해지고 프로젝트의 사이즈도 커질 것이다.따라서 한 번만 쓰고 말 패키지에 대해서해당하는 패키지를 설치하지 않고 실행만 하는 명령. 이것이 npx이다. npx(node package execu.. CSRF, 이를 막기 위한 CORS CSRF는 Cross Site Request Forgery, CORS는 Cross Origin Resource Sharing의 약자. 일단 Site와 Origin의 차이를 살펴보자.Origin : Scheme :// Host Name(Domain Name) : Portex) https://namucy.tistory.com:8080https 가 scheme ; 프로토콜을 의미namucy.tistory.com 가 Host Name;namucy가 subdomain, tistory가 second level domain, com이 top level domainPort는 서버가 요청을 받는 포트를 말한다. 일반적으로 생략되어있으면 default 포트로 향함.Site : Domain Name 중 Second leve.. Cookie를 보완하는 Storage, Session Cookie만으로 통신할 시 단점이 있다.1. 쿠키 정보가 웹 브라우저에 저장된다.민감한 정보들이 안전하지 않은 채로 저장됨웹 브라우저 간 공유 불가 (지역성 문제; 매 웹 브라우저 하는 검색같은 행위가 해당 브라우저에만 저장됨)2. 쿠키는 Domain + Path만 일치하면 해당 웹 서버로 모든 쿠키를 담아냄쿠키로 저장하려는 정보량이 많아지고, 요청 크기가 커짐 (실제요청보다 쿠키가 커지는 경우)불필요한 Network Overhead (비용의 문제로 연결) Storage (웹 브라우저 내 저장)원래부터 stateful HTTP 를 위한 기술은 아님.HTML5 표준 등장 이전에는 cookie만을 썼어야 했음. HTML5 이후부터 사용.유저에 의해 변경된 옵션 상태 등 필요에 따른 조회가 필요할 때웹 서버.. Cookie 개요, 브라우저에서 쿠키의 작동 Cookie의 필요성?➡️ HTTP가 어떤지 다시 생각해 볼 필요 있음. HTTP는 Stateless Protocol이다.✅ 웹 서버는 기본적으로 매 요청이 어떤 웹 브라우저가 보낸 것인지 알 수 없다. (stateless ; 불연속성)JWT(JSON Web Tokens)와 같은 방식으로 이를 해결하는 방식도 있음.더보기사용자 정보와 인증 서명 같은걸 암호화 해둔것을 인코딩 해둔 값이라고 보면 된다.로그인 기능을 구현할 때 초보자들에게 많이 추천되는 방식인데, 이때 보안의 결함 발생함.secret 코드(암호화를 통해 전달되어야 하는 값)의 원본 secret을 쉬운것으로 적어놨다가브루트포스에 의해 해킹당하는 경우가 있거나alg : "none" 처럼 대충 만들거나민감한 유저 정보를 그대로 다 집어 넣는 경우.. Proxy Server Proxy Server란 서버 부하 완화 및 보안을 위해 사용하는 서버이다. 주요 기능보안 : IP 숨기기 (은닉) 혹은 프록시 서버 자체를 방화벽으로 사용하기도 함속도(캐시) : Cache를 사용해 서버의 부담을 줄여준다ACL : 서브네트워크 레벨의 방화벽Log / Audit : 리포트, 모니터링지역 네트워크 제한 우회 프록시 서버는 크게 Forward Proxy와 Reverse Proxy로 나뉜다. Forward Proxy요청 보내는 측은 클라이언트 (웹 브라우저)요청에 대한 세부적인 추가 작업을 한다.클라이언트 은닉우회 : 특정 클라이언트 IP가 block되어있다면, 그걸 피해서 접속하기 위해 IP 감춤클라이언트 접근 제어 : firewall 역할을 해준다. - 특정 IP 혹은 웹 페이지에 대한 접.. HTTP Cache 재검증 기준 헤더와 조건부 요청 이전의 재검증 주기는 브라우저가 서버에서 준 정보로 캐시 사용 여부를 판단하는 것과 달리, 재검증 기준은 서버가 판단한다.처음의 요청에 대해 서버가 재검증 기준의 헤더를 브라우저에게 보내고,브라우저는 이 헤더의 내용들을 그대로 서버에게 보내서 판단한 후사용하라 / 마라를 HTTP 응답 코드와 함께 반환한다. 다음은 첫 요청 이후 서버가 브라우저에게 보내는 재검증 기준 헤더이다.Last-Modifed 헤더데이터가 바뀐 시점을 서버가 클라이언트에게 이 헤더를 통해서 보낸다ETag 헤더Entity Tag 의 줄임말.Hash-based를 가장 많이 쓴다.데이터의 고윳값을 의미한다. 가령 데이터가 한 글자라도 바뀌면 고윳값이 달라진다.위에 소개한 재검증 기준 헤더는 서버가 브라우저로 보내는 헤더들이다. 조건부 .. HTTP Cache 동작 원리와 Cache-control 헤더 Cache를 사용하는 이유?임시 저장을 통해 웹 브라우저와 서버의 과부하를 줄이는 것이 주요 목표다만 임시 저장이라는 말처럼, 오래된 데이터는 폐기해준다면 어느 정도의 실시간성을 지닌 효과도 있다. (준실시간성) ➡️ 따라서 실시간성이 매우 중요한 데이터는 캐시 사용 X HTTP Cache 동작 원리 (다음 글에서 더 정리할 예정)처음 사용자의 요청에 응답해 서버가 리소스를 반환할 때 헤더에 재검증 주기와 기준을 제공이후 브라우저는 헤더의 정보를 바탕으로 캐시를 사용할 지 말지를 결정재검증 주기와 기준 둘 다 만족 ➡️ 그냥 계속 씀어느 하나라도 만족하지 못했을 경우 ➡️ 서버에게 물어 보고 씀 서버의 Cache-control 헤더를 통한 세부 설정캐시 저장 여부 no-store : 캐시 안함no-cac.. HTTP Cache 역할, 종류 Cache의 필요성; 웹 브라우저와 웹 서버의 부하웹 브라우저가 웹 서버에게 요청하고 반환해야 하는데 매번 이를 반복하려니 부하가 옴이전과 같은 것을 로드해야 한다면, 이를 재사용 하기 위해 Cache를 사용첫 요청에 대해서 반환할 때 서버 측에서 캐시와 관련된 헤더를 통해 설정.저장소 위치 별로 아래와 같이 분류한다. 이전에 받았던 응답을 브라우저 측에서 재사용 할 때 : HTTP Private Cache 사용이전에 반환한 응답을 재사용 할 때HTTP Shared Cache (프록시 = CDN 또는 Forward / Reverse Proxy에서 사용)API 서버 자체 / 서버 사이드 Cache 사용Local Cache : 서버측에서 직접적으로 다루는 EH캐시와 같은 캐시 라이브러리를 활용참고로 서버측에.. 이전 1 다음
