セキュリティ

[akinoriosamura]

・APIのテスト（Rspec） ・普通のユーザーが管理者並みの権限持たないように └devise_token_auth + cancancanの制御 ・決済部分のセキュリティ

[akinoriosamura]

本番環境のSSL https://railstutorial.jp/chapters/sign_up?version=5.1#sec-ssl_in_production 独自ドメインを使う場合はSSL証明書を購入する必要があります)。結果として、7.5.2でアプリケーションのデプロイが終わると、自動的にSSLが有効化されているはずです。もしwww.example.comなどの独自ドメインでSSLを使いたい場合は、HerokuのSSLに関するドキュメント (英語) を参照してください。 https://qiita.com/serinuntius/items/f7f08b2221f5ad068f5d

[akinoriosamura]

エラー処理

・閲覧料支払後のみ閲覧可能 ・自分の投稿への回答のみ閲覧可能 ・アクセス権限ないとき └登録画面へ ・登録、編集失敗時 └元のページへ ・別ユーザーを編集しようとしたとき* └質問一覧へ ・最低価格未満の決済時のエラー処理 ・登録時、ログイン時：role追加

[akinoriosamura]

考案事項

・登録時に選択式（回答者、質問者）。回答者は確認書類込み登録、質問者はカード番号のみ。その後、各自の設定画面に飛びドキュメントや最低金額を設定してもらう。後に、設定で回答者への変更可能に -> フロント：認証処理 ->（auth後のリダイレクト先を設定画面へ）-> 設定画面（回答者or質問者登録ボタン）->（登録ボタン押したら各stripeの登録画面へ）->登録画面（回答者登録 OR 質問者登録）->完了したら質問一覧へ └member、quiestioner、proの3パターンいる └questionerは質問可能 └proは回答可能

・認証機能、ログアウトまでの一連の流れ、ログイン、ログアウト処理 └ログアウト処理：フロント側でアクセストークン削除し、質問一覧ページへ └石井さん待ち

・③管理機能が動作してるか、認証機能が動作してるか、認証維持できているか（各ページにアクセスして確認&テスト）今はuser_controllerのみload_authorize_をつかってる。 └アクセストークン持たせて各ページアクセス

・④SSL認証 in 本番、https://github.com/akinoriosamura/QaAppServer/issues/11#issuecomment-345484430 └https://qiita.com/GenTamura84/items/7a12ca611705017bcb0e └本番環境へ導入時に動作させる

・⑤非ログイン時のアクセスにおけるリダイレクト（アクセスdenied後のリダイレクト、ログイン要求）、ログイン時、別ユーザー編集しようとした時のリダイレクト、https://railstutorial.jp/chapters/updating_and_deleting_users?version=5.1#sec-friendly_forwarding └フロント側でリダイレクト制御

・⑧投稿、作成、編集などの失敗処理 └jsonでエラーを受取、エラー時でif文別処理をフロントで行う

・⑩閲覧数カウント └QAのPV数を計測。commentをshowする度にcountを+1、commentDBにPVカラム作成 └フロントで確認

・⑪決済時、最低価格未満のときのエラー処理 └決算のリクエストに対してif文

*管理画面http://allishackedoff.hatenablog.com/entry/2017/05/08/134308 └APIでもgem入れればいけると思いますよ。普通にActiveAdminとか入るんじゃないですかね？ https://qiita.com/fakestarbaby/items/77d7b974a8be3bfe7444 https://teratail.com/questions/81019

・stripe必要項目入力ページへの遷移 └stripeの必要遷移URLを登録後->その後設定画面へ飛ばす

[akinoriosamura]

認証ユーザーのみでの決済の確認 └別ユーザに入られた状態で決済を防ぐ └authoenticate_user

[akinoriosamura]

必須実装要件

最低限対策

・HTTPS └パフォーマンス悪くなるが、後ほど対策は調べて実装 ・cancancanのload_and_authorize_resource ・認証のbefore_action :authenticate_user! ・jsの送るデータ制限 or アクセス制限 └情報詳細をリクエストすれば他の人のメアドゲットできる状態？

XSS対策*

・Content-typeをapplication/jsonと指定し、XSSを防ぐ ・x-content-Type-options: nosniff └XSSをIEでも防ぐ

XSRF対策*

・XSRFトークン：サイト、特別なリクエストヘッダを付ける*

JSONハイジャック

・X−requested−with追加など・・・corsとの併用はややこしいので一旦stay ・メディアタイプのjson指定(content-type) ・x-content-Type-options: nosniff ・jsonをオブジェクトで返す*

その他

・webAPIの本の6.5章の一覧 ・admin追加

[akinoriosamura]

決済登録

uidとかってユーザの識別に使われるわけなので、例えば単純な連番とかになってて自分が3だったら、stripeの認証画面のブラウザバーで3を4に書き換えたらどうなるかとか、気になります。 ちゃんと考えないとどんなリスクがあるかは洗い出せないですが、ちゃんと考えないでリスク回避するなら、 ・一つはユーザ識別子をUUIDとかにして、連番とかにせず、他人のユーザ識別子が分からないようにする ・ワンタイムトークン的なものを使って、rails側でワンタイムトークンとユーザ識別子のヒモ付を保持しておきstateパラメータとしてはワンタイムトークンを渡す