iOS2019. 5. 21. 12:36

Cookie?
쿠키는 브라우저세계에서 주로 세션관리, 사용자 프리퍼런스와 상태등을 주로 다루며 일반적이고 널리 사용된다.
서버에서 제공하는 작은 속성데이터이다. 웹브라우저에서 저장되며 서버에 요청시 공유된다.

쿠키구조
적은양의 데이터이지만 구조적이고 속성들은 쿠키의 동작을 정의한다. RFC6265, RFC2109

쿠키와 모바일앱
쿠키는 웹세계에서 사용되며 대부분 모바일개발자는 다룰필요가 없다. REST API 로 서버에 데이터를 요청한다. 대부분의 유스케이스와 앱에 맞다. 하지만 간혹 경계가 모호해지는 경우가 있다. 쿠키를 조작해야 하고 모바일앱은 이를 잘 수행한다.
SSO를 예를 들면 여러 시스템에서 세션을 공유해야 할것이다. 이때 쿠키가 이 목표를 달성할수 있게 해준다.

iOS에서 쿠키 다루기
NSHTTPCookie, NSHTTPCookieStorage라는 아주 잘 설계된 클래스 2개가 제공된다.

NSHTTPCookie클래스는 쿠키 데이터 클래스이며 필수 파라메터가 있다. name, value, domain or originalurl, path이다, 모두 제공되지 않으면 nil리턴된다.

NSMutableDictionary* cookieProperties = [NSMutableDictionary dictionary];

//set rest of the properties
[cookieProperties setObject:@"MyCookie" forKey:NSHTTPCookieName];
[cookieProperties setObject:@"cookie12345ytehdsfksdf" forKey:NSHTTPCookieValue];
[cookieProperties setObject:@"/" forKey:NSHTTPCookiePath];
[cookieProperties setObject:@".example.com" forKey:NSHTTPCookieDomain];
//create a NSDate for some future time
NSDate* expiryDate = [[NSDate date] dateByAddingTimeInterval:2629743];
[cookieProperties setObject:expiryDate forKey:NSHTTPCookieExpires];
[cookieProperties setObject:@"TRUE" forKey:NSHTTPCookieSecure];

NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];

HttpOnly같은 속성은 쿠키에서 중요하며 딕셔너리로 셋팅할수 없다. 위와 같은 방식의 쿠키생성은 유용하지 않은것 같다. 

권장되는 방식은 다음과 같다.

NSHTTPCookie에 더 훌룡한 API가 제공되는데 http response 문자열을 모두 덤프할 수 있고 HttpOnly를 포함해서 모든 필요한 속성이 셋팅된 완전한 쿠키를 리턴한다.

NSArray* httpCookies = [NSHTTPCookie cookiesWithResponseHeaderFields:[httpresponse allHeaderFields] forURL:url];

서버응답인 http response에는 키/밸류 쌍인 "Set-Cookie"로 일반적으로 넘어온다. 위 API는 쿠키문자열을 response로부터 취해서 cookie를 만든다. 여기서 URL이 중요하면서도 유용한다. 앞서 얘기한데로 쿠키는 필수파라메터로 name, domain, value, path가 있다고 했다. 하지만 RFC문서에는 Domain은 옵션이다 이는 빈도매인이 있을 수 있다는 것이다. NSHttpCookie클래스에는 originURL을 셋팅할수 없다. 딕셔너리로 쿠키를 생성하는 방법은 완전히 쓸모가 없다. 하지만 이 방법은 쿠키문자열에 domain이 없으면 originURL을 채우고 유효한 쿠키를 제공한다. 이에 더해 서버에서 전달한 추가적인 정보를 알아서 셋팅해준다. 이 방법이 경험적으로 쿠키를 만드는 가장 좋은 방법이다.

쿠키 저장
NSHTTPCookieStorage가 쿠키를 저장해준다.

[[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookie:cookie];

여기서 가장 중요한 특성은 iOS가 네트웍 요청에 도메인이 매칭된다면 자동으로 추가해준다는 것이다. 예를 들어 domain이 ".example.com"인 쿠키가 저장되어 있고 "www.test.example.com"으로 요청을 하게된다면 추가코드없이 자동으로 추가된다.

NSURLSession요청은 URL이 domain이 매칭되면 요청에 쿠키를 셋한다.  webview의 경우 아래와 같이 초기로드를 위해 저장소에서 액세스하여 쿠키를 추가 할 수 있다

NSURLRequest* request; //your request
[request setAllHTTPHeaderFields:[NSHTTPCookie requestHeaderFieldsWithCookies:[NSHTTPCookieStorage sharedHTTPCookieStorage].cookies]];
[request HTTPShouldHandleCookies];

Posted by 삼스

댓글을 달아 주세요

iOS2019. 5. 10. 16:47

이게 개념이 잡히지 않으면 개발환경 설정 시 마다 고생하기 마련이다.

이참에 정리를 좀 하자.

 

일단 기본적으로 애플은 앱실행권한을 관리를 하고 있다. 이 권한이 획득되지 못하면 앱이 실행이 될수 없다.

그러기 위해서는 애플로부터 인증서를 발급받아야 한다. 그리고 단말에서 실행을 하려면 프로비저닝이 단말에 설치가 되어야 한다.

프로비저닝은 단말과 애플인증서의 연결해주는 역할을 하며 권한을 획득하여 얻어지면 앱이 실행이 된다.

 

이 과정은

1. 애플인증서 생성

2. 프로비저닝 생성

3. 빌드 및 실행

이 되는데 하나하나씩 정리해 보자

 

1. 애플인증서 생성

개발자 PC에 키체인앱은 개인키와 공개키를 가지고 있다 이를 기반으로 먼저 CSR(Certificate Signing Request)을 먼저 만들어야 한다.

(1) 키체인 앱 실행

(2) 키체인접근 > 인증서 지원 > 인증기관에서 인증서 요청 선택

(3) 개발자의 이메일주소와 이름을 입력

(4) 요청항목의 "디스크에 저장됨" 선택

(5) 계속을 누르면 CertificateSigningRequest.certSigningRequest 파일이 저장된다.

 

저장된 CSR파일을 애플개발자 콘솔에 인증서 추가 화면에서 등록한다.

(1) https://developer.apple.com/ 접속 및 로그인

(2) Certificates, Identifiers and Profile > Certificates > Development 이동

(3) 추가버튼 누르고 iOS App Development선택하고 화면 안내에 따라 CSR파일 등록 

(4) 등록 완료되면 인증서 파일 다운로드

 

동일한 방법으로 Production의 AppStore and Ad Hoc선택하여 배포용도 등록

 

2. 프로비저닝 생성

프로비저닝은 앱아이디별로 생성이 가능하며 앱아이디를 먼저 등록해주어야 한다.

등록된 앱아이디로 Provision Profiles 화면에서 안내에 따라 개발과 배포용을 등록한 후 프로비저닝 파일을 다운로드 한다.

이 때 개발용의 경우 설치를 허용할 단말을 선택할 수 있는데 이 화면에서 선택한 단말들만 해당 프로비저닝으로 설치및 실행이 가능하다.

 

위 과정을 거치면 

1. 개발자의 공개키와 개인키

2. 애플이 인증한 인증서

3. 디바이스에 설치 가능한 프로비저닝

 

위 3가지로 빌드를 하면 .app파일이 생성되며 2가지로 구성된다.

1. 실제로 사용될 프로비저닝 프로파일 : 빌드시 사용된 프로비저닝이다.

2. _CodeSignature 폴더 : CodeResources 파일을 담고 있고 모든 파일의 암호화 해시정보를 갖고 있다.

 

AdHoc버전의 앱은 디바이스에 설치되어 실행될때 

 

1. .app에 포함된 프로비저닝 프로파일이 애플인증서로 서명되었는지 확인

2. CodeResources참조하여 모든 파일의 해시를 확인하여 무결성 체크

3. 디바이스에 프로비저닝 프로파일이 있는지 확인

 

위 과정을 거쳐서 실행된다.

 

엔터프라이즈배포의 경우는 애플은 그 회사를 신뢰하고 별도의 확인과정을 거치지 않고 바로 실행되게 해준다.

 

앱스토어배포의 경우는 그 어떤 디바이스에서도 실행될수 없다. 오로지 애플에 제출용으로만 사용이 가능하며 애플이 리뷰후 다시 사인하여 배포한다.

 

팁!)

새로운 팀원이나 다른 PC에 개발환경을 설정할 때 매번 애플인증서를 만들수는 없다.

이 때는 이미 등록된 인증서와 해당 인증서를 등록한 개발자의 키파일을 전달 받아서 설치해주어야 한다. 그러지 않으면 인증서의 출처를 확인하지 못하여 정상적으로 빌드가 안되는것 같다. 이 부분에 대해서는 정확히 아는 사람이 설명을 좀 해주었으면 ....

 



Posted by 삼스

댓글을 달아 주세요

iOS2018. 8. 4. 13:17


애플의 인앱결재의 자동결재를 정리한다.


종류는 다음과 같다.


  • 소비형 : 한번 사면 바로 소모됨
  • 비소비형 : 한번사면 평생 유효
  • 자동갱신형 : 주기적으로 재구매(결재)가 자동으로 이루어짐
  • 비갱신형 : 기간 만료되면 다시 구매를 해야 함.

자동갱신

애플에서는 해당 구매의 만료일 10일전에 결재인프라를 먼저 확인한다. 이 때 카드정보등이 유효하지 않으면 메일등을 보내서 갱신을 유도한다.

하루전에는 실제로 결재를 시도한다. 이 때 결재가 실패할 수 있다. 

두가지가 있을 수 있다.


  • 결제정보의 일시적인 오류
  • 정기결제기능을 off

위 상황에서는 결재가 실패하게 되며 사용자가 결재정보를 유효하게 갱신하거나 정기결재기능을 다시 on하게 되면 애플에서는 구매를 수행하게 된다. 이 때 부득이 지연이 발생한다.


앱을 서비스 하는 입장에서는 이런 지연이 발생 한경우를 파악하여 적절히 사용자에게 안내를 해야 불온한 의도를 가진 사용자들의 공격을 막아낼 수 있을 것이다.


재결제내역 확인

앱과 서버가 모두 수행하는것이 좋으며 일반적으로 서버에서 하는것이 좀더 안전하다. 왜 더 안전한지에 대한 설명은 찾아볼 수 없으나 예상으로는 앱은 해킹이 가능하기 때문으로 추정해본다. 


앱 기동시에는 addTransactionObserver를 호출하면 된다. 이 때 재구매건이 있으면 paymentQueue에 결제건이 들어오게 된다. 이 결재건을 사용자가 직접 구매했을 때 와 동일하게 처리하면 된다.


서버에서는 만료일이 가까워진 결재건에 대해서 original 결재정보로 apple서버에 조회하여 마지막 영수증정보과 최종 영수증 정보가 다르면 리뉴얼 된것으로 파악하면 된다.


영수증정보의 갱신

영수증정보는 동일계정으로 로그인 된 다른 단말에서 재구매가 일어나도 앱 기동시마다 영수증정보를 최신으로 유지하기 때문에 동기화가 가능하다.


현재 구매상태인지 여부 확인

최초 결제의 영수증의 transactionId가 originalTransactionId가 되며 이 후 재결제가 일어나면 새로운 영수증이 발급되며 이 때 transactionId도 갱신이 된다. 하지만 originalTransactionId는 최초의 값이 유지된다.

따라서 영수증 목록에서 originalTransactionId로 필터링 후 expireDate가 아직 미래인 영수증이 있다면 아직 구매중인것으로 판단하면 된다.


구매취소 여부 확인

영수증에 Cancelation Date가 있다면 구독취소한것으로 판단하면 된다고 한다. Cancelation필드가 있으면 ExpireDate와 관계없이 취소된 구독이다.



결재내역 복원하기





Posted by 삼스

댓글을 달아 주세요