問題タブ [cookieless]

ドメイン名がなく、IP アドレスのみのホーム仮想 Web サーバーでCookieless ドメインを確立しようとしています。

ルーターの別のポートを開き、Apache にリッスンするように指示することで、cookieless ドメインをシミュレートしようとしています。すべてが正しくロードされますが、Cookie レスではないようです (ドメイン名は同じで、ポートが異なるだけなので、これは理にかなっています)。

ドメイン名がなく、IP アドレスが 1 つしかない仮想サーバーに Cookieless ドメインを設定する方法はありますか?

グラフィックと css ファイルで Cookie が送信されないように、リダイレクトを作成したいと思います。私が望むのは、html と php を www にリダイレクトし、他のものを root にリダイレクトし、おそらく js を www に保持して、スクリプトが Cookie を処理できるようにすることだと思います。これは、Cookie を認識しない Joomla のインストール用であり、テンプレート ファイルなどを変更する必要はありません。関連する質問: HTML が www に送信された場合、Cookie を使用しないファイルをルートにリダイレクトできますか?サブドメインを作成する必要があります (これにより、テンプレートの変更禁止ポリシーが複雑になります)

ありがとう。

ASP.Net MVC3 サイトで Cookie を使用しない認証とセッションを有効にしました。私たちが遭遇した問題は、ユーザーをログアウトしても、Cookie のない文字列に保存されている既に作成された Cookie/セッションが無効にならないことです。シナリオは次のとおりです。

ユーザーはサイトにログインし、Cookie を使用しない認証を使用して登録およびログインします。ユーザーの URL に Cookie のないチケットが含まれるようになりました。ユーザーは、デスクトップ ショートカットを作成するか、コピー アンド ペーストして URL をコピーします。

ユーザーがサイトからログアウトすると、 FormAuthentication.SignOut() が呼び出されてチケットが無効になり、ログオン ページにリダイレクトされます。

ユーザーはその URL を任意のブラウザーにコピー アンド ペーストしたり、別のコンピューターに移動したりするだけで、既にログアウトしていても、サイトはその認証チケットを受け入れます。深刻なセキュリティ リスクを引き起こします。

クッキーレスかどうかにかかわらず、以前のすべてのクッキーを無効にする方法はありますか? 現在、私たちのプロセスは Cookie ベースのセッション/ログインで機能します。cookieless のソリューションが必要なだけです。

これまでに見つかった唯一の解決策は、データベース内のすべての Cookie を追跡し、データベース内の Cookie を無効にし、データベースをチェックして現在の Cookie がまだ有効であることを確認することです。これはパフォーマンスに大きな影響を与えるため、先に進む前に、これが唯一の最適なソリューションであることを確認したいと考えています。

ありがとう

私のチームは現在、シングル サインオンを必要とするプロジェクトを行っています。したがって、JOSSO は私たちの問題に対して選択されたソリューションです。JOSSO 1.8.6 を使用しています。

セキュリティ上の理由から、Cookie は一切使用しません。しかしJOSSOでは、ユーザー認証後、JOSSOがCookieを作成するようです。

私の質問は、クッキーを使用せずに完全に動作するように JOSSO を設定することは可能ですか? 無理なら理由が知りたいです。また、Cookieを作成する必要があるJOSSOセッションプロセスはどのようになっていますか?

この問題を探していますが、解決策が見つかりません。どんなフィードバックでも大歓迎です。ありがとう。

MVC4 の Web.Optimization バンドル/最小化では、あるサイト (静的 Cookie なしドメイン) にバンドルを登録し、そのバンドルを別のサイト (Web アプリケーション ドメイン) で使用できますか?

たとえば、static.myapp.com には BundleConfig.cs があり、

そのバンドルを webapp のドメインのビューで使用できますか。たとえば、www.myapp.com はこれを Site.Master に持っています。

これは MVC4 バンドルで実行できますか? Cookie を使用しない静的ドメインから静的ファイルを提供することは、パフォーマンスの向上としてよく知られています。

従来の ASP ページと Cookieless セッションを使用する MVC3.0 アプリケーションがあります。

ユーザーが ASP ページにアクセスしようとすると、クエリ文字列とともに ASP ページから MVC アプリケーションにリダイレクトする必要があります。したがって、ASP ページに次のコードがあります。

//////////////////

暗い sURL

sURL = "/MVC/xyz?" & Request.QueryString

Response.Redirect(sURL)

////////////////////////////

ASP アプリケーションと MVC アプリケーションは、同じドメインでホストされています。http:\domain\wsd.asp を使用して ASP アプリケーションにアクセスしようとすると、http:\domain\mvc\xyz\s(xccxzcxzzxczxczxczxxczxc) にリダイレクトされます。s(xccxzcxzzxczxczxczxxczxc) はセッション ID です。

しかし、http:\domain\wsd.asp?querystring=ffg のようなクエリ文字列を使用して ASP アプリケーションにアクセスしようとすると、MVC アプリケーションにリダイレクトされず、エラー Internet Explorer cannot display the webpage がスローされます。

ただし、URL http:\domain\mvc\xyz?querystring=ffg をブラウザーに直接使用すると、セッション ID を URL に追加して適切にリダイレクトされます。

Cookie を使用したセッションを使用するように MVC アプリケーションを作成すると、クエリ文字列の有無にかかわらず、asp からのリダイレクトが正常に機能します。

この問題で私を助けてください。

ありがとう！！

このコードを使用してセッション変数をすべてのサブドメインで表示するまで、Cookie のないサブドメイン (静的) を使用していました。

そうすることで、「静的」サブドメインの Cookie を使用しないという特性が失われたようです。

静的なものを除くすべてのサブドメインで 1 つのセッション変数を表示するにはどうすればよいですか? 助けてくれてありがとう

人々が画像をアップロードできるウェブサイトexample.comを持っています。しかし、これらの画像を Cookie なしのドメインexamplestatic.comに保存したいと考えています。だから、私は書いた：

フォルダの一時は次のとおりです: www.examplestatic.com/image_folder/big_images

ただし、ファイルを移動できないというエラーが表示されます。以前は、アップロードされたファイルを同じドメイン内のフォルダーに移動させていましたが、機能していました。しかし、$folder_temp のディレクトリを新しい静的ドメインに変更したため、動作しなくなりました。ユーザーがクロスドメインでファイルをアップロードできるようにするにはどうすればよいですか?

ありがとう！

背景: ETag 追跡については、こちらで詳しく説明されており、ウィキペディアでも言及されています。

「ETagによる追跡を防ぐにはどうすればよいですか?」 への回答に書いた回答です。この質問を書くように私を駆り立てました。

ETag 追跡を防止するブラウザー側のソリューションがあります。現在の HTTP プロトコルを変更せずに機能します。これは ETag 追跡の実行可能なソリューションですか?

サーバーに ETag を伝える代わりに、その ETag についてサーバーに質問し、それを既に持っているものと比較します。

擬似コード:

私のソリューションでの HTTP 会話の例:

クライアント：

サーバ：

ケース 1、クライアントには同一の ETag があります。

ケース 2、クライアントに不一致の ETag があります。

HTTP 仕様の変更が必要なエクストラ

以下は理論上の資料と考えてください。HTTP 仕様はおそらくすぐには変更されないでしょう。

1. HEAD オーバーヘッドの除去

わずかなオーバーヘッドがあることに注意してください。サーバーは HTTP ヘッダーを 2 回送信する必要があります。1 回は HEAD への応答で、もう 1 回は GET への応答です。これに対する理論上の回避策の 1 つは、HTTP プロトコルを変更し、ヘッダーのないコンテンツを要求する新しいメソッドを追加することです。その後、ETag が一致しない場合、クライアントは HEAD のみを要求し、その後はコンテンツのみを要求します。

2. キャッシュ ベースの追跡を防止する (または、少なくとも追跡をより困難にする)

Sneftel によって提案された回避策は ETag 追跡技術ではありませんが、私が提案した「HEAD、GET」シーケンスを使用している場合でも人々を追跡します。解決策は、ETag の可能な値を制限することです。ETag は、任意のシーケンスではなく、コンテンツのチェックサムでなければなりません。クライアントはこれをチェックし、チェックサム値とサーバーから送信された値が一致しない場合、キャッシュは使用されません。

補足:修正 2 により、次のEvercookie追跡技術も排除されます: pngData、etagData、cacheData。これを Chrome の「ブラウザを終了するまでローカル データのみ保持する」と組み合わせると、Flash と Silverlight の Cookie を除くすべての evercookie 追跡技術が排除されます。