認証機能の実装

[oumelab]

認証機能の実装

概要

ユーザー認証システムを実装し、ログイン、登録、ログアウト機能を提供する。認証状態に基づいたUI表示の切り替えも行う。

目的

• ユーザーがアカウントを作成できるようにする
• 安全なログイン/ログアウト機能を提供する
• 認証済みユーザーのみが特定の機能にアクセスできるようにする

優先度と依存関係

このIssueは他の機能実装の前提となる最優先事項
以下のIssueがこの認証機能の完了待ち：

• イベント情報管理CRUD機能の実装 #4
• イベント申し込み・キャンセル機能の実装 #5
• イベント参加者管理機能の実装 #6

技術的詳細

• Better Authを使用した認証システムの構築
• Tursoデータベースにユーザーテーブルとセッションテーブルを追加
• Cloudflare Pages Functionsとの統合
• セキュアなパスワード管理

タスク

• ユーザーとセッションテーブルのスキーマ設計と作成
• Better Authの初期設定と構成
• 登録フォームの実装（UI + API）
• ログインフォームの実装（UI + API）
• ログアウト機能の実装
• プロテクテッドルートの実装（認証が必要なページ）
• 認証状態に基づくUIの条件分岐
• テスト用アカウントの作成
• APIエンドポイントの認証保護の実装

受け入れ基準

• ユーザーが登録、ログイン、ログアウトできる
• 認証されていないユーザーは保護されたページにアクセスできない
• パスワードは安全にハッシュ化されて保存される
• ログイン状態はページのリロード後も維持される
• 無効な認証情報ではログインできず、適切なエラーメッセージが表示される

関連ドキュメント

• Better Auth ドキュメント
• Cloudflare Pages Functions ドキュメント

ブランチ

feature/auth-implementation

[oumelab]

メモ

Better Auth CLIで認証関連テーブルを生成し、既存テーブルは保持して後で連携させる
メールアドレス確認認証は実装しない。

// lib/auth.ts
import { betterAuth } from "better-auth";
import { Kysely } from "kysely";
import { LibsqlDialect } from "@kysely/plugin-libsql";
import { createClient } from "@libsql/client";

// 既存のTursoデータベースに接続
const db = new Kysely({
  dialect: new LibsqlDialect({
    client: createClient({
      url: process.env.TURSO_DB_URL || "file:local.db",
      authToken: process.env.TURSO_DB_AUTH_TOKEN,
    })
  })
});

export const auth = betterAuth({
  database: db, // 既存のデータベースを指定
  secret: process.env.AUTH_SECRET || "your-dev-secret-key",
  
  emailAndPassword: {
    enabled: true,
    requireEmailVerification: false, // Phase 1では無効
  },
  
  session: {
    expiresIn: 7 * 24 * 60 * 60, // 1週間
  },
});

まず基本認証のみ実装して既存テーブルを保持し、#5 の段階でメールアドレス認証を実装して既存テーブルと連携する(段階的に実装)

1. Better Auth CLI：認証テーブルのスキーマ生成に使用
2. 既存テーブル保持：eventsとattendeesはそのまま活用
3. 段階的連携：Issue #3では認証のみ、Issue #5で既存テーブルと連携
4. auth.ts設定：既存のTursoデータベースを指定する