ユーザーに内部識別子を表示しないように、受信したデータとサーバーデータからハッシュを構築した後、データベースに後者の署名を保持しました。
しかし、時間が経つにつれて、そのようなアルゴリズムは私に適さなくなり、クッキー内のコンテナの数を最小限に抑えたいと思いました。
すでに持っているかどうかを探してはいけません（探していました-ハブで見つけられませんでした）。また、誰かがそれを気に入らない場合でも、誇りのためではなく、
（識別子のエンコード/デコードのアルゴリズムは1行に収まりますが、読みやすくするために、段階的に間隔を空けています）
<？php $ user_id = 1; $ crc32 = crc32（$ _ SERVER ['REMOTE_ADDR']。 '-'。$ _SERVER ['HTTP_USER_AGENT']）; //識別子をエンコードします $ cookie = $ user_id + abs（$ crc32）; $ cookie = decbin（$ cookie）; $ cookie = str_pad（$ cookie、32、 '0'、TR_PAD_LEFT）; $ cookie = strrev（$ cookie）; //識別子をデコードします $ user_id = strrev（$ cookie）; $ user_id = bindec（$サーバー）; $ user_id-= abs（$ crc32）; ？>
（関数の説明については、 ドキュメントを参照してください。）
何が得られますか？ そして、32文字のバイナリ文字列を取得します。この文字列はオンザフライでエンコードおよびデコードされます（私のマシンでは上記のコードは0.00007秒かかりました）。
アルゴリズムは、必要に応じて単純化または複雑化できますが、いずれにしても、デコードしたい人に知られていなければ、単に機能しません。
実際、指定された例のアルゴリズムは非常に単純であり、攻撃者がそれを理解する可能性がありますが、少し変更すると、$ cookieコンテナーで予測できないシーケンスを取得できます。
たとえば、行全体を反転する代わりに（
$cookie = strrev($cookie);
）、次をビルドします。
<？php $ chr_num =（int）$ _ SERVER ['REMOTE_ADDR']％30; $ str_rev = strrev（substr（$ cookie、0、$ chr_num））; $ cookie = $ str_rev。 substr（$ cookie、$ chr_num）; ？>
アルゴリズムが動的になります！ それはすべてあなたの想像力に依存します（たとえば、ユーザーのブラウザによって異なります-行の先頭または末尾、さらには中央を回すこともできます）。
プロから：
-文字列を使用してサーバーに戻ると、SQLクエリで安全に使用できる変換が実行されます。
-あなた自身がアルゴリズムを明らかにしない場合-解明することはほとんど不可能です。
-識別子とその署名の両方が1行に隠されています。
-識別子がどこにも繰り返されていないことを確認できます（元の例）。
-少なくとも0から100,000 000行まで（最初の例によると、再び）32文字（これ以上チェックしませんでした:)
-すべてが
$user_id
に対してチェックされ、残りはこのコンピューターにのみ適用されるため、特定のコンピューターへのバインドはありません。
マイナスのうち：
-上記の動的アルゴリズムは受け入れられません-数値の一致は可能です。これらの行は情報専用です（この問題を解決する方法を見つけるのは簡単です）。
-0から1111111111111111111111111111111111111までの単純な総当たりによって理論的に任意のアカウントに入ることができますが、これは解決されます（シークする人は常に見つけます）。
-他に何か？ 何らかの方向で意見や議論を聞いてうれしいです。
トピックについて：
-CRC32 ;
- セッション-常に必要ですか？ ;
-PHPドキュメント 。