WordPressと PHP セッション - セキュリティとパフォーマンス
私はサードパーティのAPIを扱うためのWordPressプラグインを書いています。
このAPIにはセッション識別子を渡す必要があります。これにより、API（基本的にはサードパーティのカートとして機能します）がどこにアイテムを追加するのかを認識できます。これもカートのように考えます。
このセッション識別子を私のWordPressユーザーのセッションに保存したいです。このAPIに接続してセッションIDを要求し、それをWordPress/PHPセッションに格納することで、サイト内を移動してサードパーティのカートにアイテムを追加するときに再利用できます。これは理想的ではないと認識していますが（なぜこれを直接行うのにWooCommerceを使用しないのですか？）、このサードパーティだけが提供できる追加の機能とデータが必要です。
とにかく、これをやろうとしていたときに、私たちのホストからこれを見つけました：https://wpengine.com/support/cookies-and-php-sessions/
私はそれが私がひどく混乱していると思うことを告白します。
それによると、PHPセッションと session_start() や session_id() のような関数はお勧めできません、そしてこのHostでは動作しません - ...我々のシステムは特にヘッダ定義を無視しますPHPSESSIDクッキー
しかし、文書が指摘しているように - IF PHPセッションは一種の料理人なのでしょうか、問題は何ですか？
私の考えでは、これらの文書はその質問に答えていません。
それは言います：
PHP Sessionsを使用するときの最大の衝突は、一意のセッション識別子と関係があります。すべてのユーザーの識別文字列は一意であるため、これはすべての新しいユーザーがあなたのサイトにアクセスするために必要な「キャッシュ」です。この種のシステムは、多くの同時サイトユーザーに対応できません。それを念頭に置いて、私たちのシステムは特にPHPSESSIDクッキーを定義するヘッダを無視します。
ここでの私の質問は、彼らが主張しているセッションには当てはまりません。それは単に別のcookieを介して行われ、それがデータベース接続につながるのですか？
彼らはここで言う：
現実には、ユーザーセッションデータを保存するためのより良い方法があります。正しい方法は、データベースを使用してセッションデータを保存することです。 WooCommerceおよび他のeコマースソリューションは、従来のPHPセッションではこの方法を使用するようにすでに変換されており、も独自のcookie命名規則を使用しています。
これらの文書は続きます：
パフォーマンスとスケーリングの影響を超えて、PHPセッションには他の問題があります。デフォルトでは、PHPセッションはデータをファイルシステムに独自の一意のファイルとして保存します。ファイルへのデータの書き込みはI/Oプロセスであり、この種のプロセスはバックアップすることが知られており、サイトで同時ユーザーが増えすぎるとサーバーの負荷が高くなります。言うまでもなく、この種のセッションストレージは、サイトが複数のWebサーバーにわたるクラスタ化されたソリューション上にある場合は、単に機能しません。
セッションをデータベースに格納するよりも、これが悪い/優れているのはなぜですか？それもI/Oじゃないの？
理解しようとしています - デフォルトのPHPセッションが悪いと見なされ、WooCommerceセッションが良いと見なされるのはなぜですか。私はセッションで WooCommerceのソースコードを調べました しかし、私はこの分野では何が彼らのしていることがホストのドキュメントで述べられている脆弱性を回避するのかを解明するのに十分経験していません。
具体的には：
PHP Sessionsを中心とした複数のセキュリティ脆弱性があります。脆弱性には、公開されているセッションデータ、セッション固定、およびセッションハイジャックが含まれます。
PHPセッションでは発生しない場合、WooCommerceはこれをどのように軽減しますか？私のユースケースには何が望ましいですか？
明らかに、私は安全でないセッションを望んでいませんが、Wooがしたようにセッションマネージャ/クッキー/データベース接続を開発することは多少時間がかかるでしょう。それで私はPHPセッションを避けるために時間を費やす前にこれが複製するのに必要である理由を理解しています。
これはwordpressとはほとんど関係ありませんが、この答えがセッションの使用を排除するのに役立つのであれば、それはそれの価値があるかもしれません....
セッションはサーバーのハードディスクに保存されます。セッションディレクトリは、あなたのサイトだけでなく、サーバー上で実行されているすべてのプロセスによって読み書き可能である可能性が最も高いため、これは共有ホスティングシナリオでは問題があります。 OSレベルのユーザーベースの保護（ディレクトリのアクセス許可など）を持たない共有ホスティングサーバー上のすべての共有リソースは、少なくとも疑わしいので、安全な場所やプライベートな場所には使用しないでください。
セッションをサーバーのハードディスクに保存します 。マルチサーバー環境で実行しているとどうなりますか？セッション情報をどのようにして見つけることができますか。それを機能させる唯一の方法は、最適ではない特定のサーバーにユーザーを結び付けることです。
そして セッションはサーバーのハードディスクに保存されます 。あなたがあなたのHTML生成の不可欠な部分としてセッションを使うならば、それはあなたがあなたのHTMLをキャッシュすることができないことを意味します。
WPEngineは、デフォルトでキャッシュを行うマルチサーバー環境での共有ホスティングです。
WCに関しては、あなたが引用していることで述べたように、彼らはphpセッションを使用せず、そしてDBにセッション情報を格納することによってそれら自身のメカニズムを発明します。これはまたあなたが細心の注意を払ってそれをしなければ大量のトラフィックがサイトをダウンさせるかもしれないことを意味するので問題のある解決策です（その場合セッションはユーザーが製品を購入するプロセスを開始したときにだけ始まります）なぜそれらがそれをしてクッキーに頼らないのか、あなたは彼らに尋ねなければならないでしょう、私は不完全なトランザクションを追跡することがそれの一部であると思います。情報漏洩あなたはそれをサーバーに保存する必要があります。
あなたのケースでは何が進められていますか？これ以上の詳細がないと言うのは難しいでしょうが、おそらくセッションのように感じるものの使用を排除するために働くべきです。 HTTPはセッションを持つようには設計されていません、そしてそれは人生のこの事実と戦わないことが最善です。