[ChatStream] HTTP セッションミドルウェアの設定

[ChatStream] HTTP セッションミドルウェアの設定

こんにちは! (株)Qualiteg プロダクト開発部 です!

本稿では、 ChatStream に セッションミドルウェアをセットし、Webアプリケーションをステートフルにする方法についてご説明いたします!

ChatStream では Qualiteg が開発した独自のセッションミドルウェアを使用しており、通常の Starlette 用のセッションミドルウェアよりも高い柔軟性を実現しています。(Java Servlet のセッション管理アプローチに近いです)

セッションミドルウェア

開いたブラウザでWebチャットをするときにマルチラウンドの会話を成立するためには
ChatPrompt(会話履歴) が複数ターンの会話のなかで更新されていく必要があります。

デフォルトでは、 ChatStream は HTTP セッションを使用してWebアプリケーションをステートフルにし、
ChatPrompt をブラウザが開いている間保持することができます。

HTTP セッションを使用するには、以下のように FastAPI のミドルウェアを登録します。

from fastersession import FasterSessionMiddleware, MemoryStore
app.add_middleware(FasterSessionMiddleware,
                   secret_key="your-session-secret-key",
                   store=MemoryStore(),
                   http_only=True,
                   secure=True,
                   )
パラメータ名 説明
secret_key クッキーの署名用キー。
store セッションの保存用ストア。
http_only クッキーがクライアントサイドのスクリプト(JavaScriptなど)からアクセスできないようにするか。デフォルトはTrue。
secure ローカル開発環境のためにFalse。本番環境ではTrue。Httpsが必要。

内部処理

このデフォルトの実装では、セッションID を生成し署名をほどこしたのち、クッキーに保存します。

クッキーの保存期間はブラウザが開いている間のみで、かつ、フロントエンドのJavaScript からアクセスできない状態となっています

会話履歴を永続化するその他の方法

デフォルトの実装では ChatPrompt はセッション上に存在します。 またセッション情報はサーバー側でオンメモリで管理され、セッションの持続期間はブラウザが開いている間でした。

本格的なチャットサーバーを構築する場合は、ユーザーを認証し、ユーザーにひもづいた ChatPrompt をデータベース上に保存(永続化)するのが一般的です。

このような処理を行うためには、カスタムリクエストハンドラの実装 を行い、リクエストハンドラ上で、 ChatPrompt の管理と、永続化を行うことができます。

関連:CORS ミドルウェア

CORS ミドルウェア


Read more

Raspberry Pi 5を堅牢化する。SSH鍵認証・UFW・fail2banと、再起動でIPv6が復活する罠

Raspberry Pi 5を堅牢化する。SSH鍵認証・UFW・fail2banと、再起動でIPv6が復活する罠

セットアップ直後のRaspberry Pi 5は、パスワード認証が有効なまま、ファイアウォールなし、更新可能なパッケージ172件と無防備です。SSHの鍵認証化・UFW・fail2ban・自動更新・IPv6無効化を実コマンドと実測検収で解説します。sysctlのIPv6無効化が再起動で復活する現象と恒久対策も実機で確認しました。

By Qualiteg プロダクト開発部
LINE Botをローカルで開発する。WebhookのURLが毎回変わる問題を固定URLで解決する

LINE Botをローカルで開発する。WebhookのURLが毎回変わる問題を固定URLで解決する

こんにちは! LINE Botを作ろうとして最初にぶつかる壁は、コードではなくWebhookです。 LINEのMessaging APIは、ユーザーがBotに送ったメッセージを、LINEのサーバーからこちらのサーバーへHTTPSのPOSTで通知してきます。 この受け口(Webhook URL)にはインターネットから届くHTTPSのURLしか指定できず、開発中の http://localhost:5000 をそのまま書くことはできません。 トンネルツールで一時URLを発行して回避する方法が定番ですが、今度は別の問題が待っています。トンネルの方式によっては、起動のたびにランダムなURLが発行されます。その場合、開発を再開するたびにLINE Developersコンソールを開いてWebhook URLを書き換えることになります。コードを直すたび、翌日再開するたび、まずURLの貼り直しから。これが地味に堪えます。 結論から言うと、 ローカルPCの開発サーバーに「変わらない公開URL」を1本付けてしまえば、Webhook URLの設定は最初の1回だけで終わります。 この記事では、L

By Qualiteg プロダクト開発部