UMC iOS 10주차 세미나

 

 

 

 

 

 

 

마지막 세미나 시간! :)

 

 

 

 

이번주의 실습은 없다! 이론 위주의 수업이 될 것

 

 

 

 

 

 

 

 

 

 

1. encoding 타입도 제이슨으로 보내야한다.

 

 

 

2. addingPercentEncoding - 깨지지 않도록

 

 

 

최신기술이라는 한글이 url에 들어갔을 때, 깨지지 않도록 하는 것

 

 

 

 

 

 

3. 스위프트가 허가되지 않은 HTTP 통신을 막음 

-> infoPlist에서 설정해주어야 한다. (빌드부터 에러남)

- 나도 발생했던 에러! 

 

공공 api 사용 시 문제가 될 수 있다.

 

 

 

 

 

검색 키워드

 

 

 

 

+ kingFisher - 이미지 처리/캐싱 작업을 편리하게 하도록 하는 대중적인 라이브러리

 

 

 

 

성장 가능한 iOS 개발자가 되려면?

라이브러리의 기본적인 작동 원리는 알고 쓰자

 

 

 

 

 

 

 

 

지난 주에 간단하게 알아본 서버 통신 

본격적으로 서버를 다루기 전에, 알아보면 좋을 내용이다.

가장 어려웠던 과정이 처음으로 서버를 iOS에서 활용할 때였던 기억이 있다.

 

 

 

로그인 이후의 기능

 

 

 

 

로그인은 앱서비스의 가장 기본적인 기능

개발자 입장에서는, 로그인 이후의 뒷과정이 더 중요하다.

생각해보면 좋을 것 - 우리가 어플 사용할 때 로그인 이후에 어떤 일이 일어나는지?

자동 로그인(User defaults), 마이 페이지 탭, 로그인 정보와 연동된 데이터들, 닉네임, 프로필

커뮤니티 어플에 내가 작성한 게시물, 내가 찜한 물품들 -> 나의 개인정보를 바탕으로 가져오는 정보

다른 ID로 접근한다면? 해당 사용자에 맞는 데이터가 불러올 것이다.

 

 

 

 

 

3가지 대표적인 로그인 구현 방식이 있다.

 

 

 

 

묶어서 부르는 경우가 많다.

 

 

 

쿠키 - 구글 설정에서도 볼 수 있다.

찾아 들어갈 필요도 없이, 웹 서비스를 사용하다 보면 쿠키 관련 문구를 많이 볼 수 있다.

쿠키란? 사용자가 삭제하지 않는 이상, 계속 남아 유저의 정보를 저장하는 것

크롬 쿠키 or 캐시를 삭제하면? 기존에 유지되던 로그인들이 풀리게 된다.

자동 로그인 / 자동으로 유저의 정보를 저장하는 것과 관련이 있다.

 

 

 

 

로그인 하는 과정 _ 이후 특정 기능을 활용하는 flow

 

 

 

 

1. 사용자가 로그인을 한다

2. 서버에서 회원 DB에 저장되어있는지 확인한다. (회원가입이 된 유저인지 확인)

3. 로그인 과정에서 session 저장소에 들리게 된다. 왜?

4. 서버가 세션 아이디를 발급하기 위해서 들리는 것!

5. 사용자에게 응답으로 넘어가게 된다.

6. 사용자에게 쿠키로 세션 아이디가 저장되게 된다. (우리도 모르게 저장되는 것)

쿠키에 넘어간 세션 아이디는 어떻게 사용되는가?

네이버 로그인 - 블로그, 카페, 음악, 클라우드 서비스 등등 유저의 고유 정보를 바탕으로 다른 기능을 사용할 수 있는 것 

각각의 서비스마다 로그인 과정? 서버 비효율

따라서 사용자의 쿠키를 바탕으로 데이터를 요청한다. 

세션 아이디 발급 - 쿠키만 검증하면 따로 로그인 할 필요 없이, 사용자 식별이 가능하다.

이러한 목적을 위하여 쿠키에 저장하는 것

쿠키에 저장된 세션 아이디를 바탕으로 유저 인식 -> 바로 응답을 줄 수 있게 된다.

따라서 이러한 과정을 통해 크롬을 껐다가 켰을때, 로그인 할 필요가 없는 것 (쿠키에 세션 아이디가 저장되어있으니까 꺼내서 보면 됨. 바로 메일함으로 들어가게 된다.)

 

보통 웹브라우저에서 많이 사용되는 방식 

장점 - 개발자들이 빠르게 구현하기가 쉽다

단점 - 누구나 접근할 수 있는 공공 PC에 남기기 찝찝한 경우가 많다.

개인 정보를 남기지 않기 위해서 지우는 경우가 많다

세션 아이디가 쿠키에 저장된다.

쿠키에는 접속한 사이트들 등 기본 정보들이 모두 저장됨

쿠키가 유출되거나, 악의적인 해커의 조작으로 변조되면

개인정보가 유출되거나 변조될 수 있어 위험성이 있다.

 

 

 

 

 

서버 개발자와 협업할 때 정말 많이 활용되는 방식

 

 

 

반드시 기본 개념은 익혀둬야 한다.

쿠키 세션 방식과 매우 유사하다.

 

 

 

 

서버에서는 토큰을 발급하여 클라이언트에게 넘겨준다.

 

 

 

세션 아이디처럼 토큰을 넘겨준다

고유한 유저의 정보가 필요한 API를 호출할 때마다 

헤더에 발급받은 토큰을 넣은 상태로 호출하게 된다.

헤더를 열어서 토큰을 보면 유저를 식별할 수 있다.

 

쿠키 세션 방식과 거의 동일한데, 

쿠키/세션 방식은 저장된 쿠키를 보내는 것

JWT는 토큰을 헤더에 집어넣는다는 것이 차이점

 

 

 

토큰을 열어봤을 때 모습

 

 

 

토큰의 구조

3가지로 나누어져 있음

헤더 / 내용 / 서명

 

 

 

JSON 포맷으로 구성된 JWT 토큰

암호화 된 문자열로 구성 -> 내용을 알아보기 힘들다

전공생이라면 암호화 수업에서 배울 수 있다.

특정 문자를 암호화할 때 어떻게 하는가?

누구나 쉽게 볼 수 없도록 여러 방식을 사용할 수 있는데,

암호화 방식을 알려주는 것들 중 하나가 헤더이다.

(이러한 방식으로 암호화가 되어있습니다 알려줌)

 

중간 주황색 부분 - 실질적인 토큰의 내용

 

노란색 부분 - 서명

내용이 변조되지 않았는지, 바뀐 내용은 없는지

잘못된 정보는 없는지 테스트하는 부분이 서명 부분이다.

 

 

 

 

 

JSON 포맷으로 구성된 토큰 - 해독하면 평범한 JSON 형식

 

 

 

 

 

 

소셜 로그인 구현 중 API 문서에서 봤을 것이다.

 

 

소셜 로그인을 할 때 사용하는 로그인 구현 방식

 

 

 

쿠키/세션 방식과 JWT를 합쳐놓은 방식!

 

 

 

- 앱에서 처음 로그인 화면

- 앱 자체에 로그인하는 것이 아니라 카카오에 로그인하는 과정

카카오에서 제공하는 SDK를 통하여, 유저 입력 정보를 바탕으로 카카오 DB에 접근 

카카오 DB에서 유효한 유저인지 확인한다 -> 카카오에서 확인 받은 유저의 정보를 받아온다.

 

- 서버 개발자가 보내준 API

- 올바른 아이디로 카카오에서 클라이언트에 넘어온 유저 정보를 바탕으로

해당 유저는 우리의 서비스에 로그인하게 된다.

- JWT 토큰 발급 -> JWT 방식과 동일하게 넘어간다.

 

 

 

 

JWT의 장단점을 알아보자

쿠키 세션과 JWT -> 둘이 합쳐지면 OAuth 방식이다.

JWT 방식의 가장 큰 방식 (JSON과 토큰)

- JSON은 익숙한 개념. 토큰이란? 

 

 

 

 

 

화폐처럼 통용되는 고유한 인증서

 

 

 

 

TOKEN: 고유한 유저의 정보를 인증하는 수단

사용자를 식별하는 인증서 개념 (토큰 만료, 토큰 갱신)

유저의 정보를 서버와 송수신할 때 인증하는 수단

 

 

 

 

문제 - 토큰이 외부에 유출되면, 개인정보 유출 - 변조 위험이 있다.

 

 

 

 

Access Token / Refresh Token

토큰이 외부에 유출되었을 경우를 대비하여 대처 - 토큰에 종류를 두는 것 

서버 호출 시 활용되는 토큰은 Access Token

Access Token이 유출되면? - 해커로 인해 개인정보 유출 및 변경 가능성

따라서 서버와 약속 - Access Token에 유효 기간을 부과한다. (ex. 1시간 이후 만료됨)

해커가 갈취했더라도, 활용할 수 없도록 유효 기간을 부여한다.

 

Refresh Token : 갱신하는 토큰 

Access Token이 만료되었을 때, Refresh Token를 사용하여 Access Token 갱신

Refresh Token도 만료되거나, 해커에게 갈취되면 어떻게 하냐? 

Refresh Token도 조금 더 긴 유효 기한이 있다. (Access가 1시간이라면, Refresh는 3일 정도라던지)

Refresh Token도 만료되었다면 (둘 다 만료) 자동으로 로그아웃이 되도록 설정

더이상 해커도 두 개의 토큰을 활용할 수 없게 된다.

 

 

 

 

 

서버 통신 이후는?

iOS 자체 디바이스의 DB를 활용하여

CoreData, UserDefaults, Key-Chain 등등

받아온 유저 데이터를 바탕으로 iOS 어플 구현

 

 

 

 

 

정규 과정 이외에 꼭 공부하면 좋을 내용

 

 

 

 

 

 

 

 

클로저 - 스위프트의 1급 객체

함수의 parameter로서 클로저를 넘길 수 있다.

클로저를 함수 내부에서만 작동할 수 있도록 막아두었다 - 탈출 불가 상태

컴파일러 최적화를 위해 애플에서 막아둔 것 

 

 

 

 

변수로 선언된 클로저 변수에, parameter로 넘겨받은 클로저를 대입할 수 없다. (외부로 탈출 불가능)

 

 

 

 

 

@escaping 키워드를 붙이면 에러가 사라진다!

 

 

 

 

어떠한 이점이 있는가? 어떻게 활용이 되길래?

escaping closure -> 함수가 반환된 이후 실행

함수들 간의 호출 순서 (실행 순서)를 부여할 수 있다.

https://hcn1519.github.io/articles/2017-09/swift_escaping_closure

 

네트워크 서버 통신 - API 호출에 걸리는 시간이 있다.

API 호출이 끝나기도 전에 함수가 종료될 수 있다.

5초 못기다리고 1초만에 함수가 종료되면?

서버 API 호출은 완료되지도 않았는데, 함수가 종료되어 의도와 다르게 동작할 수 있음 

즉, 함수가 서버 통신을 기다려줘야 함

 

이러한 경우 많이 활용되는 것이 escaping closure

함수의 종료와 무관하게 API 호출 로직을 보장할 수 있다.

탈출 가능하기 때문에, 함수 외부로 갈 수 있는 것

 

 

 

 

 

 

 

 

 

 

 

 

싱글톤 디자인 패턴

 

 

 

 

 

Class - 여러 VC에서 접근할 수 없다

 

 

 

 

Class - 여러 VC에서 접근할 수 없다 (추상)

class를 인스턴스화 해서 사용한다. 

여러 VC가 있을 때, class는 각각 인스턴스화 되어, 독립적인 객체로 선언하여 사용하게 된다.

즉 산재된 클래스들이 각각 동일한 정보를 들고 있지 않다. (오,, 우리 타스 천체 모델의 문제점!)

 

회원 가입 - 단계별 회원 가입 과정 

1단계 - 아이디, 패스워드

2단계 - 이름과 성별과 연락처

-> 결국 한 유저에 대한 회원 가입 과정

- 회원 가입 API parameter로 넘길 때 

각각의 class가 독립적으로 존재 -> 하나로 종합해야함

protocol delegate or VC 넘어갈 때마다 넘겨주면 - 비효율적

 

 

 

 

 

더 효율적일 순 없을까? 싱글톤 디자인 패턴 

하나의 고유한 객체로 구현할 수 있는 디자인 패턴 

스위프트에 국한된 것이 아니라, 소프트웨어공학적 기술

 

각각의 VC가 고유한 class에 접근할 수 있다.

 

 

 

 

하나의 객체에 데이터를 주입할 수 있음 

어떻게 구현하나?

 

 

 

 

class 내부에 static 타입으로 자기 자신의 property(객체)를 가지는 것

 

 

 

전역 변수를 활용하듯이

여러 VC에서 고유한 객체, class에 접근하여

데이터를 주입할 수 있다.

 

 

 

 

프레임워크들도 싱글톤 디자인 패턴으로 구현되어있는 경우가 정말 많다. (알라모파이어, 유저 디폴츠 등등)

 

 

 

AF도 알라모파이에서

싱글톤 디자인 패턴으로 구현된 

(AF. ) 객체를 활용한 것!

 

iOS 개발자라면, 꼭 개념을 알고 넘어가야한다.

 

 

 

 

---

 

 

 

 

두 달 반 동안 10주 간의 iOS 세미나를 마칩니다. 

10주간의 커리큘럼은 iOS 개발의 핵심적인 내용들이다.

이를 바탕으로 프로젝트를 하고, 개인적으로 공부를 하면서

밑바탕이 될 내용들. 이를 기반으로 나아갈 수 있을 것입니다.

 

처음에 새로운 환경에서의 개발에 적응하기 어려웠는데,

이러한 과정에서 우리가 도움을 받았다면 만족스러울 것이다!

 

 

 

 

 

 

 

이번 세미나의 목표 4가지 

1. iOS 개발에 흥미

2. iOS 개발의 공부 방법을 익힌다.

3. 개발 프로젝트 미션을 통해 실력 향상

4. 성장 가능한 개발자로 나아가는 것

 

 

 

 

 

 

 

 

마지막 UMC 실무 프로젝트

많은 어려움들이 우리의 실력이 될 수 있다.

10주 세미나를 따라오려고 노력했다면, 앞으로의

어려움도 스스로의 힘으로 해결할 수 있는 문제이다.

그간의 미션들이 난이도가 쉬운 미션들이 아니었다.

앞으로의 어려움도 미션보다 쉬울 수 있으니 포기하지 말고 공부해나가자!

(공식문서 보고, reference 참고하고 등등)