9: 2015-08-01 (土) 17:31:58 njf   |
10: 2015-08-10 (月) 10:06:08 njf |
| | *IDの加算と排他処理 [#g6b90e90] | | *IDの加算と排他処理 [#g6b90e90] |
| | | | |
| - | ユーザーIDを取得して加算する処理は以下のようになります。 | + | ユーザーIDを取得して加算する処理は以下のようになります。GAEには連番を生成する機能が見当たらないので自作します。 |
| | | | |
| | @ndb.transactional | | @ndb.transactional |
| | | | |
| | パスワードは乱数にしています。桁数があまり小さいと偶然正解する確率が高くなるので1000以上1000000未満としています。 | | パスワードは乱数にしています。桁数があまり小さいと偶然正解する確率が高くなるので1000以上1000000未満としています。 |
| - | ここでuserDataにユーザーＩＤとパスワードを連結した物をＩＤとして与えています。これはユーザーＩＤとパスワードが変更されない事を前提としています。パスワード変更をユーザーに許すならこの方法はあまり良くないでしょう。その場合はidは使わずにデータを検索する必要があります。今回は変更はしないのでこれで問題ありません。 | + | ここでuserDataにユーザーＩＤとパスワードを連結した物をＩＤとして与えています。これはユーザーＩＤとパスワードが変更されない事を前提としています。パスワード変更をユーザーに許すならこの方法はあまり良くないでしょう。その場合はidは使わないか、ユーザーIDが変更されないならそれをidとしてデータを検索する必要があります。今回は変更はしないのでこれで問題ありません。 |
| | | | |
| | 戻り値はユーザーＩＤとパスワードをjsonで送っています。 | | 戻り値はユーザーＩＤとパスワードをjsonで送っています。 |
| | } | | } |
| | です。 | | です。 |
| | + | |
| | + | オブジェクトが入れ子になっていても大丈夫です。 |
| | + | |
| | + | 注意する必要があるのは、日本語を送ると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] |
| | + | ここではパスワードを平文で保存していますが、個人情報などを扱う場合はパスワードを暗号化するのが一般的です。たとえばパスワード忘れ処理のためにメールアドレスを保存するなどした場合は、パスワードは暗号化した方が良いでしょう。しかし、カジュアルゲームでは個人情報取得すること自体がユーザーがいやがる可能性があるのでそこまで実装するかどうかは微妙です。 |
| | | | |
| | *サンプルコード [#ucddcda4] | | *サンプルコード [#ucddcda4] |
| | ここで解説したサンプルコードはこちらです。クライアント側のURLやcrossdomain.xmlの中のURLは環境に合わせて書き換えてください。 | | ここで解説したサンプルコードはこちらです。クライアント側のURLやcrossdomain.xmlの中のURLは環境に合わせて書き換えてください。 |
| | &ref(gaeWikiSample.zip); | | &ref(gaeWikiSample.zip); |
下位
ページへ戻る
