항해 99 5기 TIL_33

▶ Today I Learned

<CS>

 

[Transaction]

 

transaction: DB는 하나의 명령어로만 행동하지 않으며 추가, 업데이트, 삭제와 같은 행위 중 특정 단계에서 에러가 발생할 수 있음,

그렇게 되면 데이터 간의 불일치가 일어날 수 있음

이를 방지하기 위해 관련된 작업을 하나로 묶을 수 있으며 이 작업 단위는 성공하거나 실패해야 한다.

여기서 말하는 작업단위를 바로 트랜잭션이라고 한다.

 

참조 자료:

https://blog.naver.com/wkdgusrhkd97

 

 

[CORS]

 

Cross Origin Resource Sharing 교차출처 리소스 공유, 교차출처란 다른 출처를 의미

 

cf) SOP

Same Origin Policy, 같은 출처에서만 리소스를 공유할 수 있다는 규칙을 가진 정책

기본적으로 브라우저는 출처가 다른 사이트와 리소스 공유하는 것을 위 원칙에 의해 막아두었다.

출처가 다른 리소스 요청을 허용하는 예외를 만들어 주어야 하는데, 이를 위해 'CORS 정책을 지킨 리소스 요청'을 하여야 한다.

즉, CORS로 이 출처의 사이트는 괜찮아, 하고 지정해주어야 하는 것이다.

 

여기서 출처(origin)란 scheme(protocol), host(domain), port로 구성되어 있다.

https://www.google.com/maps

라는 url이 있다면 https://는 프로토콜, www.google.com은 host :443은 포트이다. (https의 기본포트는 443이라서 생략이 가능하다.)

CORS는 보안 문제 중 CSRF나 XSS를 방지해줄 수 있다.

 

CSRF (Cross Site Request Forgery): 사이트 간 요청 위조, 일단 사용자가 웹사이트에 로그인 상태에서 사이트간

요청 위조 공격 코드가 삽입된 페이지를 열면,

공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다.

공격 과정은 해당링크 참조

https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%9A%94%EC%B2%AD_%EC%9C%84%EC%A1%B0

 

XSS (Cross Site Scripting): 웹사이트의 관리자가 아닌 사람이 웹페이지에 악성 스크립트를 삽입하는 것

공격 과정은 해당링크 참조

https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8C%85

 

CORS 동작방식

 

1) 프리플라이트 요청 (Prefilght Request)

 

Option 메소드를 통해 다른 도메인의 리소스에 요청이 가능한지 (실제 요청이 전송하기에 안전한지)

확인 작업을 하고 요청이 가능하다면 실제 요청을 보낸다.

(Cross-origin 요청은 유저 데이터에 영향을 줄 수 있기 때문이다.)

 

2) 단순 요청 (Simple Request)

 

위와 달리 즉시 cross origin인지 확인하며 다음 조건을 모두 충족해야한다.

 

메서드는 GET, POST, HEAD 중 하나,

헤더는 Accept, Accept-Language, Content-Language, Content-Type만 허용,

Content-Type 헤더는 다음의 값들만 허용

application/x-www-form-urlencoded

multipart.form-data

text/plain

 

3) 인증정보 포함 요청 (Credentialed Request)

 

인증 관련 헤더를 포함할 때 사용하는 요청이다. 브라우저가 제공하는 비동기 리소스 요청 API인 XMLHttpRequest 객체나 fetch API는 별도의 옵션 없이 브라우저의 쿠키 정보나 인증과 관련된 헤더를 기본적으로 요청에 담지 않으므로, credentials 옵션을 변경하지 않고서는 cookie를 주고 받을 수 없다.

 

옵션종류

 

- omit : 절대로 cookie 들을 전송하거나 받지 않는다.

- same-origin : 동일 출처(same origin)이라면, user credentials (cookies, basic http auth 등..)을 전송한다. (default 값)

- include : cross-origin 호출이라 할지라도 언제나 user credentials (cookies, basic http auth 등..)을 전송한다.

 

 

이 외에도 위의 내용들은 하단의 링크를 참조하면 더욱 자세히 알 수 있다.

 

출처:

https://www.youtube.com/watch?v=bW31xiNB8Nc 

https://evan-moon.github.io/2020/05/21/about-cors/

https://ingg.dev/cors/

 

 

<알고리즘>

 

신고 결과 받기

시간: 1시간 20분 (이전에 들인 시간까지 해서 도합 6시간 이상 푼 것 같다.)

https://programmers.co.kr/learn/courses/30/lessons/92334

문제해결 여부: 미해결

 

실행 테스트는 통과하지만 예외처리 부족 + 성능 테스트 미 통과로 추측한다.

 

let id_list = ["con", "ryan"]

let report = ["ryan con", "ryan con", "ryan con", "ryan con"]

// ["ryan con", "ryan con", "ryan con", "ryan con"]

let k = 2

// 예상 결과 result 값 [2,1,1,0]

// 문자열 알파벳 소문자, 중복 아이디 x 동일 유저 신고 여려번 해도 1회로 처리

let i = 0
let reporters = []
let reported = []
let noDoubleReports = []

// 신고 중복검사
for (let j = 0; j < report.length; j++) {

  if(noDoubleReports.includes(report[j])) {
    j++
  } else {
    noDoubleReports.push(report[j]);
  }
}

// 중복검사로 걸러진 배열을 신고한 사람, 신고당한 사람으로 나누기
for(i; i < noDoubleReports.length ; i++) {

reporters.push(noDoubleReports[i].split(' ')[0]);
reported.push(noDoubleReports[i].split(' ')[1]);
}

// 신고당한 사람을 id 리스트 순서대로, 횟수대로 나열
let reportedListById = id_list.map((v, i) => reported.filter(x => x === v))

console.log(reportedListById)

let j = 0
let nameToFind = []

// 신고k번이상 당한사람 구하기
while(j<reportedListById.length) {

if (k <= reportedListById[j].length) {
   nameToFind.push(reportedListById[j][0]) 
 }
 j++
}

//이메일 보낸 횟수 구하여 배열에 담기
let emailList = []
let arr2 = report.map((v, i) => 
{if (nameToFind.includes(v.substring(report[i].indexOf(' ')+1))) {
return v = v.substring(0,report[i].indexOf(' '))
}})

id_list.map((v, i) => {
  emailList.push(arr2.filter(x => x === id_list[i]).length)
})

answer = emailList

return answer

 

팀원분들에게 여쭤보니 다른 해결 방안을 참조하여 푸셨다고 한다. 이 정도 고민하며 들었던 생각은

한 번에 집중해서 푸는 것이 아니라 4일에 걸쳐 고민을 하다보니 처음 작성할 때의 생각이 나지 않는다는 것이다.

덕분에 코드를 복기하는데만 해도 시간이 꽤 소모된다.

문제가 복잡할 수록 더욱 그렇기에 해답을 보며 한번 익히고 나중에 한번 더 풀어보도록 해야겠다.

 

<Figma>

 

웹 페이지를 만들기 전 와이어 프레이밍을 할 필요가 있다.

이때 사용되는 툴로 주로 sketch, Figma, Adobe XD가 있다고 들었는데 그 중 사용이 간편해보이는

Figma를 바로 써보기로 했다.

크게 특별한 기술은 필요하지 않았다. 그래서 프레임, 도형, 텍스트 정도만을 이용해 간단하게 몇 페이지를 아래와 같이

구상해보았다.

PPT로 할까하다가 나중에 쓰겠지싶어 한번 시도해본 것인데 사람들이 많이 쓰는데는 이유가 있나보다.

매우 간편했고 만들어둔 도형의 정렬이나 이동, 전체 틀의 이동, 변형 등이 아주 쉬웠다.

앞으로 종종 써보아야겠다.

 

 

▶ 느낀 점

비교적 순탄한 한 주의 시작이다. 지난 번 과제에서 끝내지 못한 부분을 제대로 짚고 넘어갈 수 있는 시간이 생긴 듯 하다.

팀 플레이 이므로 팀원들의 일정에 지장을 주지 않고 협업에도 열심히 참여하면서도

해당 부분은 확실히 한 번 더 연습해보아야지 :)

 

+ 개발자를 준비하며 삶의 스타일이 좀 더 주도적으로 바뀌는 것 같다.

어릴 적의 나는 90년생인 우리 형이나 사촌 형을 보며 문득 이런 생각을 했다.

'와, 큰형은 어떻게 외할머니댁에 잘 찾아가지?', '초등학생이 지도만 보고도 길을 찾아갈 수 있나??'

어린 나는 그저 주어진 상황에서 적당히 살아갔고 형들이라는 '선례자'가 있다보니 모르는 게 있어도

편하게 지식을 얻거나 따라다니기에 조금 익숙했던 것 같다.

그렇게 나이를 먹으며 점점 내 자신이 정말 회사에서 일을 할 수 있을지, 이건 어떻게 하고 저건 어떻게 할지 의문이 들었다.

새로운 상황을 마주하게 되면 마음 어딘가 모르게 불안하거나 불편했고 기왕이면 편하게 답을 찾길 바랬던 듯 하다.

그렇게 생각하다보니 이런 생각을 마주하게 되었다.

'나는 주도적으로 살아갈 수 있을까?'

 

주도적인 삶을 위해서는 겁나도 해보는 게 중요했다.

다행히 대부분 사람이 할 수 있는 일이고 뭐든지 해보면 막상 그렇게 어렵지 않거나 그때 그때 방법을 찾아나갈 수 있는 것들이었다.

어차피 삶의 많은 것에는 절대적인 정답이 있는 것도 아니기에 내가 했던 시도가 항상 틀린 것도 아니었고 다음을 위한 좋은 양분이 되었다.

이런 마음 가짐으로 새로운 일에 조금씩 부딪쳤던 나는 이제 개발자라는 삶에 뛰어들고 있다.

 

모르는 지식이 많고 심지어 어려운 내용들도 있어 간간이 자괴감이 들기도 하지만 괜찮다.

나는 여전히 나아가고 있으며 점점 성장해가는 모습이 보인다.

무엇보다 좋았던 건 모르는 걸 마주해도 누가 알려주기만을 기다리기 보다 '내가 찾아서 해보면 되겠지뭐, 일단 해보자.'라는 마인드가

좀 더 강해졌다는 것. 어떤 상황이든 문제를 해결할 방법은 있고 이를 찾기 위해 스스로 정보를 수집하고 시도해보고 있다.

 

그렇게 오늘도 살면서 단 한번도 써본적 없는 피그마를 필요한 만큼 사용해내고 협업 과정에 큰 도움이 되었다.

'아 내가 점점 이렇게 바뀌고 있구나, 주도적인 사람이 되어가고 있구나.' 라는 생각에 매우 뿌듯했던 하루이다.

내일은 더 열심히, 더 주도적으로 살아보는 내가 되어야지. 오늘 하루도 고생많았고 내일도 화이팅이다! :)

 

▶ 공부 시 참고 링크들

 

https://medium.com/@heizence6626/aws-%EC%9D%98-%EA%B8%B0%EB%B3%B8-%EC%84%9C%EB%B9%84%EC%8A%A4-s3-ec2-rdb%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC-1eb60cbd951d

AWS 의 기본 서비스 S3, EC2, RDB에 대하여