7

ユーザーのマシンにファイルを設定するのではなく、Webサイトの訪問者（サブスクライバー）のCookie情報をデータベースに保存してみませんか。ええ、私は次の理由でばかげているように聞こえるかもしれません：

  1. データの小さな「チャンク」について、すべてのユーザーのデータベース情報を維持することは困難です。

  2. データベースサーバーがダウンしていると、データを取得するのが難しい場合があります。

  3. 小さな情報ごとに、Webサーバーに対して継続的な要求が行われます。

私のポイントは、ユーザーのデータをクライアントのマシン上のファイルではなくデータベースに保存する場合、他の組織や他のサイト（またはハッカー）がユーザーのデータにアクセスできないようにすることで、クライアントにセキュリティを提供できるということです。クッキーからの情報。

さらに、ユーザーの活動や行動を追跡することができます。（つまり、データの改ざんなど、ユーザーが何をしているのか（クライアント側のアクティビティ）は実際にはわかりません。）

Ajaxのおかげで、Webサーバーにリクエストを継続的に送信するのが難しいと感じる場合は、そうではありません。これは私の立場をある程度サポートします：Ajaxを使用して非常に簡単にされたWebサーバーにリクエストを送信します。

では、ユーザーのマシンに小さなファイルを設定するのではなく、ユーザーの機密情報をデータベースに保存することをお勧めしますか？

具体的には、セッションについて話しているのではありません。

4

6 に答える 6

8

あなたのアプローチは間違いなく有効ですが、1つの根本的な問題があります（これがおそらくCookieが最初に作成された理由です）：識別。

ユーザー名/パスワードを要求せずに、ユーザーAとユーザーBをどのように識別できますか？クッキーは、この差別化を行う簡単な方法を提供します。ユーザーが特定されると、ポイントは完全に有効になります。

一般的に、機密情報はCookieに保存されることを意図していません。このような情報は、サーバー側に保存するのが最適です（ご指摘のとおり）。

于 2010-07-16T19:31:37.667 に答える
3

機密情報はCookieに含めるべきではありません。そこで同意します。サーバー自体のフラットファイルまたはデータベースのいずれかに、サーバー側のどこかに保存する必要があります。

クライアントマシンで必要なのは、この機密データへのあいまいで推測しにくい参照を含む1つの小さなCookieです。

おめでとう！セッションを再発明しました！

（Webサーバーは、セッションデータをサーバー上のフラットファイルではなくデータベースに保存するように設定できます。）

于 2010-07-16T19:29:32.197 に答える
2

確かに、従来の知識では、機密データにCookieを使用することは避けています。これは、Cookieがクライアントに保存され、ハッカーがCookieをいじくり回して、損害を与える可能性があるためです。ただし、Cookieを再検討する価値があると思われる説得力のある理由があります。それはスケーラビリティです。任意の数のクラウドサーバーで利用可能なセッションデータの高性能プールを用意することは困難です。

http://aws.typepad.com/aws/2012/04/scalable-session-handling-in-php-using-amazon-dynamodb.html

これが私が見つけたリンクで、安全なCookieシステムを構築する方法について詳しく説明しています。

http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf

ですから、古いものが再び新しいのかもしれません。

于 2013-02-27T22:47:36.340 に答える
1

通常、Cookieを使用するのは、Cookieに機密データを設定する必要がないためです。アプリケーションに機密データがあり、だれにもいじられたくない場合は、必ずすべてのサーバー側とDBツールを使用して解決してください。ただし、すべてのアプリケーションと実装がこれらの点でそのレベルのセキュリティを必要とするわけではありません。クッキーの設定は便利です、それだけです。

于 2010-07-16T19:29:34.347 に答える
1

これはすでに行われています。そうでない場合は、ユーザー名、住所、クレジットカード情報をデータベースではなくCookieに保存します。データベースに保持するのが理にかなっているのか、Cookieとして保存するのが理にかなっているのかを評価する必要があります。サーバーのパフォーマンス、帯域幅、スケーラビリティ-これらすべてを念頭に置く必要があります。サーバー側を保存すればするほど、クライアント側を提供する必要があることを忘れないでください。

また、セッションについても言及します。セッションはCookie（ちょっと）です。

于 2010-07-16T19:32:21.287 に答える
0

クッキーとデータベースの議論に関連するいくつかの同様のアドバイスを探しているときに、この投稿に出くわしました。

たとえば、整数リストの形式のユーザーデータ、つまりブックマークされた製品があり、ユーザーあたり最大80です。

データベースでは、これは4つのテーブル（データ型ごとに1つ）に置き換えることができるため、ユーザーあたり20行になります。

年間100万人のユニークビジターがいて、議論のために70％がメンバーではなくゲストユーザーだった場合、テーブルに14mの行が追加される可能性があります。そうでない場合は、600万の行になる可能性があります。もちろん、ゲストユーザーに対してカリングポリシーを設定することもできますが、正確に管理するのは厄介です。つまり、ユーザーが9か月後にデータが消去されたのを見つけて戻ってこないということです。

コインの反対側は、ゲストデータがCookieに保存されるため、保存期間は関係ありません。2つのストレージ方法の管理にはさらに多くの作業が必要ですが、それが私が考えることができる唯一の欠点です。

アドバイスをいただければ幸いです。

于 2012-08-13T11:09:26.620 に答える