この場合、データベース "users"と "posts"に2つのテーブルがあります。 最初のテーブルは基本的なユーザーデータ（ID、名字、ユーザー名、メールアドレス、パスワードなど）を拡張しています。Codeigniterのセッションデータをデータベースに格納する方法は？
投稿を作成するには、彼はタイトルフィールドとテキストフィールドを埋める必要があり、著者フィールドはセッションから直接引っ張られたユーザー名で埋められ、dbに保存されるべきです。
これを行うにはさまざまな方法がありますが、私が示唆しているのは、セッションにユーザーデータを保存しないことです。ユーザーが最初にログインしたときに、参照のために多分datetimeの長いランダムな文字列である「トークン」を作成します。ユーザー表をトークンで更新し、トークンをセッションに保存します。
ユーザーが別のページに移動すると、セッションからトークンを取得し、そのトークンを使用してデータベースからユーザーレコードを返します。必要なものすべてのユーザーの詳細が表示されます。これにより、セッション中にユーザーなどの詳細を保存する習慣がなくなります。これはセキュリティにとってははるかに優れており、システムを長期的に扱いやすくします。それ以外の場合は、ユーザーが変更を行うたびに、ユーザーデータベーステーブルとセッションを更新する必要があります。
ここであなたのより良い、おそらくもっと良い選択肢は、データベース自体にSESSIONデータを保存することです。
https://www.codeigniter.com/userguide3/libraries/sessions.htmlをご覧ください。 DB内にci_sessionsという名前のテーブルを作成する必要があります（または設定ファイルで名前を変更できます）。そうすれば、セッションからユーザー名を取得する必要があるかもしれません。
ディスクに保存されているセッションは、専用のボックスなどでコードを完全に制御している場合は問題ありません（AFAIK）。あなたが共有ボックスにいるとき、彼らは信頼できません。
ログインすると、クッキーとセッションDBに入る一連のものを作成します。例
if (password_verify($pass1, $stored))
{
$data = array(
'name' => $row->name,
'is_logged_in' => TRUE
);
$this->session->set_userdata($data);
この名前は、ユーザーのdbレコードの一部です。しかし、ログインの一部ではありません。ユーザーがログインするために検索するとき、名前はクエリに含めるものの1つです
次に、フォーム入力で、set_value = $ this-> session-> userdata（ 'name'）
最後の部分はまったく真実ではありません。ディスクベースのセッションは、共有ホスティングで正常に動作します。唯一の「キャッチ」は、application/config.php内のセッションファイルを保持するためにフォルダを割り当てる必要があり、そのフォルダは正しいアクセス権を持つpublic root htmlフォルダの上にある必要があります。その部分が新しい人を混乱させる可能性があります。それ以外の場合、共有ホスティングのファイルベースのセッションが信頼できない特定のユースケースがある場合、私はそれが何であるか聞くことに非常に興味があります。 – cartalot
私はあなたのポイントを取る。明らかにサーバーがうまくセットアップされていなかった場合、これらのセッションファイルが読み込み可能である可能性があります - アクセス許可、封じ込めなどのリスクがあります。これを反映したhttp://eddmann.com/posts/securing-sessions-in-php/彼のセクションでは「Session Content Encryption」と書かれています。 – Antony