Q&A
スマホからDBと書かれていますが、こちらについては正確にはサーバ上にあるDBサーバということでしょうか。
ローカルにあるDBであれば、このような話にならないように見えますが読み手に優しい文書にして頂ければと思います。
聞かれている内容も軽い質問ではないと思いますので、前提条件や環境をしっかり書かれないとトラブルが発生する元となります。
お手数ですが質問内容を見直して頂ければ幸いです。
概念的な質問というか疑問なのですが、スマホからやりとりする際に自分がいま考えているロジックは、
前準備）スマホがuuidを作成してDBに登録
これの後に、スマホが通信をしたい場合
１）スマホが自分のuuidをDBに送信
２）DBはuuidが登録されているかどうかを調べ、登録されていれば10分以内しか通用しないキーを発行してスマホに返却
３）スマホはそのキーと一緒にゲームなどの更新データを送信
４）DBはキーがあるかどうかを調べ、キーがあれば更新データをDBに登録
といった流れを考えています。
この考え方に穴はないでしょうか？
また、一般的な他の通信はどうなっているのか、ご存知の方は教えてください。
すいません、自分でもどう書いたらいいのか見当がつかず、このような形になってしまいました。技術的なことというか、概念的なことが知りたかったのです。
サーバーはネット上にあるサーバーのことです。
回答1件
0
ベストアンサー
ここでいう「DB」とは、DBを背後に持つWebアプリケーションサーバのことだと解釈します。
さてこのuuidは、誰にも漏れる心配の無いデータだと考えて良いのでしょうか？
もしそうだとしたら、一時トークンは不要です。データアクセスのときに一緒に持っていく認証情報は、一時トークンでなくuuidを持っていけばそれで十分なので。
もし認証情報が漏れることを心配しているのだとしたら、1)2)の流れがおかしいです。誰かに盗まれたかもしれないuuidだけで本人確認としてしまってはいけないので。
通信がすべてhttpsなのなら基本盗聴はありえないものとみなして、前者のuuidだけ持ち回って認証でよろしいかと思います。
投稿2016/03/24 16:06
総合スコア5568
uuidは誰にも漏れない、という前提です。概念的なものがつかめました、ありがとうございます。これでやってみようとおもいます。
答えにくい質問でしたが、親身になっていただきましてありがとうございます！
uuidの登録作業をどうやるかですね。ユーザーごとにマイページを用意してそこで登録できるようにするのでしょうか。それともtwitterクライアントを認証するときのように、サーバ側がuuidを生成して提示する形でしょうか。
どんな形にしろ、マイページ上でユーザーが自らuuidを無効化できる仕組みは必要ですね。
？
＞どんな形にしろ、マイページ上でユーザーが自らuuidを無効化できる仕組みは必要ですね。
それはなぜでしょうか？
uuidをパスワードに例えると、万一パスワードが漏洩した場合はパスワードを変更して最悪でも今後は不正ログインできなようにします。
同じように、不正アクセスその他による万一の漏洩に備えて、uuidを無効化（リセット）できるようにすべきというこだと思います。
あなたの回答
tips
プレビュー
