Server 9주차 워크북

목차

1. 학습 목표 🎯

1. 정규식에 대한 이해 및 적용
2. 테스트 환경, 프로덕트 환경의 분리의 이해 및 적용
3. Social Token, In-app 결제 흐름에 대한 이해

2. 9주차 수업 후기 ✏

 

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

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

3. 실습 💻

미션없음!!!

4. 개념 키워드 🔑

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

• Regex
  • 정규표현식 표현방법
  정규표현식은 표준인 POSIX의 정규표현식과 POSIX 정규표현식에서 확장된 Perl방식의 PCRE가 대표적이며, 이외에도 수많은 정규표현식이 존재한다.
• 정규표현식(Regular Expression)을 소개합니다.
• 특정한 규칙을 가진 문자열의 집합을 표현하는데 사용하는 형식 언어이다. 주로 Programming Language나 Text Editor등 에서 문자열의 검색과 치환을 위한 용도로 쓰이고 있다.
• OAuth
  • OAuth의 배경
  • 개인정보를 여러 곳에 입력하면서 피싱에 둔감해지고 무엇보다 Application이 안전하다는 보장이 없기 때문에 보안에 취약했습니다.
• 간단하게 인증과 권한을 획득하는 것이다. 인증은 시스템 접근을 확인하는 것 (로그인) → 인증만 하는 것은 openID, 권한은 행위의 권리를 검증하는 것.
• OAuth 원리와 과정
  • OAuth 1.0문제점 : 구현이 복잡, 웹이 아닌 app에서의 지원이 부족, 인증 토큰이 만료되지 않는다.
  • 
  • OAuth 2.0
    • OAuth 1.0과 달라진 점
      • 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어 졌다
      • 1.0a는 만들어진 다음 표준이 된 반면 2.0은 처음부터 표준 프로세스로 만들어짐.
      • https가 필수여서 간단해 졌다.
      • 암호화는 https에 맡김.
      • 1.0a는 인증방식이 한가지였지만 2는 다양한 인증방식을 지원한다.
      • api서버에서 인증서버를 분리 할 수 있도록 해 놓았다
    • OAuth 2.0 구성
      • Resource owner: 사용자.
      • Client : Resource Server 에서 제공하는 자원을 사용하는 애플리케이션 (예, 페이스북의 뉴스를 모아서 보여주는 앱)
      • Resource server(API server): 자원을 호스팅하는 서버, (예, 페이스북 사진 비디오 등)
      • Authorization Server: 사용자의 동의를 받아서 권한을 부여하는 서버, 일반적으로 Resource Server 와 같은 URL 하위에 있는 경우가 많음
    • OAuth 2.0 과정
    • 
• 논리적 Validation보통 중복 검사를 한다. (DB에서 받은 것 심사)
• Provider와 Service에 있어야 하는 예외처리.
• 형식적 Validation빈 값, 길이, 정규표현식
• Controller에 있어야함
• Test Env, Prod. EnvProd env는 실제 서버 EnV
• 환경 분리를 통한 서버 분리 실시
• Test Env는 테스트를 하는 Env
• Social Token액세스 토큰은 카카오 계정으로 성공적으로 로그인 했음을 증명하는 암호문 형태의 증서입니다. 액세스 토큰에는 만료 기한이 있어 영구적인 것이 아닙니다. 오히려 보안상 이유로 짧은 유효 기간을 가지고 있다고 합니다
• Refresh token은 긴 유효 기간을 가지고 있습니다. Access Token이 만료됐으나 Refresh token이 만료되지 않은 경우, Access Token을 갱신하여 유효하게 할 수 있습니다.
• 사용자 토큰은 Access Token과 Refresh Token
• In-app Billing
  1. 애플리케이션에서 사용 중인 In-app Billing API의 대상 버전이 지원되는 버전인지 확인하기 위해 Google Play로 isBillingSupported 요청을 보냅니다.
  2. ********사용자의 인앱 구매를 쿼리하려면 getPurchases 요청을 보냅니다.
  3. 요청에 성공하면 Google Play는 구매한 아이템의 상품 ID 목록, 개별 구매 세부정보 목록, 구매를 위한 서명 목록이 포함된 Bundle을 반환합니다.
  4. Google Play에서 정의한 인앱 상품의 세부정보를 쿼리하기 위해, 애플리케이션이 getSkuDetails 요청을 보낼 수 있습니다.
  5. 사용자가 인앱 상품을 소유하고 있지 않으면 상품 구매를 시작할 수 있습니다.
•