[ JavaScript 알고리즘 (프로그래머스)] 문자열안에 문자열

2frost — Thu, 23 Nov 2023 22:32:26 +0900

문자열안에 문자열

1. 문제설명

문자열 str1, str2가 매개변수로 주어집니다. str1 안에 str2가 있다면 1을 없다면 2를 return하도록 solution 함수를 완성해주세요.

제한사항

1 ≤ str1의 길이 ≤ 100
1 ≤ str2의 길이 ≤ 100
문자열은 알파벳 대문자, 소문자, 숫자로 구성되어 있습니다.

2. 입출력 예

입출력 예 설명

입출력 예 #1

"ab6CDE443fgh22iJKlmn1o" str1에 str2가 존재하므로 1을 return합니다.

입출력 예 #2

"ppprrrogrammers" str1에 str2가 없으므로 2를 return합니다.

입출력 예 #3

"AbcAbcA" str1에 str2가 없으므로 2를 return합니다.

[ 내가한 문제 풀이 ]

function solution(str1, str2) {
    var answer = 0;
    if(str1.includes(str2)) answer=1;
    else answer=2;
    return answer;
}

[ TIL ] [ 실전프로젝트주차] '내일은 최저가' 프로젝트 회고

2frost — Thu, 23 Nov 2023 22:21:56 +0900

6주간의 최종프로젝트(2023.10.04~9.2023.11.15) '내일은 최저가'에 대한 프로젝트가 끝났다.

블로그에는 프로젝트에 대한 '회고'를 정리할 예정이라 자세한 정보는 가장 하단 노션(*그 외 URL첨부) 주소로 따로 기재하곘다.

간단하게 우리가 기획하고 만든 '내일은 최저가'에 대해 소개하자면

'다이나믹 프라이싱'을 활용하여 쿠팡에서 애플제품에 대해 매일 2회 가격 변동 차트를 업데이트 -> 가격 하락, 품절업데이트 시 설정한 상품에 대해 이메일 알림 제공 (카카오비즈톡 승인중)이 가능하다.

이를 통해, 고객의 구매 전환율 제고 하고 탐색 비용을 줄여줄 수 있는 서비스를 만들었다.

(* 다이나믹 프라이싱이 뭐야?)

다이나믹 프라이싱은 가격을 설정하는 전략으로, 시장 수요, 재고 상태, 고객 행동, 경쟁사 가격 등 다양한 요소에 기반하여 가격을 실시간으로 조정한다. 이 방식은 항공권, 호텔 예약, 전자 상거래 등 다양한 산업에서 사용되며, 최적의 가격을 통해 수익을 극대화하고 소비자의 구매 패턴에 더 잘 맞추기 위해 사용됨.

*(왼쪽부터1-2) 1. 가격변동차트 2. 상품알림설정

'회고'가 주제이니 설명은 이쯤 해두고

프로젝트를 하면서 있었던 트러블슈팅, 유저테스트에 대한 몇 가지 부분에 대해 적어보려 한다.

[ trouble SHOOTING ]

1. Puppeteer의 실행문제

프로젝트에서 가장 중요한 '웹 스크래핑'을 하기 위해 Puppeteer를 사용했다. 그러나 클라우드 VM 환경(우분투)에서 Puppeteer 패키지를 사용 시 에러 발생 되었다.

발생원인 :

Puppeteer는 Chromium 기반의 GUI 브라우저를 구동하는데 필요한 라이브러리가 우분투에 설치되지 않아 libatk-1.0.so.0 파일을 찾을 수 없어 브라우저 실행에 실패하였으며, 서버 용량 부족도 포함되어 있었다.

해결방법:

이 부분을 해결하기 위해, AWS Lambda, 도커, serverless framework를 사용해 Chromium – Puppeteer 의존성과 배포환경 문제 해결하는 방법을 선택했다.

2. HTTPS 환경에서 JWT 토큰전송문제

FE는 BE가 처리를 완료할 때까지 기다려야 하며 BE에서 발급한 JWT 쿠키가 FE의 로컬 스토리지에 저장되지 않음. HTTPS로 배포한 경우, 쿠키는 생성되지만 사용할 수 없음

const redirect_url = `${process.env.CLIENT_URL}/kakaologin?
authorization =${accessToken}`;
console.log(redirect_url); // 백엔드에서 확인
res.redirect(redirect_url);

발생원인 :

쿠키를 통한 JWT 전송이 FE와 BE 간의 통신 방식에서 문제를 일으킬 수 있으며 특히, 쿠키의 SameSite 정책, Secure 플래그 설정, CORS 정책 등으로 인해 FE에서 쿠키를 제대로 처리하지 못하는 경우가 있었다.

해결방법:

이 부분을 해결하기 위해 JWT 토큰을 쿠키 대신 URL의 쿼리 스트링에 담아서 FE로 전송하고, FE는 쿼리 스트링을 파싱하여 직접 로컬 스토리지에 저장하고 사용했다.

이 외에도 FE에서의 React Query훅 호출 순서에 대한 문제, Styled Components props 전달오류 등 트러블 슈팅이 있었다.

우리는 서비스를 만들고, 짧지만 구글폼을 통해 (11/2 ~ 11/6 (5일간)) '유저피드백' 기간을 가졌다.

[ UT진행 내용 및 결과 ]

5일이라는 짧은 기간에 49명의 유저가 피드백을 정성스럽게 남겨주었다.

구글폼의 질문은 소비자의 접속환경을 파악하고, 서비스에대한 니즈를 파악하는 항목으로 준비해두었고,

그 결과, 아래와 같은 답변을 받아 볼 수 있었다.

*(왼쪽부터1-3) 1. UT 진행내용 2. UT 결과 중 접속환경 결과 3. 유저테스트 결과중 일부

- 사용자 중 다수(17명)가 모바일을 통해 서비스를 이용,

- 사용자의 접속환경읜 구글/크롬이 압도적으로 많았으며, safari를 사용하는 유저도 일부 존재.

따라서 유저의 접속환경 대부분이 모바일모바일인 점과,유저테스트 오류(버그)에 대한 내용이 모바일의 스크롤과 관련된 부분으로 '모바일 편의성' 개선에 주안점을 두고 최종 발표 이전까지 서비스를 개선하도록 했다.

*(왼쪽부터1-2) 1. UT피드백1) 개선사항 2. UT피드백2) 개선사항

유저피드백을 통해 다수의 의견이 있었던 피드백은 아래와 같이 개선했다.

UT 피드백1)

AS-IS : "모바일을 저격한 디자인으로 보이는데 컴퓨터로 보았을 땐 다소 답답해 보입니다! PC버전과 모바일 버전이 나뉘어져 있었으면 더 좋았을 것 같습니다."와 "반응형이 제대로 안됩니다안됩니다."에 대해,

TO-BE : 기존 모바일 사이즈 (width: 375px)에서 태블릿및데스크탑용사이즈(375px~ 744px)까지미디어쿼리및rem을사용하여 반응형 웹페이지를 제작하는 것으로 수정하였다.

UT 피드백2)

AS-IS : 메인페이지에서 "아이패드, 에어팟을 제외한 카테고리를 선택하는 필터링에서 충전기들이 맨 위로 나타납니다!" 피드백에 대해,

TO-BE : 카테고리에서 금액대 9만원 이상인 제품만 반환하도록 설정을 진행해서 부속품이 아닌 제품들이 먼저 반환되도록 진행했다.

( 카테고리 필터에서 페이지네이션으로 설정하다보니, productId 기준으로 정렬되면서 충전기와 같은 부속품이 먼저 나오는 점이 문제로 수정함. )

UT를 통해 느낀 점

우리에게 당연한 건? 당연하지 않다. 안당연한 게 당연하다.

언젠가, 토스의 UX디자이너가 하는 이야기를 들은 적 있다. "유저는 고정관념을 깨 주는 유일한 존재들이다."

백엔드는 그저 서버 잘 구축하고 배포하고 잘 돌아가게 하면 되지.라는 안일한 생각을 가졌던 나에게 고정관념과 틀을 깨는 계기가 됨과 동시에 많은 공부가 되었던 시간이었다.

기간 내에 소비자의 니즈를 파악해 봄으로써 어떤 요소를 만들어야 서비스에 더 머물 수 있을지, 더 매력적인 서비스란 어떤 것인지에 대해 조금 더 고민해 볼 수 있었다. '우리 눈에는 보이지 않던 것들을 피드백을 통해 배움으로 성장해 나갈 수 있다는 것'

너무 좋았다.

6주간의 프로젝트를 통해, 좋았던 점을 간단히 나열해 보자면,

1. Nest.js를 공부해 볼 수 있어 좋았다.

- 2주 프로젝트에는 문법이 익숙하지 않아 ts와 express로 진행했다. 때문에 6주 프로젝트 시작에 공부를 하는데 시간을 많이 할애했는데, 그럼에도 무언가 배워가는 것이 있어 좋다고 생각한다.

2. UT를 통해 피드백을 받아 볼 수 있었다.

- 서비스를 구현하는 데 있어서 가장 필요로 하는 유저의 시선에서 피드백을 받아 볼 수 있어서 좋았다.

3. 협업경험 ( 프론트앤드 / 디자이너 )

- 2주 프로젝트는 챌린지팀으로 진행하다 보니 FE와의 협업경험이 없었는데, 협업 경험을 가져볼 수 있는 경험이 되었다.

아쉬운 부분은 여전히 남아있고, 내가 부족한 부분이 많았기에 완벽히 채울수 없겠지만 차차 보완하고 싶다.

아직 서버를 열어둔 상태라, 코드리팩토링을 할 예정이다. 필요에 따라, 디벨롭을 할 수도 있을 것이고

가장 중요하게는 테스트 코드를 놓친 부분이 있어서 팀원들과 진행해 보기로 했다. 회고는 여기서 끝.

(2주 프로젝트 회고도 못썼는데, 시간 내서 써야겠다!)

내일은 최저가 Notion

URL : https://lowprice.notion.site/624de44444494e1e86a5d30d7ea1f1aa?pvs=4

[내일은 최저가] 더 알고 싶다면?

항해16기 8조 최종 프로젝트 ‘내일은 최저가’

lowprice.notion.site

언제까지 서버를 열어 둘진 모르겠지만, 당분간은 열어둘 예정이기에 서비스 서버도 함께!

URL : https://lowest-price.store/

내일은 최저가

lowest-price.store

그리고 우리 프로젝트의 시연영상도 함께 공유한다.

( 광고영상 및 편집은 내가 진행했다. )

URL : https://youtu.be/NfOPmhd0Wm0

[ JavaScript 알고리즘 (프로그래머스)] 편지

2frost — Thu, 23 Nov 2023 21:40:34 +0900

편지

1. 문제설명

머쓱이는 할머니께 생신 축하 편지를 쓰려고 합니다. 할머니가 보시기 편하도록 글자 한 자 한 자를 가로 2cm 크기로 적으려고 하며, 편지를 가로로만 적을 때, 축하 문구 message를 적기 위해 필요한 편지지의 최소 가로길이를 return 하도록 solution 함수를 완성해주세요.

제한사항

공백도 하나의 문자로 취급합니다.
1 ≤ message의 길이 ≤ 50
편지지의 여백은 생각하지 않습니다.
message는 영문 알파벳 대소문자, ‘!’, ‘~’ 또는 공백으로만 이루어져 있습니다.

2. 입출력 예

입출력 예 설명

입출력 예 #1

message의 글자 수가 15개로 최소 가로 30cm의 편지지가 필요합니다.

입출력 예 #2

message의 글자 수가 11개로 최소 가로 22cm의 편지지가 필요합니다.

[ 내가한 문제 풀이 ]

function solution(message) {
    return message.length*2;
}

length 프로퍼티 값 = 배열의 길이 ( * message.length는 메세지 변수의 배열 길이)

message.length * 2는 한 글자당 2cm를 차지하는 편지지의 가로 길이가 된다.

[Summary:써머리] 바쁜 현대사회,유튜브 자동요약 필기앱이 있다?

2frost — Fri, 17 Nov 2023 11:06:48 +0900

어느 날 커리어리를 보다가, '유튜브 자동 요약 필기앱'이라는 아주 좋은 서비스를 발견했다.

당연히 유료라고 생각했는데...? 이게 무료라뇨????????? 바로 사용해 봅니다.

Summary라는 서비스였고, 홈페이지에 접속해서 바로 다운받아서 사용해 주었다.

( Summary 공식홈페이지 : https://home.summaryapp.io/ )

써머리: 유튜브 자동 요약 필기 앱

유튜브 영상을 AI가 자동으로 요약하고 필기

home.summaryapp.io

바쁘다 바빠 현대사회, 내 몸은 왜 하나?

긴 글 읽기는 시간이 부족해.... 영상으로 쓱 - 볼 때는 이해는 되는데 머리에는 남지 않는다 할 때!

* 예를 들면, JWT에 대해서 이해가 필요한데 유튜브로 보고 나서 요약이 필요할 때. 이렇게 쓰면 얼마나 좋냐면요?

1. 영상을 먼저 보고,

유튜브 '애플코딩' 관련URL : https://youtu.be/XXseiON9CV0?si=eUTQ3UKCwDmBDjng

2. 주소나 채널 추가로 요약을 요청하면? 1-2분 이내에 요약 완성이 되고, 공유하기도 가능하다.( * 스크립트로 전체 내용 확인도 가능! )

3. 2와 같이 공유를 하면, 아래와 같이 URL공유가 가능하다 (*카카오톡으로 공유도 가능)

summary 요약본 : https://share.summaryapp.io/ko/6556c8bb002c12243b4fb666

JWT 대충 쓰면 님들 코딩인생 끝남

1. JWT와 세션 방식의 차이점 • •JWT와 세션 방식은 유저가 로그인하면 서버가 입장권을 발급해주고, 이 입장권을 유지하여 유저를 인증하는 방식이다. • •세션 방식은 입장권에 적힌 정보가

share.summaryapp.io

영상으로 가볍게 한번 보고, 정리까지 해주는 서비스가 있다면, 안쓸 이유가 없다고요..

한국어로만 가능하냐고. 댓츠노!

영어로 된 좋은 레퍼런스를 찾았는데, 이해가 1도 되지 않을 때 ( *이 부분!!!! 너무 좋아,, )

1. 영상을 먼저 찾아보고, 유튜브 'abdul bari' 알고리즘 관련 URL : https://youtu.be/0IAPZzGSbME?si=ZRzTVblI0a8kc-Y4

2. 좋은 래퍼런스를 가진 영상이 한국어 번역이 없는 영어 자막이라면 ( 언제까지 모르는 단어 파파고 치고 있을 거야.. )

그때, 바로 URL을 바로 복사해 와서 한국어로 요약하면! 완벽하다..

( 반대로, 한국어 내용을 영어로 요약해야 할 일이 있을 때 사용해도 될 것 같으나 필터링이 필요하긴 합니다. )

3. 2에서 번역된 내용은 공유하기가 가능하며 '텍스트만 공유하기'도 가능하답니다! 카카오, URL공유 가능.

공유한 내용은 아래와 같이 보인답니다!
https://share.summaryapp.io/ko/6556ca06002c12243b4fbf89

1. Introduction to Algorithms

1. 알고리즘의 중요성과 학습 순서 • •알고리즘은 컴퓨터 공학 학생들에게 일반적으로 가르치는 과목으로, 대부분의 대학에서 이 과목을 교육과정의 일부로 제공한다. • •알고리즘은 이론

share.summaryapp.io

AI너.. 너무 무섭다.. 근데.. 너무 편하다... 서비스 만들어주신 분 감사합니다 감사합니다..

생활이 편해 질 수록 점점 문해력이 떨어지는 것 같은 느낌도 들지만,

많은 범위가 침해되지 않는 영역에서 잘 활용하면 생활에 너무 유용할것 같아서 많이 사용할 것 같다.

나도 좋은 서비스 만들고 싶어 ~

[ JavaScript 알고리즘 (프로그래머스)] 문자열 내림차순으로 배치하기

2frost — Sat, 14 Oct 2023 09:38:02 +0900

문자열 내림차순으로 배치하기

1. 문제설명

문자열 s에 나타나는 문자를 큰것부터 작은 순으로 정렬해 새로운 문자열을 리턴하는 함수, solution을 완성해주세요.
s는 영문 대소문자로만 구성되어 있으며, 대문자는 소문자보다 작은 것으로 간주합니다.

2. 입출력 예

[ 내가한 문제 풀이 ]

function solution(s) {
    return s.split("").sort().reverse().join("")   
}

1. 문자열 배열로 만들기 : split("")
2. 배열을 오름차순으로 정렬 : sort()
3. 배열을 내림차순으로 정렬 : reverse()
4. 배열을 문자열로 변환 :  join("")

* 코드카타를 너무 간만에 했다..문제 풀다가,

일정시간 이상이 지나 다른 사람들의 풀이를 참고해서 풀었다. 다시한번 풀어보는 시간을 가져야겠다.

[ TIL ] [ 정규과정 : 실전프로젝트주차 ] 기술면접 대비 1. Hoisting, async/await, Arrow Function

2frost — Thu, 12 Oct 2023 19:39:57 +0900

Q1. Hoisting이란 무엇인지 설명해주실 수 있을까요?

변수와 함수 선언이 그들의 스코프 상단으로 끌어올려지는 동작을 의미합니다. 이러한 동작은 실행 컨텍스트의 생성 단계에서 발생한다.

(나는 처음, 호스팅으로 공부해버렸다... 호이스팅이라는걸 다시 확인했고, 아래의 블로그를 참조해서 공부했다.)

https://tecoble.techcourse.co.kr/post/2021-04-25-hoisting/

호이스팅에 대한 오해와 진실

…

tecoble.techcourse.co.kr

Q2. async/await 이란 무엇인지 설명해주실 수 있을까요?

async와 await는 자바스크립트의 비동기 처리 패턴 중 가장 최근에 나온 문법입니다. 기존의 비동기 처리 방식인 콜백 함수와 프로미스의 단점을 보완하고 개발자가 읽기 좋은 코드를 작성할 수 있게 되었다.

1) async 키워드는 function 앞에 사용한다. function 앞에 async를 붙이면 해당 함수는 항상 프라미스를 반환한다. 프라미스가 아닌 값을 반환하더라도 이행 상태의 프라미스(resolved promise)로 값을 감싸 이행된 프라미스가 반환되도록 한다.

2) await: await 키워드는 async 함수 내에서만 사용될 수 있다. await는 Promise가 완료될 때까지 함수의 실행을 일시 중단시킵니다. Promise가 성공적으로 완료되면 그 결과값을 반환하고, 실패하면 에러를 발생시킨다.

참고 URL : https://joshua1988.github.io/web-development/javascript/js-async-await/

자바스크립트 async와 await

(중급) 자바스크립트 개발자를 위한 async, await 사용법 설명. 쉽게 알아보는 자바스크립트 async await 개념, 사용법, 예제 코드, 예외 처리 방법

joshua1988.github.io

참고 URL : https://velog.io/@khy226/%EB%8F%99%EA%B8%B0-%EB%B9%84%EB%8F%99%EA%B8%B0%EB%9E%80-Promise-asyncawait-%EA%B0%9C%EB%85%90

동기, 비동기란? (+Promise, async/await 개념)

1. 동기 vs. 비동기 우선 차이점 부터 설명하자면, 동기는 '직렬적'으로 작동하는 방식이고 비동기는 '병렬적'으로 작동하는 방식이다. 즉, 비동기란 특정 코드가 끝날때 까지 코드의 실행을 멈추

velog.io

Q3. Arrow Function 이란 무엇인지 설명해주실 수 있을까요?

ES6 문법 이후부터는 자바스크립트에서 함수를 만들 수 있는 문법이 새롭게 하나 등장했다.
arrow function 이라는 문법인데 이걸 이용하면 함수를 만들 수 있다.

function이라는 길고 복잡한 키워드 대신에
=> 이런 예쁜 화살표를 사용해서 함수를 만들어내는 신문이다.

1) 함수 본연의 기능을 아주 잘 표현하는 문법이다.

로그래밍할 때 function 문법은 왜 사용할까?
1. 여러가지 기능을 하는 코드를 한 단어로 묶고 싶을 때 (그리고 나중에 재사용할 때)
2. 입출력기능을 만들 때
이럴 때 함수를 사용한다.

arrow function을 사용하면 함수 본연의 입출력기능을 아주 직관적으로 잘 표현해준다.

arrow function을 쓰시면 입출력기능이 쉽고 예쁘게 표현된다.

var 두배만들기 = (x) => { return x * 2 }

console.log( 두배만들기(4) );
console.log( 두배만들기(8) );

숫자를 넣으면 2배를 해주는 함수를 만들면, 매우 이해하기 쉬워진다.

2) 소괄호 생략이 가능하다.

파라미터가 하나라면 소괄호 생략이 가능하다.

var 두배만들기 = x => { return x * 2 }

console.log( 두배만들기(4) );
console.log( 두배만들기(8) );

x에 소괄호를 생략해도 된다.

3) 중괄호 생략이 가능하다.

중괄호 안에 return 한줄 뿐이라면 중괄호와 return도 생략가능하다.

var 두배만들기 = x => x * 2 ;

console.log( 두배만들기(4) );
console.log( 두배만들기(8) );

결론: x가 어떻게 변하는 함수인지 입출력기능이 바로 한눈에 들어온다.

4) this 바인딩 : arrow function은 어디서 쓰든간에 내부의 this 값을 변화시키지 않는다.
그러니까 바깥에 있던 this의 의미를 그대로 내부에서도 사용하는 함수가 바로 arrow function 이라는 함수입니다.
(*항상 장점은 아니다. 내가 예측하던 this값과 달라질 수도 있으니 단점이 될 수 있다. )

참고 URL : https://codingapple.com/unit/es6-3-arrow-function-why/

Arrow function은 function을 대체하는 신문법이 아님 - 코딩애플 온라인 강좌

0:00 Arrow function 문법 1:17 왜 쓰는지 장점 3개 정리 4:28 Arrow function 실생활 사용 예시 & this값에 대하여 ES6 문법 이후부터는 자바스크립트에서 함수를 만들 수 있는 문법이 새롭게 하나 등장했습니

codingapple.com

오늘부터 기술면접 대비를 진행했다.

하루에 2개정도 내가 알아본 내용들을 제출했고,

오늘은 내가 미리 내가 기존에 알아본 내용들로 롤플레잉도 진행햬보았는데, 걱정이다..!

나 나중에.. 기술면접 잘 볼수있겠지?

벌써 걱정이다!

아직 전문지식이 부족해서 꼬리질문 나오면 긴장부터 된다!

많이 배워야겠다!

[ TIL ] [ 정규과정 : 실전프로젝트주차 ] Docker

2frost — Thu, 5 Oct 2023 19:53:49 +0900

YOUTUBE [얄팍한 코딩 ] - 도커가 뭐고 왜 쓰는건가요?

서버를 운영하다 보면, 더 성능 좋은 서버로 옮겨가거나,늘어난 서버 처리를 위해 서버를 여러 개를 처리해야 할 일이 생길 수 있다.

그럼 그곳에서도 똑같이 설치를 해야하는 일이 발생된다.

그나마 같은 사람이 하는거면 좀 번거롭고 마는데 지금은 퇴직하고 없는 개발자가 구축하게 된다면?

거기다 구식이라 매뉴얼도 잘 없는 환경이라면? 와중에 어디를 고쳐야 할지 아무도 모르는 상황이 발생된다면?

같은 서버에 여러 서비스를 돌리는 경우, 각각이 다른 실행환경에서 동작해야 할 때 일이 까다로워질 수도 있다.

ex) 기존사이트는 자바 7에서 동작 새 서비스는 자바 8에서 동작되면 이것저것 맞추고 신경 써야 할 것이 많아진다.

Docker를 사용하면 이러한 불편함을 없앨 수 있다.

각 요소가 설치된 형태를 ‘이미지’라는 형태로 박제해서 저장한다.

( 각 제품마다 공식적으로 제공되는 이미자도 있고, 원하는 대로 만들어 낼 수도 있다. )

Docker는 DockerHub에 업로드돼서 공유되고 다운로드하여질 수 있다.

이렇게 이미지로 저장된 항목들이 함께 연결돼서 동작하도록 설정 상태를 명령어 텍스트나 문서 형태로 저장할 수도 있다.

이런 것들을 설치하는 과정을 어디서든 컴퓨터가 자동으로 재현할 수 있도록 녹화해 둔다는 느낌으로.

따라서 이 문서만 잘 보관해 두면 이 요소들이 어디서든 미리 지정된 서비스에 필요한 설정대로 도커허브로부터 다운로드하여져서 설치될 수 있다.

도커는 이것들을 컴퓨터에 바로 설치하지 않는다. ‘컨테이너’로 불리는 독립된 가상공간을 만들어내서 복원한다.

때문에 아까 말했던 케이스와 같이 java7,8 또한 각각의 컨테이너 안에서 서로 방해받는 일 없이 돌아갈 수 있다.

도커는 가상컴퓨팅하고는 다른 구조이다.

가상컴퓨팅은 각각 OS를 가동하는 컴퓨터들이 물리적 자원을 불할 해서 쓰기 때문에 성능에 한계가 생기게 된다.

도커는 OS단까지 내려가는 게 아니라 실행환경만 독립적으로 돌리는 거라 컴퓨터에 직접 요소들을 설치한 거랑 별 차이 없는 성능을 낼 수 있고 가상컴퓨팅보다 훨씬 가볍고 빠르게 각각을 설치하고 실행하고 켜고 끄고 연동할 수 있다.

서버에 뭐가 잘못돼서 고치거나, 업그레이드 할 때 일일이 요소를 정지하고 지우거나 새로 깔 필요 없이 컨테이너를 통쨰로 교체해서 새로 실행하면 된다. 서버를 관리하고 서비스를 배포하는 일이 간편해지게 되었다.

1. Docker 실행방식

Docker 기술은 Linux 커널과 Cgroups 및 네임스페이스 등 커널의 기능을 사용하여 프로세스를 분리함으로써 독립적으로 실행할 수 있도록 합니다. 이러한 독립성은 컨테이너의 본래 목적이다. 다시 말해서, 여러 프로세스와 애플리케이션을 서로 개별적으로 실행하여 인프라를 더 효과적으로 활용하고 개별 시스템을 사용할 때와 동일한 보안을 유지할 수 있다.

Docker를 포함한 컨테이너 툴은 이미지 기반 배포 모델을 제공합니다. 따라서 여러 환경 전반에서 애플리케이션 또는 서비스를 모든 종속 항목과 손쉽게 공유할 수 있다. 또한 Docker는 이 컨테이너 환경 내에서 애플리케이션(또는 애플리케이션을 구성하는 결합된 프로세스) 배포를 자동화한다.

이러한 툴은 Linux 컨테이너를 기반으로 구축되어 Docker를 사용자 친화적이고 고유하게 만들어 주므로 사용자는 그 어느 때보다 쉽게 애플리케이션에 액세스 하고, 신속하게 배포하고, 버전 및 버전 배포를 제어할 수 있다.

2. Docker 장점

모듈성
컨테이너화에 대한 Docker 접근 방식은 전체 애플리케이션을 분해하지 않고도 업데이트 또는 복구를 위해 애플리케이션의 일부를 분해하는 기능에 중점을 둔다. 이러한 마이크로서비스 기반 접근 방식 외에도 서비스 지향 아키텍처(SOA)와 거의 같은 방식으로 멀티플 애플리케이션 간에 프로세스를 공유할 수 있다.

계층 및 이미지 버전 제어
각 Docker 이미지 파일은 일련의 계층으로 구성되며 이러한 계층들은 단일 이미지로 결합됩니다. 계층은 이미지가 변경될 때 생성되고, 사용자가 실행 또는 복사와 같은 명령을 지정할 때마다 새 계층이 생성된다.

Docker는 이러한 계층을 재사용하여 새 컨테이너를 구축하는데, 이때 구축 프로세스 속도가 빨라진다. 중간 변경 사항은 이미지 간에 공유되므로 속도와 크기, 효율성이 더욱 향상됩니다. 또한 계층화에는 버전 제어가 내재되어 있다. 새로운 변경 사항이 있을 때마다 변경 로그가 기본 제공되므로 컨테이너 이미지를 완벽하게 제어할 수 있다.

롤백
계층화의 가장 큰 장점은 아마 롤백 기능일 것이다. 모든 이미지에는 계층이 있다. 현재의 이미지 반복이 적절하지 않은 경우 이전 버전으로 롤백하면 됩니다. 이 기능은 애자일 개발 접근 방식을 지원하며 툴 관점에서 실제로 지속적 통합 및 배포(CI/CD)를 수행하는 데 도움을 준다.

신속한 배포
이전에는 새로운 하드웨어를 확보, 실행, 프로비저닝, 제공하는 데 며칠이 걸렸으며, 이를 위한 작업 및 오버헤드 부담도 상당했다. Docker 기반 컨테이너는 배포 시간을 몇 초로 줄일 수 있다. 각 프로세스에 대한 컨테이너를 생성하면 해당 프로세스를 새 애플리케이션과 빠르게 공유할 수 있다. 또한 컨테이너를 추가하거나 이동하기 위해 운영 체제를 부팅할 필요가 없으므로 배포 시간이 상당히 단축된다. 배포 시간이 단축되면 컨테이너에서 생성한 데이터를 쉽고 비용 효율적으로 생성하고 제거할 수 있다.

따라서 Docker 기술은 효율성을 더욱 중요시하며 더욱 세분화되고 제어 가능한 마이크로서비스 기반 접근 방식이다.

3. Doker 사용방법

1) Docker 설치:

Docker는 대부분의 주요 OS(Windows, MacOS, Linux)에서 사용할 수 있습니다. 공식 사이트에서 적절한 버전을 다운로드하고 설치.

2) Docker 이미지와 컨테이너:

➤ 이미지: 애플리케이션과 그 실행 환경을 포함하는 템플릿입니다.
➤ 컨테이너: 이미지를 기반으로 실행되는 인스턴스입니다.

3) 기본 명령어:
➤ 이미지 다운로드: docker pull [이미지 이름]
➤ 이미지 목록 확인: docker images
➤ 컨테이너 생성 및 실행: docker run [이미지 이름]
➤ 실행 중인 컨테이너 확인: docker ps
➤ 모든 컨테이너 확인: docker ps -a
➤ 컨테이너 종료: docker stop [컨테이너 ID 또는 이름]
➤ 컨테이너 삭제: docker rm [컨테이너 ID 또는 이름]
➤ 이미지 삭제: docker rmi [이미지 이름]

4) Dockerfile:

Docker 이미지를 만들기 위한 스크립트 파일입니다.

Dockerfile에 애플리케이션과 환경을 정의하고 docker build 명령어를 사용하여 이미지를 생성할 수 있습니다.

5) Docker Compose:

여러 컨테이너를 함께 관리하게 해주는 도구입니다. docker-compose.yml 파일에 여러 서비스를 정의하고, 단일 명령어로 그룹화된 컨테이너를 생성,

시작, 중지할 수 있습니다.

참조 URL : https://www.redhat.com/ko/topics/containers/what-is-docker

Docker란? What is docker? 도커 컨테이너, docker container 실행

도커는 리눅스 컨테이너 생성 및 실행을 위한 컨테이너 기술을 뜻합니다. 오픈소스 Docker는 컨테이너를 경량화된 모듈식 가상 머신처럼 다룰 수 있도록 지원합니다.

www.redhat.com

맞다.. 나 이제 더 이상 물러날 곳이 없다..!

16기 마무리 잘해봐야한답 !

실전 프로젝트다.. 6주 열심히해야지 6_6..

[ WIL ] ( Week 7 주차) 협업을 진행하며 느낀 아쉬운 점, 뿌듯한 점

2frost — Thu, 28 Sep 2023 21:57:39 +0900

팀플 짤. jpg를 찾으면 대개는 이러한 것들이 나온다.

팀플 썰들을 들어보면 긍정적인 것보다는 부정적인 것이 많았고, 어느 한 명의 희생을 요구하는 일도 있었으며 대부분은 소통의 부재와 탈주자들, 잠수를 타버리는 사람들이 발생되곤 했다.

이번 프로젝트는 2주간 이루어지는 프로젝트였다. 나는, 서비스팀과 챌린 진 팀의 선택의 기로에서 챌린지 팀을 선택했다.

원래 내가 추구해 온 스타일 대로라면 서비스팀이 맞지만 ( Fornt-end 와의 협업 경험과, 서비스분야를 개발해보고 싶어서 ) 협업을 하기에는 공부량이 조금 부족했다는 생각에 챌린지팀에서 조금 어려운 주제라도 부딪혀 가면서 배우자는 생각을 했다.

각설하고, '이번 프로젝트(협업) 경험이 나에게 어떠했냐?'라고 물어본다면.

1. 나의 부족함을 많이 알 수 있었다.

'챌린지팀'이라는 이름이 붙은 만큼, 평소 잘하신다고 하시는 분들이 우리 조에 많이 있었고 그 덕분에 배울 수 있는 시간이 많이 되었다.

처음에는 실력적인 부분에서 차이를 느꼈고, level5 미션을 제대로 완수하지 못하고 투입이 되었던 나는 다른 분들에 비해서 OOP에 대한 이해도가 조금 떨어져 있는 상태였기에 빨리 배워야겠다는 조급한 마음만 컸던 것 같다. 오히려 어떤 것을 먼저 해야 할지 몰라 이것저것 해보다 낭비해 버린 시간들이 많았다. ( 아마도 어떤 것을 모르는지 정확히 메타인지가 되어있지 않은 상태였던 것 같다. )

조별 멘토링 시간에 기술매니저님이 남들과 비교하지 않는 것이 가장 중요하다는 말이 잔잔하게 계속 생각이 났다.

2. 컨디션 조절을 잘하지 못했다.

내 부족함을 인지하는 순간부터 심적 스트레스가 많이 심했다. 그게 곧 스트레스로 이어졌고 컨디션이 급속히 나빠지기 시작했다.

어쩌면 건강관리도 스케줄을 소화해내야 하는데 가장 큰 부분이기에 조별활동을 하는 데에 있어 나 스스로 지켜야 할 문제이나 그러지 못했다.

그래서 팀원들에게 미안하다는 말을 해야 할 때가 많이 있었다. 조금 더 차분하게 나를 다스리면서 프로젝트를 진행했다면 좋았을 것 같다는 생각을 했다. 나 스스로가 컨디션 조절을 하지 못했던 게 너무 아쉬웠다.

3. 그럼에도 뿌듯했던 점은

팀원들이 상황을 잘 이해해 주었고, 끝까지 프로젝트를 잘 완수했다는 점이다.

소통에 있어서 크게 어려웠던 부분이 없었고 (물론 내 느낌이었을 수 있지만) 매일 회의를 한 내용들을 문서화해서 다음에도 확 일이 가능하도록 했다. 매번 팀 프로젝트는 힘든 게 맞다. 시간도 맞춰야 하고 합도 맞춰야 한다. 누군가와 속도를 맞춰주는 일이 얼마나 어렵겠는가.

그럼에도 늘 끝날 때는 한 보따리씩 배워간다. 나는 이야기를 통해서 그 많은 것들을 배운다고 생각한다. 소통이 없으면 결국 남는 게 없다.

아무튼, 다음 프로젝트에도 많이배워야징..ㅎ..

[ TIL ] [ 정규과정 : 주특기프로젝트주차 ] HTTPS / HTTP

2frost — Thu, 21 Sep 2023 02:28:09 +0900

* 이번 주특기프로젝트에서 https로 배포해야 하는 부분이 있었다.

배포환경에 맞춰 설정을 하면서 알게 된 것과 추가로 공부한 것들을 오늘자 til에 기재해야겠다.

Https를 왜 써야할까?

HTTPS는 TLS 암호화를 갖춘 HTTP. HTTPS는 TLS(SSL)를 사용하여 일반 HTTP 요청과 응답을 암호화하므로 더 안전하고 보안이 강화됩니다. HTTPS를 사용하는 웹 사이트의 URL 앞에는 http:// 대신 https://(예: https://www.cloudflare.com)가 있다.

웹 사이트에서는 왜 HTTPS를 사용해야 할까?

1) HTTPS를 사용하는 웹 사이트는 사용자가 더 신뢰할 수 있습니다.

HTTPS를 사용하는 웹 사이트는 지역 식품 안전 검사관으로부터 "합격"을 받았음을 게시하는 식당과 같다.

잠재 고객은 큰 부작용 없이 해당 업체를 이용할 수 있다는 것을 신뢰할 수 있다.

요즘 같은 시대에 HTTP를 사용하는 것은 식품 안전 검사 "불합격" 표시를 게시하는 것과 같다. 고객에게 뭔가 안 좋은 일이 발생하지 않는다는 보장이 없다.

HTTPS는 SSL/TLS 프로토콜을 사용하여 통신을 암호화하므로 공격자가 데이터를 탈취할 수 없다.

또한 SSL/TLS는 웹 사이트 서버가 실제 서버임을 확인하므로 사칭이 방지된다. 이는 식품 안전이 질병을 예방하는 것과 마찬가지로 여러 종류의 사이버 공격을 차단한다.

일부 사용자는 SSL/TLS의 이점을 인식하지 못할 수도 있지만, 최신 브라우저에서는 어떤 경우에도 웹 사이트의 신뢰성을 인식하도록 하고 있다.

▶︎ Chrome 등의 브라우저에서는 모든 HTTP 웹 사이트를 "안전하지 않음"으로 표시한다.
Google에서는 여러 해에 걸쳐 점진적으로 조치를 취하여 웹 사이트에 HTTPS를 도입하도록 했다.

Google 또한 검색 결과를 반환하는 방식에서 품질 요소로 HTTPS를 사용하며, 웹 사이트의 보안 수준이 높을수록 방문자가 Google이 제공한 링크를 클릭함으로써 실수할 가능성이 낮아진다.
2018년 7월 Chrome 68 출시와 함께 보호되지 않은 모든 HTTP 트래픽은 URL 표시줄에 '안전하지 않음'이라고 표시된다. 이 알림은 유효한 SSL 인증서가 없는 모든 웹 사이트에 표시된다. ( *다른 브라우저도 그 뒤를 따름 )

2) 사용자와 웹 사이트 소유자 모두에게 HTTPS가 더 안전하다.

HTTPS를 사용하면 원본 서버로 전송되는 데이터와 원본 서버에서 수신되는 데이터의 양방향 전송이 모두 암호화됩니다. 프로토콜은 악의적인 당사자가 전송되는 데이터를 관찰할 수 없도록 통신을 안전하게 유지한다. 따라서 사용자가 양식에 사용자 이름과 비밀번호를 입력할 때 이들 정보가 전송 중에 도난당하지 않는다. 웹 사이트나 웹 애플리케이션에서 사용자에게 중요한 데이터나 개인 데이터(예: 은행 계좌 정보)를 전송해야 하는 경우, 암호화를 통해 해당 데이터도 보호될 수 있다.

3) HTTPS에서는 웹 사이트가 인증된다.

Uber나 Lyft와 같은 차량 공유 앱의 사용자는 운전자가 픽업하러 왔다고 말한다고 해서 낯선 차에 무작정 올라탈 필요가 없다. 대신 앱에 운전자의 이름과 외모, 운전하는 차량의 종류, 차량 번호 등 운전자에 대한 정보가 표시된다. 공유 차량이 모두 다르고 운전자를 한 번도 본 적이 없더라도 사용자는 이러한 사항을 확인해서 올바른 차량에 탑승하게 되는지 확인할 수 있다.
마찬가지로 사용자가 웹 사이트를 탐색할 때 실제로 하는 일은 한 번도 본 적 없는 사람이 관리하는, 잘 알지 못하고 먼 곳에 있는 컴퓨터에 연결하는 것이다. HTTPS를 활성화하는 SSL 인증서는 차량 공유 앱의 운전자 정보와 같다. 이는 신뢰할 수 있는 제삼자가 웹 서버가 자칭하는 실체임을 외부에서 검증하는 것을 의미한다.
이를 통해 공격자가 웹 사이트를 사칭하거나 스푸핑 하여 사용자가 실제로는 가짜 사이트에 접속하고 있는데도 의도한 사이트에 접속한 것처럼 보이게 하는 공격이 방지된다. 또한 HTTPS 인증은 회사 웹 사이트가 합법적으로 보이도록 하는 데 많은 도움을 주며, 이는 회사에 대한 사용자의 태도에도 영향을 준다.

HTTPS에 대하여 오해와 진실

"웹 사이트에서 중요한 정보를 취급하지 않으므로 HTTPS가 필요하지 않다"

예를 들어, 일부 인터넷 서비스 공급자는 실제로 HTTP로 제공되는 웹 사이트에 광고를 삽입한다. 이러한 광고는 웹사이트의 콘텐츠와 방향이 일치하거나 일치하지 않을 수 있으며, 웹사이트 수익을 공유하지 않는다는 사실은 제쳐두더라도, 잠재적으로 공격적일 수 있다. 사이트의 보안이 확보되면 이러한 삽입 광고는 더 이상 실행할 수 없다. 최신 웹 브라우저에서는 이제 안전하지 않은 사이트에 대하여 기능을 제한합니다. 웹 사이트의 품질을 향상하는 중요한 기능에는 이제 HTTPS가 필요하다. 위치 정보, 푸시 알림, 프로그레시브 웹 애플리케이션(PWA)을 실행하는 데 필요한 Service Workers는 모두 강화된 보안을 필요로 한다.

"페이지 로드 시간을 늘려 웹 사이트의 성능을 저하시키고 싶지 않다"

시간이 지남에 따라 HTTPS가 개선되어 암호화된 연결을 설정하는 데 필요한 성능 오버헤드를 줄일 수 있게 되었다.

TLS 세션 재개 및 TLS 잘못된 시작을 포함하여 연결 생성의 총 대기 시간을 줄이기 위해 TLS에 개선 사항이 구현되었다.
세션 재시작을 사용하면 서버가 추가 요청에 대해 동일한 세션을 다시 시작하여 연결을 더 오래 유지할 수 있습니다.

연결을 유지하면 클라이언트가 캐시 되지 않은 원본 가져오기를 요구할 때 연결을 다시 협상하는 데 소요되는 시간이 절약되므로 총 RTT가 50% 감소했다.

"HTTPS를 구현하려면 비용이 너무 많이 든다"

이제는 더 이상 비용이 걱정되지 않습니다. Cloudflare에서는 웹 사이트에 무료로 전송을 암호화하는 기능을 제공합니다.

출처 : https://www.cloudflare.com/ko-kr/learning/ssl/why-use-https/#

아래는, 프로젝트에서 https를 사용하기 위해 변경한 부분이다.

https를 사용하는 경우, 쿠키를 안전하게 전송하고 보호하기 위해서 아래와 같은 설정이 필요하다.

[기존코드]

// 사용자 로그인 API
res.cookie('Authorization', `Bearer${accessToken}`, {httpOnly: true});
res.cookie('refreshToken', refreshToken, {httpOnly: true});

//accessToken 재발급 API
res.cookie('newAccessToken', newAccessToken, {httpOnly: true});

문제점 : http에서만 사용될 수 있도록 설정되어 있어서 https 배포환경에서는 로그인이 되지 않는다.

( * 확인하는 방법 : 터미널에서 ubuntu로 접속해 있을 때, pm2 log 명령어로 확인)

[ 해결방법]

httpOnly: true, 
sameSite: process.env.NODE_ENV === ‘production’ ? ‘none’: ‘lax’, // https 환경에서는 none으로 설정 
secure: process.env.NODE_ENV === ‘production’ //이 조건에 의해서 true 일 경우에 '쿠키는 HTTPS 연결을 사용하는 경우에만 브라우저로 전송한다.'

위 와 같은 설정을 추가로 해줘야 한다.

[변경된 코드]

// 사용자 로그인 API
res.cookie('Authorization', `Bearer ${accessToken}`, cookieOptions)
res.cookie('refreshToken', refreshToken, cookieOptions);

//accessToken 재발급 API
res.cookie('newAccessToken', newAccessToken, cookieOptions);

뭐 했는데

벌써 프로젝트 일주일 뚝딱 갔죠?

.....

이러다 눈 감았다 뜨면 항해 끝났겠네..

[ WIL ] ( Week 6 주차) 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)

2frost — Sun, 17 Sep 2023 23:26:33 +0900

[교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)]

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다.

교차 출처 요청의 예시: https://domain-a.com 프런트 엔드 JavaScript 코드가 XMLHttpRequest 사용하여 https://domain-b.com/data.json 요청하는 경우.

보안 상의 이유로, 브라우저는 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다. 예를 들어, XMLHttpRequestFetch API는 동일 출처 정책을 따름. 즉, 이 API를 사용하는 웹 애플리케이션은 자신의 출처와 동일한 리소스만 불러올 수 있으며, 다른 출처의 리소스 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해야 한다.

CORS 체제는 브라우저와 서버 간의 안전한 교차 출처 요청 및 데이터 전송을 지원합니다. 최신 브라우저는 XMLHttpRequest 또는 Fetch와 같은 API에서 CORS를 사용하여 교차 출처 HTTP 요청의 위험을 완화한다.

어떤 요청이 CORS를 사용할까?

교차 출처 리소스 공유 표준은 웹 브라우저에서 해당 정보를 읽는 것이 허용된 출처를 서버에서 설명할 수 있는 새로운 HTTP 헤더를 추가함으로써 동작한다. 추가적으로, 서버 데이터에 부수 효과(side effect)를 일으킬 수 있는 HTTP 요청 메서드(GET 제외한 HTTP 메서드)에 대해, CORS 명세는 브라우저가 요청 OPTIONS "프리플라이트"(preflight, 사전 전달)하여 지원하는 메서드를 요청하고, 서버의 "허가"에 떨어지면 실제 요청을 보내도록 요구하고 있다.

또한 서버는 클라이언트에게 요청에 "인증정보"(쿠키, HTTP 인증)를 함께 보내야 한다고 알려줄 수도 있다.

CORS 실패는 오류의 원인이지만, 보안상의 이유로 JavaScript에서는 오류의 상세 정보에 접근할 수 없으며, 알 수 있는 것은 오류 발생했다는 사실뿐이다. 정확히 어떤 것이 실패했는지 알아내려면 브라우저의 콘솔을 봐야 합니다.

이후 항목은 시나리오와 함께, 사용한 HTTP 헤더의 상세 내용을 다룬다.

출처 : https://developer.mozilla.org/ko/docs/Web/HTTP/CORS

교차 출처 리소스 공유 (CORS) - HTTP | MDN

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라

developer.mozilla.org

자주보는 얄코님의 강의에서 CORS에 대한 내용을 보아서, 내용을 다시 한번 정리해 보았다.

YOUTUBE 얄팍한 코딩 - 웹개발 짜증유발자! CORS가 뭔가요?

한 사이트에서 주소가 다른 서버로 요청을 보낼 때 자주 접하게 되는 오류 CORS

주소가 ‘어쩌고’ 닷컴에서 URL ‘저쩌고’ 닷컴 서비스에 API로 정보를 받아오기 위해서 프런트에서 HTTP요청을 보냈을 때 미리 어떤 설정을 해 주지 않으면 CORS문제로 막히게 된다. ( * postman과 같이 디른 걸로 요청하면 다되는데, 웹으로 하면 막힐 때가 많음 ).

▶︎ 웹사이트에서! 즉 브라우저인 프런트엔드에서 AJAX를 보낼 때마다 안됨 ( 크롬 / 에지 / 사파리 )

CORS는 왜 있는 걸까?

예를 들어 착한 닷컴이라는 사이트가 있다고 가정하자.

어떤 사이트에 로그인하면, 다음에 접속할 때 로그인이 유지가 되어야 하는데 그것을 캐시라고 한다.

내 로그인정보를 토큰으로 저장해서, 로그인했던 사이트에 접속할 때마다 요청에 실어 보내면 그 사이트에서 이 쿠키를 확인하고 로그인을 확인할 수 있다. 만약 내가 크롬을 통해 로그인을 진행했다면, 크롬에 내 정보가 저장이 되어있다는 것이 된다.

이때, 이러한 정보를 빼내기 위해 나쁜 닷컴을 만들어 악성메일이 이나 댓글을 통해 해당 사이트로 유인하게 할 수 있다.

나쁜 유저의 브라우저에 접속을 하면 Html / css / js 코드가 내 브라우저에 받아질 수 있다.

그렇다면, 나의 착한 닷컴에 저장된 내 정보를 가지고 악의적인 행동을 취할 수 있게 된다.

이뿐만 아니라 다른 API를 조작할 수 있기에 브라우저는 이를 방지한다.

CORS(Cross-Origin Resource Sharing) 다른 출처 간의 리소스를 주고받을 수 있음,

SOP (Same-Origin Policy) 동일 출처 정책 (요청을 막는 것)

원래 서로 다른 출처끼리 요청을 주고받는 것은 안 되는 게 기본값이었다.

하지만, 웹 생태계가 다양해지면서 여러 서비스들 간에 보다 자유롭게 데이터가 주고받아질 필요가 생기게 되었다.

그런데 다른 사이트 간의 요청을 브라우저가 막고 있어 개발자들은 jsonp (*현재는 거의 사용하지 않음) 우회해서 사용했다.

이걸 합의해서 충족시키면 리소스가 공유되어 사용할 수 있을까 해서 만들어진 것이 CORS (교차 출처 자원 공유 방식)이다.

단, 조건이 있다.

요청을 받는 백엔드 쪽에서 허락할 다른 출처들을 미리 명시해 두면 된다.

백엔드 서버를 프로그래밍할 때 쓰는 프레임워크들을 살펴보면 CORS 옵션을 넣는 방법들이 쉽게 마련돼 있다. 여기다 허용할 사이트들을 적어주면 이제 거기서 지정한 사이트에서 이 서버로 얼마든지 HTTP요청을 보낼 수 있다.

아무나 보내도 되는 요청의 경우 일반적으로 별표, 와일드카드를 적어 넣으면 누구나 다 쓸 수 있다.

네이버 지도와 같은 api도, CORS를 허용해 주는 주소를 지정하는 페이지가 따로 있다.

여기서, header란, 데이터가 다른 곳으로 전송될 때

데이터의 맨 앞쪽에 붙은 보충 정보라고 보면 된다.

받는 쪽의 IP주소 사용할 프로토콜이나 옵션 등이 담기는데 이는 우편으로 치자면 봉투에 적인 내용이라고 볼 수 있다. (Header에는 요청하는 쪽의 schema 도메인, 그리고 포트가 담긴다. )

origin에서 보낸 출처값이 서버에 답장 헤더에 담긴 Access-control-allow-Origin에 똑같이 있으면 안전한 데이터로 간주하고 응답을 받아오게 된다.

토큰등 사용자 식별 정보가 담긴 요청은, 보다 엄격하다. 보내는 측 요청의 옵션에 credentials 항목을 true로 세팅해야 하고,

받는 쪽에서도 아무 출처나 다 된다는 와일드카드가 아니라, 보내는 쪽의 출처 웹페이지 주소를 정확히 명시한 다음 Access-control-allow-credentials 항목을 true로 맞춰줘야 한다. ( 브라우저에 저장된 쿠키가 나쁘게 쓰일 수 있어서 보다 조건을 높게 갖추어야 함 )

▶︎ Simple request 방식으로 get / post 등 일정조건의 요청에 사용됨

▶︎ Put / delete 등은 preflight 요청을 먼저 보내서 본 요청이 안전한지 확인하고 여기서 허락이 떨어져야 요청을 보낼 수 있다. ( 서버에 영향을 줄 수 있는 요청으로 먼저 허용여부 검증이 필요함 )

첨부 URL : https://evan-moon.github.i/2020/05/21/about-cors/

CORS는 왜 이렇게 우리를 힘들게 하는걸까?

이번 포스팅에서는 웹 개발자라면 한번쯤은 얻어맞아 봤을 법한 정책에 대한 이야기를 해보려고 한다. 사실 웹 개발을 하다보면 CORS 정책 위반으로 인해 에러가 발생하는 상황은 굉장히 흔해서

evan-moon.github.io

프로젝트 진행시 프론트와 연결하면서 위와같은 오류가 발생되었다.

Wil을 적기 위해서 CORS를 찾아보면서, 대부분의 제목들이 웃프지만 저러했다.

실제로 팀원들과 프로젝트를 하면서 첨부 이미지와 같이 CORS오류가 나는 것을 보기도 했다.

(트러블 슈팅에서 가져옴!)

협업을 하다 보면 심심치 않게 마주하겠지.

다음 주도 파이팅 해야지! ㅇ ㅏ자!