9: 2015-08-01 (土) 17:31:58 njf   |
現: 2015-08-15 (土) 16:34:45 njf |
| | *URL構成 [#r4de93f6] | | *URL構成 [#r4de93f6] |
| | 以上のことを踏まえて、URLの構成は以下のようになります。 | | 以上のことを踏まえて、URLの構成は以下のようになります。 |
| | + | |
| | /crossdomain.xml | | /crossdomain.xml |
| | /api/entry | | /api/entry |
| | runtime: python | | runtime: python |
| | api_version: 1 | | api_version: 1 |
| | + | |
| | handlers: | | handlers: |
| | - url: /.* | | - url: /.* |
| | | | |
| | import webapp2 | | import webapp2 |
| | + | |
| | class HelloWorld(webapp2.RequestHandler): | | class HelloWorld(webapp2.RequestHandler): |
| | def get(self): | | def get(self): |
| | self.response.headers['Content-Type'] = "text/plain; charset=utf-8" | | self.response.headers['Content-Type'] = "text/plain; charset=utf-8" |
| | self.response.write("Hello, world!") | | self.response.write("Hello, world!") |
| | + | |
| | application = webapp2.WSGIApplication( | | application = webapp2.WSGIApplication( |
| | [('/', HelloWorld), | | [('/', HelloWorld), |
| | | | |
| | from google.appengine.ext import ndb | | from google.appengine.ext import ndb |
| | + | |
| | class UserData(ndb.Model): | | class UserData(ndb.Model): |
| | userId = ndb.IntegerProperty() | | userId = ndb.IntegerProperty() |
| | *IDの加算と排他処理 [#g6b90e90] | | *IDの加算と排他処理 [#g6b90e90] |
| | | | |
| - | ユーザーIDを取得して加算する処理は以下のようになります。 | + | ユーザーIDを取得して加算する処理は以下のようになります。GAEには連番を生成する機能が見当たらないので自作します。 |
| | | | |
| | @ndb.transactional | | @ndb.transactional |
| | lastId = UserIdCounter(id=userIdIndex) | | lastId = UserIdCounter(id=userIdIndex) |
| | lastId.userId = 0 | | lastId.userId = 0 |
| | + | |
| | nowId = lastId.userId | | nowId = lastId.userId |
| | + | |
| | lastId.userId = lastId.userId + 1 | | lastId.userId = lastId.userId + 1 |
| | lastId.put() | | lastId.put() |
| | + | |
| | return nowId | | return nowId |
| | | | |
| | | | |
| | パスワードは乱数にしています。桁数があまり小さいと偶然正解する確率が高くなるので1000以上1000000未満としています。 | | パスワードは乱数にしています。桁数があまり小さいと偶然正解する確率が高くなるので1000以上1000000未満としています。 |
| - | ここでuserDataにユーザーＩＤとパスワードを連結した物をＩＤとして与えています。これはユーザーＩＤとパスワードが変更されない事を前提としています。パスワード変更をユーザーに許すならこの方法はあまり良くないでしょう。その場合はidは使わずにデータを検索する必要があります。今回は変更はしないのでこれで問題ありません。 | + | ここでuserDataにユーザーＩＤとパスワードを連結した物をＩＤとして与えています。これはユーザーＩＤとパスワードが変更されない事を前提としています。パスワード変更をユーザーに許すならこの方法はあまり良くないでしょう。その場合はidは使わないか、ユーザーIDが変更されないならそれをidとしてデータを検索する必要があります。今回は変更はしないのでこれで問題ありません。 |
| | | | |
| | 戻り値はユーザーＩＤとパスワードをjsonで送っています。 | | 戻り値はユーザーＩＤとパスワードをjsonで送っています。 |
| | userId = self.request.get('userId') | | userId = self.request.get('userId') |
| | password = self.request.get('password') | | password = self.request.get('password') |
| | + | |
| | userData = getUserData(userId, password) | | userData = getUserData(userId, password) |
| | if userData: | | if userData: |
| | | | |
| | class NjfSave(webapp2.RequestHandler): | | class NjfSave(webapp2.RequestHandler): |
| | + | |
| | def post(self): | | def post(self): |
| | self.response.headers['Content-Type'] = "text/plain; charset=utf-8" | | self.response.headers['Content-Type'] = "text/plain; charset=utf-8" |
| | } | | } |
| | です。 | | です。 |
| | + | |
| | + | オブジェクトが入れ子になっていても大丈夫です。 |
| | + | |
| | + | 注意する必要があるのは、日本語を送るとGAE側でエラーになる場合があると言うことです。pythonはあまり日本語処理などが得意ではありません。どういうやり方が一番良いかわかりませんが、手っ取り早い方法として、日本語を送る場合はurlエンコードしておくとascii文字だけになり安心です。データをサーバーから取得したときにはクライアント側でurlデコードします。 |
| | | | |
| | *さらに改良するには [#kf41b5d8] | | *さらに改良するには [#kf41b5d8] |
| | これで最低限のデータの保存と呼び出しが出来るようになりました。しかし、実際に使うにはまだ問題が生ずる場合があります。 | | これで最低限のデータの保存と呼び出しが出来るようになりました。しかし、実際に使うにはまだ問題が生ずる場合があります。 |
| | + | |
| | + | **値のチェック [#db045494] |
| | + | IDが数値かどうかやパスワードが数値かどうかなどはここでは省略していますが、本来チェックした方が良いでしょう。しなくてもGAEでエラーになり処理が止まるのであまり問題では無いですが、無意味なエラーログが多く残ると問題が発生したときに調査しづらくなります。 |
| | + | |
| | **チート対策 [#q662c5f9] | | **チート対策 [#q662c5f9] |
| - | もしランキングなどを実装するならチート対策が必須となります。このままでは送信データを容易に書き換えられるため、すぐにランキングにおかしなデータを登録されるでしょう。経験的には対策しなかった場合、ランキングに送られるデータの数パーセント程度がチートを行ったものです。数百程度のデータ数でも上位１０位ぐらいすぐにチートで埋まってしまいます。 | + | もしランキングなどを実装するならチート対策が必須となります。このままでは送信データを容易に書き換えられるため、すぐにランキングにおかしなデータを登録されるでしょう。経験的には対策しなかった場合、ランキングのためにサーバーに送られるデータの数パーセント程度がチートを行ったものです。数百程度のデータ数でも上位１０位ぐらいすぐにチートで埋まってしまいます。 |
| | クライアント側での対策は「[[ActionScriptでチート検出]]」こちらに書きました。 | | クライアント側での対策は「[[ActionScriptでチート検出]]」こちらに書きました。 |
| | | | |
| | これに加えてデータ送信時にも署名を行うなどしてデータの改ざんを防ぐ必要があります。 | | これに加えてデータ送信時にも署名を行うなどしてデータの改ざんを防ぐ必要があります。 |
| - | たとえば、jsonデータを送信するときに、そのmd5ハッシュを同時に送信し、サーバー側でチェックするなどです。 | + | たとえば、jsonデータを送信するときに、そのmd5ハッシュを同時に送信し、サーバー側でチェックするなどです。その場合、サーバーとクライアントで共通する送信しない余分の文字列や類推されにくくするために乱数などを加える必要があります。 |
| | | | |
| | **2重登録チェック [#y2834953] | | **2重登録チェック [#y2834953] |
| | 前述のように、データを差分で送るとブラウザを２つあげてそれぞれ違うデータを登録すると矛盾したデータが保存されてしまう可能性があります。これはプレイヤー側が意図的に行わなくてもいつでも起こりうる不具合です。 | | 前述のように、データを差分で送るとブラウザを２つあげてそれぞれ違うデータを登録すると矛盾したデータが保存されてしまう可能性があります。これはプレイヤー側が意図的に行わなくてもいつでも起こりうる不具合です。 |
| | | | |
| - | サーバー側でそれぞれの値の整合性チェックを行うと他の不具合も防げて確実ですが、単に2重登録を防ぐためだけなら他の方法もあります。たとえばサーバー側で保存回数を数えておいて、その値をクライアントに戻すようにし、クライアントはその値も保存時にサーバーに送信するようにしておきます。サーバー側ではクライアントから送られてきた値がサーバー側の値と等しければそのまま保存し、保存回数をインクリメントしますが、違う場合はエラーにします。 | + | サーバー側でそれぞれの値の整合性チェックを行うと他の不具合も防げて確実ですが、実装は大変です。単に2重登録を防ぐためだけなら他の方法もあります。たとえばサーバー側で保存回数を数えておいて、その値をクライアントに戻すようにし、クライアントはその値も保存時にサーバーに送信するようにしておきます。サーバー側ではクライアントから送られてきた値がサーバー側の値と等しければそのまま保存し、保存回数をインクリメントしますが、違う場合はエラーにします。 |
| | | | |
| | すると２つのクライアントから別々に保存しようとしても、後から保存する方は保存回数が１つ前になってしまうので、エラーになります。 | | すると２つのクライアントから別々に保存しようとしても、後から保存する方は保存回数が１つ前になってしまうので、エラーになります。 |
| | + | |
| | + | **パスワード暗号化 [#b678ed71] |
| | + | ここではパスワードを平文で保存していますが、個人情報などを扱う場合はパスワードを暗号化するのが一般的です。たとえばパスワード忘れ処理のためにメールアドレスを保存するなどした場合は、パスワードは暗号化した方が良いでしょう。しかし、カジュアルゲームでは個人情報取得すること自体がユーザーがいやがる可能性があるのでそこまで実装するかどうかは微妙です。 |
| | + | |
| | + | *費用 [#z4eebd4a] |
| | + | 費用についてはゲームによってセーブの回数や転送量が違うのでなんとも言えませんが、一日数百PV程度なら無料範囲でおさまるでしょう。 |
| | + | |
| | + | それ以上の場合で課金されるのは、ほぼ「Datastore Write Operations」という課金枠です。 |
| | + | これは名前の通りデータを保存した回数で、レコード毎に課金されます。これが2015/8/15現在、「$0.60/ Million Ops」となっています。十万回で0.6ドルですので、1万PVで１PV平均10回保存するゲームなら、一日60円、つまり月1800円程度となります。 |
| | + | 次に課金されやすい項目は「Datastore Read Operations」です。こちらはデータの読み込みで、一操作あたりの課金額はWrite Operationsと同じです。しかし、読み込みは最初のデータロード時のみのはずなので、Write Operationsに比べるとかなり少なく、上記のように1PVで10回保存するゲームならWrite Operationsの1/10です。 |
| | + | カジュアルゲームのデータ保存程度ではこれ以外ではほぼ課金されることは無いです。まれに転送量とインスタンスの立ち上げ時間が無料枠を少し越えるかどうか程度です。 |
| | + | |
| | + | よって、一日1万PV以上が一年以上続くような場合では月々定額のレンタルサーバーを借りた方が安くなるでしょう。一方数ヶ月で数百～数千PVにまで落ちそうなら、従量課金のGAEのほうが安くなります。 |
| | + | |
| | | | |
| | *サンプルコード [#ucddcda4] | | *サンプルコード [#ucddcda4] |
| | ここで解説したサンプルコードはこちらです。クライアント側のURLやcrossdomain.xmlの中のURLは環境に合わせて書き換えてください。 | | ここで解説したサンプルコードはこちらです。クライアント側のURLやcrossdomain.xmlの中のURLは環境に合わせて書き換えてください。 |
| | &ref(gaeWikiSample.zip); | | &ref(gaeWikiSample.zip); |
下位
ページへ戻る
