問題タブ [cookieless]

私は、訪問者の20％がCookieをサポートしていないPHPサイトを持っています。

Cookieのサポートに応じてURLベースとCookieベースの両方のセッショントラッキングを提供するにはどうすればよいですか？

つまり、ユーザーがCookieを受け入れる場合は、Cookieベースのセッショントラッキングを使用します。ただし、そうでない場合は、URLベースのセッショントラッキングに切り替えて、それらのユーザーが引き続きサイトを利用できるようにします。

ユーザーの20％を失いたくないし、URLセッショントラッキングに基づいた100％のサイトは、セキュリティリスクをもたらすだけでなく、他の80％を望まない特定の制限もあるため、望んでいません。ユーザーは耐えなければなりません。

PingFederate を使用して SLO を試みています。SP アプリの 1 つは、cookieless セッションを使用するように構成されています。PingFederate のこの SP アプリは、たとえば「http://site/logout.aspx」のようにログアウト URL が設定されていますが、SLO プロセスがトリガーされると、PingFederate はブラウザーをこの URL に正常にリダイレクトしますが、まったく別のセッションにリダイレクトします。 SSO が最初に作成されたときに生成されたものよりも。SSO プロセスで作成されたセッションを再利用して SP のログアウト ページにリダイレクトするように PingFederate を構成するにはどうすればよいですか?

編集：何かを言及するのを忘れてすみません。実際には、IdP アプリケーションと SP アプリケーションの両方が ASP.NET で開発されています。Cookie を使用しないということは、SP アプリケーションの web.config ファイルに次のセッション状態構成が含まれていることを意味します。

この sessionState 構成により、URL は 'http://site(S(pvvofbemnrmaixo2emaaeo0t))/Home.aspx' のようになります。これは、'http://site/Home.aspx' が呼び出されたときと同様に、SSO では問題ありません。新しいセッションが作成されるため、URL を置き換えて "(S(blahblah))" を含めますが、SP のログアウト URL (http://site/logout.aspx) が SLO プロセスによって呼び出されると、 SP サイトが生成されます (SSO によって最初に作成されたものとは異なります)。したがって、元の SP サイト セッションは終了しません。

ASP.NET Web サイトを開発しています。セッション状態モードでどちらが優れているか知りたい: InProc または SQL Server? この問題に関するあなたの経験について聞く必要があります。

別の質問は、cookieless 属性に関するものです。true に設定した場合、サイトにセキュリティ ホールはありますか? MSDN サイトで見たすべてのサンプルで、この属性は false に設定されていました。

最後の質問は Timeout 属性についてです。この属性を InProc モードに設定すると、セッションの有効期間に影響しますか?

私の知る限り、web.configのすべての場所でCookieなしのURLを無効にしています。

私はまだ時々私たちのサイトを閲覧して、クッキーのないURLを取得します。パスは次のようになります：/（F（5wpzvCsOC [... snip ...] 9NXal01））/ About /

問題は、一部のURLに非常に長い製品名が含まれているため、「URLの長さ[...]が[...]maxUrlLengthを超えている」というHttpExceptionが発生することです。また、GoogleはこれらのURLにインデックスを付けているようですが、これを回避するために正規リンクを追加しました。

重要な場合は、IIS7.5で実行されているASP.NETMVC3サイトです。

編集： 私はこの問題をしばらく棚に置いていましたが、今日、それがキャッシングと関係がある可能性があることに気づきました。少しスピードアップするためにいくつかの子アクションをキャッシュしますが、キャッシュされるリクエストに（F（[stuff]））が含まれている場合、キャッシュには当然（？）にこれらのリンクが含まれます。ここでの問題は、ASP.NET MVCのHtml.ActionLink（）が最初にこれらのリンクを生成しないようにすることができるかどうかです。

最近Cookieなしのセッションについて調べていたところ、サーバーでセッションが作成されるたびに、そのIDがCookieに保存され、クライアントマシンで、セッションが保存されていると大学で考えられていたという記事に出くわしました。サーバー、およびsessionIDがCookieにあり、Cookieがクライアントマシンにローカルに保存されている場合、セッションがサーバーに保存されていると言うことができますか？そうです、そのセッションはサーバーに保存されていますか？はいの場合、Cookieなしのセッションの概念は何ですか、誰かが私を説明できますか

django-social-auth を使用して Facebook 認証を許可するサイトがあります

ここで、Cookie ベースではない API を使用して認証する必要もあります。私の考えは、「sessionid=」を POST フィールドとして含めることです (HTTPS を使用します)。これまでのところ、djangoを「だまして」、このセッションIDにCookieであるかのようにアクセスすることができました（基本的に、ミドルウェアでrequest.COOKIES ['sessionid'] = request.POST ['sessionid']のようなことを行います）。

私の問題は、ユーザーが認証された直後にセッションIDをユーザーに与える方法です。私が見つけたものから、facebook はユーザーに「アクセス トークン」を与え、それが /complete/facebook/ に送信されます。これは django-social-auth によって処理され、「sessionid」を含む「Set-cookie」ヘッダーを返します。鍵。しかし、その代わりに、セッション ID キーをページ コンテンツの json として返す必要があります (API クライアントは http 応答ヘッダーを読み取ることができません)。

Cookie を使用しないセッション中にユーザーが [戻る] ボタンをクリックすると何が起こっているのか、誰か説明してもらえますか?

Cookie を使用しないセッションについて私が知っていることは、セッションを識別するために、サーバーは応答ページに存在するすべてのリンクにセッション ID を追加するということです。

では、ユーザーがリンクをクリックせずに [戻る] ボタンを押した場合はどうなるでしょうか。

web.config を使用して Cookie を使用しないセッションを有効にするのは簡単です。特定のリクエスト (おそらく global.asax) に対して有効にすることもできますか?

IE8 での IFrame の問題を回避するには、Cookie を使用しないセッションが必要です。IFrame を使用しないすべての通常のリクエストでは、cookieless モードを使用したくありません。

こんなものか…

...可能？

asp.net cookielessセッションを使用するWebサイトで、セッションIDをIISログファイルに記録するための最良の方法は何ですか？

たとえば、クライアントがページをリクエストした場合

http://server.tld/(S(kdcwx1552av4iq45uabwa145））/ site.aspx

デフォルトでは、IISは記録のみを記録します

ログファイルに記録されます。つまり、セッションIDは記録されません（リファラーフィールドに表示される場合があります）。

ログにセッションIDを含めるためのビルドイン方法はありますか？そうでない場合は、カスタムISAPIフィルターが機能すると思いますか？

ありがとう

使用する場合

この変更を行うと、匿名ユーザーとしてアクセスすると、URLは以前とまったく同じように表示されます。たとえば、Default.aspxページにアクセスすると、ブラウザのアドレスバーに次のURLが表示されます。

ただし、ログインすると、フォーム認証チケットがURLに埋め込まれます。たとえば、ログインページにアクセスしてSamとしてログインすると、Default.aspxページに戻りますが、今回のURLは次のとおりです。

注： Cookieなしの認証チケットは、認証チケットがURLに直接埋め込まれているため、リプレイ攻撃を受けやすくなります。Webサイトにアクセスしてログインし、そのURLを同僚への電子メールに貼り付けるユーザーを想像してみてください。有効期限が切れる前に同僚がそのリンクをクリックすると、メールを送信したユーザーとしてログインします。

これは、Cookieなしの認証を使用する場合に考えられる欠点のひとつです。このアプローチの他の考えられる欠点を知りたいと思っています。

ありがとう