yfuruyama / beercolle Goto Github PK

• サーバサイド側とのAPI通信の仕様を考えときます
  • どういったリクエスト・レスポンスにするか

現在の認証方法

- iOS側のSDKを使用してデバイスに保存されているtwitter, facebookアカウントを取得する
- アカウントのuser idを取得し、それをiOS側でハッシュ化しサーバに送信

[現在の方法だとまずい理由]
twitter, facebookアカウントのuser idは誰でも簡単に取得できてしまう値。
ハッシュ化するといっても、そのIDを使用して認証させるのはどうなのか。
そもそも外部サービスのサーバとOAuth認証しているのに、さらに自サービスのサーバと通信するようじゃOAuth認証の意味がない。

[加瀬くんの提案]
iOS側はWebの方でOAuth認証させ、認証のやりとりは外部サービスのサーバと自サービスのサーバで完結させる。

「世界のビール」みたいな名称でマスターデータをユーザに参照させたい。
どう思います？

サービス名を一人3個投稿するスレ

以下の方法だとユーザーを特定するためにセッションベースの認証にする必要があると思うけど、認証系の議論は #16 で。

• GET /api/beeralbums
  • 全beeralbumの取得
• GET /api/beeralbums/updated?from=TIMESTUMP
  • TIMESTUMPより後に更新されたものを取得する
• POST /api/beeralbums
  • 新しいbeeralbumの作成。サーバーからidをもらう
• PUT /api/beeralbums?id=BEERALBUM_ID
  • 既存のbeeralbumの更新
• DELETE /api/beeralbums?id=BEERALBUM_ID
  • 既存のbeeralbumの削除

iPhoneからBeerAlbumの項目を追加更新削除するときは、iPhoneのCoreDataを操作するのと同時に上のAPIによるWEBサーバーとの通信を非同期タスクキューとかに入れてもらう。
オフラインのときはキューに入れるだけにして、オンラインになったときにキューを実行すればシンプルにiPhoneとWeb側のDBの同期が実現できると思う。

データの競合とかが起きた時のことは、まだ考えていない

初回登録、以後の同期処理のときにiPhoneからPOSTしてもらうJSONには、以下の例のようなユーザーを特定する認証部を付けて欲しい。
{
"auth" : {
"service" : "Facebook",
"id" : 123456789123456,
"hash" : "e05b1cef8fa248cdb225b2ad9a7a620de7cd5bfa9885ce907aaba0b82bfa1203"
}
}

• マスターデータに基づいたデータの初期化ロジック(MySQL->SQLiteフォーマットのファイル->iOS組み込み)
• iPhoneサイドのtwitter or facebook認証(サーバサイドとの連携もしたい)
• クライアントサイドのテーブル定義
• iPhoneアプリのワイヤーフレーム構想
• マスターデータの変換スクリプト(MySQL => csv => JSON)
• Canvasでビールをお絵描き

• 加瀬くんの各種テーブルの同期のコードレビュー
• 本番環境構築&サンプルやらドキュメントやら
  [ ] MySQL各種テーブル
  [ ] Apache
  [ ] PSGI/Plack
  [ ] Mojolicious
• Webクライアント

• BeerAlbumレコードの更新処理のAPIを考える
• BeerAlbumレコードの追加更新削除API(/api/beeralbum/xxx)
• モデルのテスト
• セッション管理の仕組み
• コントローラーのテスト、あるいはエンドポイントの簡易なドキュメント

API周りが決まってないことが多いから、TODOは随時変更するかも

• /signinを/api/signinに変更
• BeerAlbumレコードの追加(/api/beeralbum/insert)
• BeerAlbumレコードの更新(/api/beeralbum/update)
• モデルのテスト
• idのハッシュ変換部の関数化
• コントローラーのテスト、あるいはエンドポイントの簡易なドキュメント

スキーマの変更などの相談したい変更があったらpull requestに出していきます。
2人がOKを出せばマージするというのでいいかな？

• クラウドソーシングにエクセル埋め仕事投げる
• ビール(Beerテーブルのレコード)の同一性を担保するためのロジックを，ふりがな正規化によって作る．テストも．
• 各種テーブルの同期を実装(あるいは実装の一歩手前まで)
  • クライアントサイドのテーブル定義が必要 (by 古山)
• その他，mysqlは請け負います
• PSGI/Plackの導入検討 (余裕があれば)

• 野添にExcel依頼
• 加瀬くんの各種テーブルの同期のコードレビュー
• 本番環境構築&サンプルやらドキュメントやら
  • MySQL各種テーブル
  • Apache
  • PSGI/Plack
  • Mojolicious
• Webクライアント

• iPhoneサイドのfacebook認証
• Canvasでビールをお絵描き続き
• サーバサイド側とのAPI通信の仕様を早めに考えときます
  • どういったリクエスト・レスポンスにするか
• ビールの登録・マスターデータの閲覧の画面作ります

facebook or twitterでの認証しか出来ないとそれは辛いので、
メルアドでの認証も出来るようにしたい。
メルアドは一意だからそのままIDとして使用出来る。

正規化したふりがなの既存レコードとの「一致」を見るのではなく，「距離」を見ることによって，「もしかして」機能を提供したい．

【例】
入力: さんくとがーれんゆうげんがいしゃ
正規化後: さんくとがあれんゆうげんがいしや
もしかして: さんくとがあれん

• ハッシュ値に変換する処理の実装 (SHA-256)
• 初回のFacebook_idの登録 (/signin)
• 同期処理の認証部までの作成 (/sync)
• (fb_id, hash )が送られてきたときにユーザーを特定する処理
• 特定したユーザーのBeerAlbumテーブルへのアクセス

ビールのコレクション登録時に、見た目の色も付けられるようにする。
色が単調増加な範囲で表せるのなら、スライダーとかで。
その範囲に収まらないものがあるのなら、カラーピッカーとか使う