iPhoneアプリでUDIDを使いたいケースその1


iOS 5からUDID取得APIがdeprecatedになるぞ、ってのを受けて、どんなときにUDIDを使いたくて、その代替策はどうなるかというケーススタディ。

まずは、機能を制限解除型で購入するアプリ。あるアプリをダウンロードして、一部の機能に制限がかかっている。In App Purchaseで購入することで、その制限を解除することができる。これをどうやってアプリで管理する?または、悪意あるユーザのクラックからどうやって守る?

いちばん簡単なのは、NSUserDefaultsにフラグを設定すること。

[[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"purchased"];

って感じでね。簡単だけど、初期設定のplistを書き換えることで、簡単に破られてしまう。

じゃあってんで、何らかの固定文字列のハッシュ値を書き込むようにしたらどうだ?これなら、もとの固定文字列がばれない限り破られない。これは、一度だけ誰かが購入して、そのplistをコピーすれば破られてしまう。CFUUIDでUUID作っても、同じ。そのもとのUUIDをどこに保存するの?ってことになる。

そこで、UDID登場。UDID + 固定文字列のハッシュ値を使うようにする。これならこの値が流出しても、同じUDIDを持つデバイスでしか使えない。少しまともになった。

この手法の問題点は、機種変更すると使えなくなってしまうこと。フューチャーフォンとは違い、iPhoneでは機種変更したら前のアプリが使えなくなってしまう、というふざけたことは許されない。これは、In App Purchaseを使っているときは、リストアすることで対応できる。

別の手法を検討してみる。キーチェーンを使う方法。キーチェーンの中に、購入済みフラグを設定する。いまのところ、これは使える。

問題点は、キーチェーンの中に保存した情報は、アプリを削除しても残ること。制限解除キーが永遠に残るのは気持ち悪い。あと、キーチェーンって基本的には、ネットワークサービスのパスワードのように、ユーザが何度も入力するのが面倒な情報を保存しておくものだ。つまり、ユーザがすでに知っている情報が保存されているっていうのが前提。制限解除キーみたいに、ユーザから隠したい情報を入れておくのってどうなのよ、という気はする。もしかすると、将来AppleがiPhone版のキーチェーンアクセスみたいなものを出してきて、キーチェーンの中の情報を自由に見れるようにするかもしれない。そうなると、お手上げ。

また別の方法を。今回はIn App Purchaseで購入するというのが前提なので、購入したかどうかの判断をStore Kitを使って行うことができる。iTunesのサーバにアクセスして、購入履歴をリストアすることで判断する。

これの問題点は、ネットワークアクセスが必要になることと、毎回ユーザにApple IDの入力を求めることになること。これはめんどくさい。また、Store Kitへのアクセスをユーザの操作無しに行うと、アプリ申請時にリジェクトされる恐れがある。Store Kitのアクセスは、アプリを削除して新規インストールした、バックアップもなくしちゃいました、というときに留めておくのが無難。

ということで制限解除の許可には、ユーザを識別できて、かつ書き換え不可能なIDが必要なわけで、それにはUDIDは手軽な手段だったんだよね。そういったIDは、他にはApple IDがあるけど、これアプリからは全うな手段では取得できないし。ユーザからアクセス不可な領域ってことでキーチェーンを使うってことになるんだろうけど、なんか不安があるんだよな。

  1. コメントはまだありません。

  1. 2011年 8月24日