Server 8주차 워크북

목차

1. 학습 목표 🎯

1. 인증과 권한 부여(인가)에 대한 지식 습득
2. 로그인 유지 방법에 대해서 이해 및 적용
3. DB가 항상 정확하고 일관된 상태를 유지하는 방법

2. 8주차 수업 후기 ✏

📌 8주차 ****수업을 듣고 느낀 점과 각자의 과제 진행 상황을 서로 이야기해주세요!

이곳에 강의 내용을 정리해도 좋습니다 👍

3. 실습 💻

• API 추가 구현하기
• HTTP Method를 모두 사용해보기
• Path Variable, Query String, Body를 모두 사용해보기
• 형식적/논리적 Validation 추가하기
• API Sheet 작성

스탠다드 헤론/박세웅-3rd Server 인하대

4. 개념 키워드 🔑

📌 이번 주차 세미나에서 중요하게 다룬 키워드들입니다. 키워드에 대해 조사해본 후 해당 키워드에 토글 안에 자유롭게 정리해주세요!

• Stateless(무상태성)
  • Stateful(상태 유지)
  • 클라이언트의 요청1에 대한 상태를 해당 요청을 받은 서버A가 기억하고 있는 것으로 항상 같은 서버A가 유지되어야 한다.
• 무상태성이란? 서버가 클라이언트의 상태를 보존하지 않는 특징을 가지고 있다. 서버의 확장성에 용이하다는 장점이 있지만, 클라이언트가 추가 데이터를 전송해야 하는 단점이 있다.
• Request Header를 활용한 로그인 방식
• Request header에 계정 정보를 넣어서 보내는 방식. 권장하지 않음. http 방식으로 보내고 이를 탈취할 경우 사용자의 계정정보를 손쉽게 엳을 수 있다.
• 쿠키
  • 쿠키는 클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일이다.
  • 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다.
  • 쿠키가 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다.
  • 클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있음, 하나의 쿠키값은 4KB까지 저장한다.
  • Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.
  • 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송한다.
  • 쿠키 구성 요소
    • 이름 : 각각의 쿠키를 구별하는 데 사용되는 이름
    • 값 : 쿠키의 이름과 관련된 값
    • 유효시간 : 쿠키의 유지시간
    • 도메인 : 쿠키를 전송할 도메인
    • 경로 : 쿠키를 전송할 요청 경로
• 쿠키를 활용한 로그인 방식클라이언트에서 서버로 로그인 요청, Header에서 사용자 식별 id를 쿠키에 담아 전달, 그러면 클라이언트에서는 해당 쿠키를 저장해두고 사이트에 접속할 때마다 서버에 쿠키를 함께 전달한다.
• 
• 세션
  • 세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다.
  • 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
  • 물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능하다.
  • 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다.
  • 즉 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 된다.
  • 클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는 데 이것이 세션 ID입니다
• 세션을 활용한 로그인 방식Session은 쿠키에 비밀번호와 같은 인증 정보를 저장하지 않고, 대신 JSESSIONID(session id)라는 사용자 식별자를 저장한다.그 다음, 클라이언트가 서버에 요청을 할 때, 서버는 sessionId를 Key로 가지고 있는 value값을 조회하여 로그인 여부와 중요 정보 등을 확인한다.
• 만일 쿠키에 SessionId가 존재하지 않다면, 서버에 요청하여 SessionId를 받아 쿠키에 보관한다.
• 
• JWT(Json Web Token)
  • JWT 구조
    • Header(헤더)
      • typ : 토큰의 타입을 지정 ex) JWT
      • alg : 알고리즘 방식을 지정, Signature 및 토큰 검증에 사용 ex) HS256(SHA256) 또는 RSA
    • PayLoad(페이로드)
      • Registered Claim(등록된 클레임) : 토큰 정보를 표현하기 위해 이미 정해진 종류의 데이터. 선택적으로 작성 가능 ex) iss(토큰 발급자), sub (토큰 제목) 등등
      • Public Claim(공개 클레임) : 공개 클레임은 사용자 정의 클레임으로, 공개용 정보를 위해 사용된다. 충돌 방지를 위해 URI 포맷을 이용한다.
      • Private Claim(비공개 클레임) : 비공개 클레임은 사용자 정의 클레임으로, 서버와 클라이언트 사이에 임의로 지정한 정보를 저장한다
    • 토큰의 페이로드에는 토큰에서 사용할 정보의 조각들인 **클레임(Claim)**이 담겨 있다.
    • Signature(서명)
      • 서명 생성 방법
      • 서명(Signature)은 위에서 만든 헤더(Header)와 페이로드(Payload)의 값을 각각 BASE64Url로 인코딩하고, 인코딩한 값을 비밀 키를 이용해 헤더(Header)에서 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 BASE64Url로 인코딩하여 생성한다.
    • 서명(Signature)은 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드이다.
  • 
• JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달한다.
• Paging 처리
  • LIMIT문 사용으로 구현 가능
    • offset : (page - 1) * recordSize
    • recordSize : 페이지당 출력할 데이터의 개수를 의미합니다.

    select *
    from board
    order by id 
    LIMIT offset,recordSize;
    // offset = 0, recordsize = 10 이면 0 부터 10까지 게시글 보여줌 
    

  • LIMIT의 첫 번째 파라미터에는 **시작 위치(몇 번째 데이터부터 가지고 올 것인지)**를 지정하고, 두 번째 파라미터에는 시작 위치를 기준으로 가지고 올 데이터의 개수를 지정합니다.
• 페이징은 사용자가 어떠한 데이터를 필요로 할 때, 전체 데이터 중의 일부를 보여주는 방식이.
• Transaction작업의 단위 : 게시판에서 사용자가 올리기 버튼을 눌러 insert를 하고 게시판을 구성할 데이터를 다시 select하여 최신 정보를 유지하게 할 때 insert와 select문 둘다 를 합친 것이다.
  • Transaction의 특징
    • 원자성 (Atomicity) : 트랜잭션이 데이터베이스에 모두 반영되던가, 아니면 전혀 반영되지 않아야 한다는 것이다.
    • 일관성 (Consistency) : 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다는 것 이다.
    • 독립성 (Isolation) : 둘 이상의 트랜잭션이 동시에 실행되고 있을 경우 어떤 하나의 트랜잭션이라도, 다른 트랜잭션의 연산에 끼어들 수 없다는 점을 가리킨다.
    • 지속성 (Durability) : 트랜잭션이 성공적으로 완료됬을 경우, 결과는 영구적으로 반영되어야 한다는 점이다
  • 트랜잭션의 Commit, Rollback 연산
    • Commit이란 하나의 트랜잭션이 성공적으로 끝났고, 데이터베이스가 일관성있는 상태에 있을 때, 하나의 트랜잭션이 끝났다라는 것을 알려주기위해 사용하는 연산이다.
    • Rollback이란 하나의 트랜잭션 처리가 비정상적으로 종료되어 트랜잭션의 원자성이 깨진경우, 트랜잭션을 처음부터 다시 시작하거나, 트랜잭션의 부분적으로만 연산된 결과를 다시 취소시킨다.
• 데이터베이스의 상태를 변화시키기 해서 수행하는 작업의 단위를 뜻한다.