이 Storage는 Cookie, Session처럼 Stateful HTTP를 위한 기술은 아니다.✅ Storage와 Cookie의 목적 차이🔹Storage웹 브라우저 저장소 (Stateful Http를 위한 기술은 아니다.)유저에 의해 변경된 옵션 상태 등 -> 필요에 따른 조회가 필요할 때(진짜 저장소)마지막에 어떤 소셜 계정으로 로그인했는지 저장하고, 1년 뒤 로그인할 때 표시하여 알려주기🔹Cookie웹 서버에게 웹 브라우저가 매번 전달할 특정 정보를 위한 저장소(Stateful)로그인 인증 정보 등 -> 웹 서버가 매번 요청할 때마다 필요한 정보를 웹 브라우저에 넣어두고 전달받아 쓴다.만료시간이 필요한 정보는 cookie를 사용 [Storage와 Cookie구분하기]사용자가 방문한 페이지 저장..
전체 글
✅ Cookie웹 서버의 제어 + 웹 브라우저 내 저장 및 전송- 웹 서버의 제어: Set-Cookie헤더를 통해 어떤 데이터를 쿠키로 쓸것인지, 유효시간 및 보안 설정✅ 쿠키 사용의 기준: Dmain + Path웹 브라우저가 쿠키를 웹 서버에게 전송하는 기준(전송할지, 말지) = 해당 쿠키를 어떤 요청에 보낼지모든 쿠키에는 도메인이 연결되어있다.같은 도메인이더라도 각 페이지마다 보내줘야하는 쿠키가 다르다. 예를 들어서 웹 브라우저에 아래와 같이 저장되어 있는 쿠키 리스트가 있다고 쳐보자1번 쿠키 : h1 = w1 (Domain: `a.com`, Path: `/`)2번 쿠키 : h2 = w2 (Domain: `a.com`, Path: `/user`)3번 쿠키 : h3 = w3 (Domain: `b.com..
✅ HTTP 는 Stateless Protocol이다.💡Stateless?🔹Stateless(불연속성): 무상태, 서버가 클라이언트의 상태를 보존하지 않음최소한의 자원으로 서버 유지를 가능하게함 (수억명의 트래픽(Concurrent Users)커버 가능) - Easier to scale, cache, and manage the service기본적으로 세션을 유지하지 않고, 서버는 Client specific세션 데이터를 저장하지 않기에 클라이언트는 끊임없이 자신이 누구인지 밝혀야한다는 것 -> JWT HTTP는 stateless 하게 설계되었으나 쿠키와 세션을 활용해서 stateful하게 사용할 수도 있다고 이해했다.✅ Stateful HTTP: Cookie & Session웹 서버는 웹 브라우저..
프록시를 사용하는 이유보안: IP 숨기기 혹은 프록시 서버를 방화벽으로 사용하기도 한다(프록시 방화벽)속도(캐시): 동일 요청이 들어오면 서버에 다로 접속할 필요가 없이 저장된 Cache 자원을 반환전송 시간 절약, 외부 트래픽을 줄여 네트워크 병목 현상도 방지 = 이는 서비스의 속도를 높여준다ACL: 사이트 접근 범위 정책 정의 (Proxy Server 에 접속할 수 있는 범위를 설정하는 옵션)Log/ Audit: 리포트, 모니터링(회사 내 직원의 인터넷/인트라넷 사용을 레포팅)지역 네트워크 제한 우회: 한국에서는 접속이 제한이 되는 사이트 (IP 검사로 한국에서의 접속임을 감지)이런 경우 프록시 서버를 사용하면 접속을 다른 나라로 우회proxy는 클라이언트측 Forward Proxy 와 서버측 Rev..
캐시할 데이터는 웹 서버가 반환하는 값-> 반환값에 대한 소유주: 웹 서버-> 웹 서버가 캐시를 모두 제어 Cache-control 헤더를 통한 세부 설정캐시 입장에서 누가 갑이고 누가 을인가?갑: 웹 서버: 웹 서버가 캐시를 하냐마냐 등을 모두 제어 -> Cache-control 헤더을: 웹 브라우저나 프록시: 웹 서버가 보내는 Cache-control헤더를 보고 하라는 대로 순종캐시 저장 여부: 캐시해? 말아?`no-store`: 캐시 안함`no-cache`: 캐시 함. 단, 매번 재검증 후 사용(패킷 경량화) -> 이름만 보고 캐시 안하는거아니야? 라고 헷갈리지 말기 캐시 저장 장소: 어디에 저장해?`public`: Private(웹 브라우저) + Shared(프록시) 모두에 저장 -> 브라우저에도..
dockerfile 생성FROM eclipse-temurin:17-jdk-alpineVOLUME /tmpARG JAR_FILE=build/libs/*.jarCOPY ${JAR_FILE} app.jarENTRYPOINT ["java","-jar","/app.jar"] docker 명령어로 이미지 생성dockerfile이 있는 폴더에서 아래 명령어 실행docker build --build-arg JAR_FILE=build/libs/\*.jar -t rlawldus0209/capstone . --platform linux/x86_64 도커 허브에 이미지 올리기docker push rlawldus0209/capstone 배포 서버에서 허브에 올린 스프링 이미지 다운받기docker pull rlawldus0209..
오류@Transactionalpublic Files savefiles(FileUploadDTO file, MultipartFile newFile, Member member) throws Exception { if (member == null) { throw new BusinessException(CustomErrorCode.ACCESS_DENIED); } Files files = fileHandler.parseFileInfo(file, newFile, member); if (files == null) { //파일이 없을 경우: 클라이언트 측에서 파일 데이터가 없을 경우 throw new BusinessException(CustomErrorCode.NO..
원인docker hub에 로그인이 되지 않을 경우user name과 docker hub 로그인된 ID가 일치하지 않을 경우 나의 경우 1번이였던거 같다.해결먼저 아래 명령어로 docker 로그인 진행 docker login 그러면 아래 사진 같이 뜰 것이다. 로그인 성공~ 로그인 후 프로젝트 이미지 허브에 올리기
원인ERROR: failed to solve: eclipse-temurin:17-jdk-alpine: failed to resolve source metadata for docker.io/library/eclipse-temurin:17-jdk-alpine: no match for platform in manifest: not found 윈도우에서 잘 되던 명령어가 맥에서는 이런 에러가 떴다..해결구글링 해보니 M1칩의 경우 linux/arm64/v8 베이스로 이미지 빌드를 한다고 나와있었다. 나는 M3칩을 사용했지만 혹시 나도? 라는 생각에 docker build -t {tag} . --platform linux/x86_64 이미지 빌드시 위 처럼 플랫폼을 명시해주니 이미지 생성이 잘 되었다.