junnetworks/42-ft_transcendence

42-ft_transcendence

Prismaを使う上での注意点

schema.prismaを編集したとき、npx prisma migrate devを実行すること。 既存のデータベースからのマイグレーション用のSQLファイルが生成されるので、一緒にプッシュよろ。

42-ft_transcendence's Issues

bug: ユーザがログアウトしても、そのユーザに紐付くWSがすぐに破棄されない

チャットのメンバー一覧とか発言のユーザ部分とかをクリックするとまずユーザ情報モーダルを出す

ユーザ情報の設定

仮でチャットチームにアサインしておく。

• #42
• #43
• #61
• その他

チャットルーム 名前の変更

PRIVATEルームについて、オーナーがユーザを選んでJOINさせるUIを作成する

ゲームがプレイできるようにする

• 1人でプレイできる
• 2人でプレイできる
• 他の人が観戦できる

tailwindでindexpage作る

ユーザ情報を表示するモーダルを作る

モーダルなのかな？

Pong ランキング

DM

仕様

• 実装上はDMタイプを持つチャットルームとする。
• DMタイプのチャットルームはPRIVATEタイプのチャットルームと類似しているが、
  • 明示的に作成できず、メンバーのうち一方がDMを送った時に自動的に作成される。
  • チャットルーム一覧に出てこない。
  • DM一覧的な画面に出てくる。
  • 管理コマンドがない。
  • 他のユーザを招待することはできない。
  • 退室ができない。
  • ルーム名の代わりに「自分でない方の参加者の名前」が表示される。

タスクリスト

-> see #81

表示名の設定

認証下でやるのでこれもWSコマンドになりそう。

Pong 観戦

ゲームのリファクタ

• 定数をstatic readonlyにする
• eventlistenerのcleanupをする

フロント側認証処理の検討と実装

コンポーネントの構造

• / AppRoutes
  • /auth DevAuth
    • credentialの検証状態によって表示するコンポーネントが切り替わる:
      • (credential検証中) DevAuthValidating
        • プログレス的なものを表示するだけ
      • (credential検証失敗) DevAuthLogin
        • ログイン用UI
      • (credential検証成功) DevAuthenticated
        • ユーザ情報表示・ログアウト用UI

APIの構造

• GET /auth/session
  • 手持ちのクレデンシャルを送り, 有効かどうか確認する
• POST /auth/login_ft
  • 42authへの入口
• GET /auth/callback_ft
  • 42authからの認可コードをトークンに交換する口

クレデンシャル

型定義。

type AppCredential = {
  token: string; // トラセンが発行したJWT
};

これをローカルストレージに置いておく想定。

クレデンシャルへのアクセスは専用のフックを経由して行う。
値をnullにセットするとログアウト。
クレデンシャルが無効化されていると判定された場合もnullにする。

チャットルームの設計変更

現行の画面

変更案

• 左ペインのルーム一覧は、基本的に「自分がJOINしているルーム」(JOINED)を表示する。
• ルームに入るためのUIとして、チャットルームを選択していない状態の右ペインに「見えているルーム」(VISIBLE)を表示する。
• 右ペインのルーム一覧の出し方は「縦のリスト」と「カードの折り返し」とがある。作ってみて比べる。
• JOINボタンはVISIBLE一覧の各ルームのカードに置く。
• LEAVEボタンは各ルームのViewに置く。
• 表示をVISIBLE一覧に切り替える手段(ボタン)を左ペインに追加

チャットルーム パスワードの変更

保存後のルームタイプがLOCKEDであるとき、パスワードを設定する必要がある。

Pong マッチメイキングができる

セキュリティチェック

• 参考: https://github.com/owasp-ja/Top10/blob/master/2021/docs/index.ja.md
• 参考: https://www.ipa.go.jp/files/000100451.pdf

Pong バーを動かしながらバーの側面にボールを当てると､ボールがバーにめり込む

Vite.+.React.+.TS.-.Google.Chrome.2022-10-01.19-44-45.mp4

NestJSのホットリロードでpsが必要なのでコンテナにインストール

各種システムメッセージ

案

• 入退室メッセージ
• ADMINになった旨のメッセージ
• 対戦募集通知
  • 募集ボタンは別途ある
• ↑の取り消し
• ↑↑の終了(=マッチング成立)
  • ここから観戦に飛べるイメージ

サブタスク

• #153
• #154
• #155
  • ゲーム側が進行してマッチテーブルのスキーマが確定するまで待ち

チャットルームを「削除」する機能を実装するかどうか検討 → 今はしない！

実装の優先度低くする。

第1回TODOコメントお掃除

コメントにTODO:って書いてあるけどもうこれ終わってるよね？というやつを消す。

「ブロック」によりブロックされる操作

ブロックした人 → された人

• した人は、された人のチャットの発言が見えない
• #312

ブロックされた人 → した人

• #312
• された人は、自分がオーナーであるPRIVATEチャットルームにした人をINVITEできない

「ブロック」によりブロックされる操作の範囲を決定する

Pongのトップページ､リザルトページ

LOCKEDルームへのJOIN処理

• LOCKEDなルームへのJOINボタンを押した時、JOINコマンドの送信前にパスワード入力モーダルを挟む。

チャットルーム タイプの変更

タイプは3種類

• PUBLIC
  • 全ユーザに見える。banされていない全ユーザがjoinできる。
• PRIVATE
  • joinしているユーザにのみ見える。joinできず、自分で作るかinviteされるしか入る方法がない。
• LOCKED
  • 全ユーザに見える。banされていない全ユーザがjoinできるが、その際正しいパスワードを送る必要がある。

Pong WebSocketを用いて簡単なPongを実装する

自分の動きがサーバーに送信され､サーバー側でゲームロジックの計算を行い､結果のスナップショットをクライアントに返して､クライアントで描画する｡

ってところまで作る｡

できれば自分のバーの動きが相手の動きに反映されるようにしておくと動かすの楽しそう｡

ユーザ情報の登録

仕様

• 42auth
• #300

パスワードの設定・変更

チャット仕様の策定

アバター画像の設定

要素

• 受け付ける入力
  • 画像ファイルのアップロード
  • URL
• 保存場所
  • PostgreSQL
  • backendコンテナ内部のストレージ
  • backendではない別のボリューム
    • どのコンテナがマウントする? frontend or backend
• 保存形式(≒表示形式)
  • blob
  • dataURL
  • 普通にファイル
    • ブラウザキャッシュに載せるという意味では良さそう
    • この場合フロントエンドが画像ファイルに到達できる必要がある

chatroomの命名変更

chatroomとsocket.ioのroomが混同しやすいのでchatroomをchannelなどに変更してもいいかも

Pong ボールの射出角度を制限する

ボールの射出角度を制限しないと真上にボールが飛んでしまう｡そうするとプレイヤーにボールが届くまで時間がかかりすぎてしまうので､射出角度を制限する必要がある｡

Pong 複数試合の同時進行ができる

e2eテスト修正

現状のバックエンドのe2eのテストはほとんど要らなくなるはずなので、
サービスのunitテストを実装してe2eは削除する方が良さそう

チャットのスクロールに応じて過去の発言を自動取得して追加する

Pong マッチリザルトのDBへの保存

チャットルームのパスワードをハッシュ化する

DockerfileのDebianのバージョンを固定したい

Debianのイメージのバージョンが上がるとイメージのビルドを全部やり直すことになるので、外でテザリングしてる時にきつい

汎用のメッセージ表示UIの仕様を検討

Pong マッチリザルトへの遷移

Pong カスタムルール

チャットに新しい発言が来たら、それが見えるようにスクロールなどする

backendの.envをローカルとコンテナで切り替える

コンテナ内はpostgresで名前解決できるけど、ローカルからnpx prisma studioでデータベース接続できなくなるので、
ローカルの.envのホストはlocalhost
コンテナの.envのホストはpostgres
になるようにしたい。

[チャット班] 第1回 取りこぼした細かいところのフォロー

タスクリスト

• #95
• #96
• #102
• #100
• #97
• #98
• #99
• #101
  • オーナーがLEAVEしてもルームは消えない、という方向で
• #106
• #107
• #108
• #109
  • @nakamo326 の見解: ログインだけできればいい
• #110
• #114
• #116

取りこぼしなんでもリスト

• チャットに新しい発言が来てもスクロールしないと見えない
• チャットで過去の発言が取得できない
• UIがアニメーションしない(するのか？)
• チャットルームのまともな新規作成UIがない
• チャットルームが削除できない
  • オーナーがleaveしたら削除？
• チャットルームのタイプ別の細かい挙動
  • PUBLIC
  • PRIVATE
  • LOCKED
• チャットルームに通常のメッセージ以外のものを表示する話
  • システムメッセージ
  • ゲームへのinvite
• チャットルームのメンバー一覧からユーザをクリックした時はまずモーダル出す方がいいと思う
• 汎用のメッセージ表示UIがほしい
  • エラーメッセージの表示に使う場合、ウェブソケットコマンドのエラーを想定する。
    • REST APIのエラーは普通は表示場所がちゃんとあるはず。
  • (汎用のモーダルダイアログもあるといいかも?)
• バックエンドでDTOによるチェックをちゃんとやる
• フロントエンドでバックエンドから来たデータの形式チェックをやる
• チャットルームのパスワードをハッシュ化する
• Routerのフォールバックを設定する
• 極端に長い文字列に対する表示
  • 「何が」「どこで」表示される時「どうするか」
  • 「何が」
    • ユーザの名前
    • チャットルームの名前
    • チャットの発言
  • 「どこで」
    • モーダル
    • 閲覧ページ
    • テーブル
  • 「どうするか」
    • 1行にしてはみ出した分は隠す
    • 1行にしてはみ出した分はスクロールで見せる
    • 折り返す
• ログインしていない状態で何ができるのかを確定させる

---

• UI
  • 必要なUI(ページレベル)のリストアップ
  • 各UIについて、何を表示するべき＆何ができるべきかを決める
  • ページ間をどのように繋ぐかを決める
    • @ToYeah に構想があるか聞く
• エラーハンドリング
  • フロントエンドにおいてどの状況でどのエラーメッセージを出すべきか確定させる
• バリデーション
  • フロントエンドの既存の適当なバリデーションを改善する
  • バックエンド側でのバリデーションをきっちりやる
• セキュリティ
  • パスワードのハッシュ化をやるべき所でやる

チャットルームの新規作成UIを作成

チャットルームの設定変更

• #65
• #66
• #67

二要素認証(2FA)

要求事項

「すべてのユーザは2FAを有効にできること」

タスク

• 実装する2FA手段の選定
  • 候補
    • ✅ TOTPによる認証; たとえばGoogle Authenticator
      • 最有力。金がかからないしスマホアプリがもうある。メンテされてるかは知らんけど。
    • 電話番号を入力してもらい、SMSで認証コードを送る
      • 金がかかる
    • メールアドレス宛にログインリンクを送る
      • 楽なメール送信サービスは金がかかるが、タダのやつが楽に使えるならアリかも。
• 実装 -> #78