AJAXリクエストはPHPセッション情報を保持しますか?


154

私のユーザーが自分のサイトにログオンし、IDがに保存されていて$_SESSION、ブラウザーから[保存]ボタンをクリックすると、サーバーにAJAXリクエストが送信されます。彼$_SESSIONとCookieはこのリクエストで保持され$_SESSIONますか?また、IDが存在することを安全に信頼できますか?

回答:


191

答えはイエスです:

セッションはサーバー側で維持されます。サーバーに関する限り、AJAX要求と通常のページ要求の間に違いはありません。どちらもHTTPリクエストであり、どちらも同じ方法でヘッダーにCookie情報を含みます。

クライアント側からは、通常のリクエストでもAJAXリクエストでも、常に同じCookieがサーバーに送信されます。Javascriptコードは特別なことをする必要はなく、これが発生していることを認識する必要さえありません。通常のリクエストの場合と同じように機能します。


10
フォローアップ:サーバーはHttpOnlyCookieを設定するときにフラグを設定できます。これは、JavaScriptがCookieを認識できないことを意味します。ただし、Cookie 引き続きAJAXと通常のページ要求の両方に対して送信され、まったく同じように機能し続けます。あなたのJavascriptはそれをに表示しませんdocument.cookie
thomasrutter 2013

PHPエラー報告がオンになっている場合、AJAX応答でセッションエラーが返されることがあります。Warning: session_write_close(): Failed to write session data (user)最近プロジェクトで断続的にエラーが発生していますが、残りのページの読み込み中にAJAXリクエストが発生した場合のみです。セッションデータにMySQL DBを使用していますが、メインページのリクエストがそのテーブルをロックしているため、AJAXリクエストがテーブルにアクセスできない可能性があります。
Buttle Butkus

@ButtleButkusはサーバーサイドコードの問題のように聞こえます。それを独自の質問として送信すれば、人々は喜んで助けてくれるでしょう。セッションでMySQLを使用しているという理由だけでエラーが発生することはありません。エラーで失敗するような方法でロックする必要がないからです。これは、MySQL接続が飽和している問題、または他の無関係な問題である可能性があります。
thomasrutter

MySQLの接続が飽和しているはずなので、これは悪意のあるマシンで起こっています。すぐにわからない場合は、間違いなく質問を投稿します。
Buttle Butkus

23

PHPファイルにAJAXリクエストsession_start()にセッションがある場合、セッション情報は保持されます。(要求を排除すると、同じドメイン内にあります)


2
確かに、それは私が忘れていたものです:-)
sivann

23

あなたが本当に得ているのは、AJAXリクエストでCookieが送信されているかということです。AJAX要求が同じドメイン(またはCookieのドメイン制約内)に対するものであるとすると、答えは「はい」です。そのため、同じサーバーへのAJAXリクエストは同じセッション情報を保持します(呼び出されたスクリプトがセッション情報へのアクセスを必要とする他のPHPスクリプトと同様にsession_start()を発行すると想定)。


1
私は間違っているかもしれませんが、ajaxリクエストを他のドメイン(サブドメインを除く)に投稿することさえ不可能だと思いましたか?
Emil H

動的スクリプトのトリックでごまかすことができるかもしれません。でも疲れません。
cletus 2009年

1
はい、Ajaxリクエストを他のドメインに対して行うことはできません。ただし、ページに<script>タグを動的に挿入し、そのsrcを、javascriptをエコーするドメイン外のURLに設定できます。
2009年

1
他のドメインに対してajaxリクエストを行うことはできません。しかし、あなたはあなたのphpコードでプロキシを作ることができました。プロキシへのajaxリクエスト、他のドメインへのプロキシリクエスト。
ピーターロング

2
注意事項... ajaxリクエストはクロスドメインで行うことができますが、応答タイプがjsonpの場合のみです。私はいつもこれをします。
エピファニー

8

ええと、いつもではありません。クッキーを使用すると、あなたは良いです。しかし、「存在するidに安全に依存できますか」ということで、重要なポイント(このページの訪問者数は非常に多いように見えるので、主に参照用)で議論を拡張するように促されました。

PHPは、Cookieの代わりにURL書き換えによってセッションを維持するように構成できます。それが良いか悪いか(<-たとえば、そこにある一番上のコメントを参照)は別の質問です、今一つのサイドノートで現在の質問に固執しましょう:URLベースのセッションで最も顕著な問題-露骨なネイキッドセッションIDの可視性-内部Ajax呼び出しの問題ではありませんが、Ajaxで有効になっている場合は、サイトの他の部分でも有効になっているので...)

URL書き換え(Cookieなし)セッションの場合、Ajax呼び出しは、要求URLが適切に作成されていることを自分で処理する必要があります。(または、独自のカスタムソリューションをロールバックすることもできます。要求の少ないケースでは、クライアント側でセッションを維持することもできます。)ポイントは、Cookieを使用しない場合でも、セッションの継続性に必要な明示的な注意です。

  1. Ajax呼び出しがHTMLからそのままURLを抽出するだけの場合(PHPから受信した場合)、それらは既にクックされている(うーん、クックされている)ため、問題ありません。

  2. リクエストURIを自分でアセンブルする必要がある場合は、セッションIDを手動でURLに追加する必要があります。(ここを確認するか、PHPによって生成されたページソース(URL書き換えがオンの場合)を確認してください。)


OWASP.orgから:

事実上、Webアプリケーションは、メカニズム、CookieまたはURLパラメータの両方を使用できます。また、特定の条件が満たされた場合(たとえば、CookieがサポートされていないWebクライアントの存在、またはCookieがサポートされていない場合)、一方から他方に切り替えることもできます(自動URL書き換え)ユーザーのプライバシー問題のために受け入れられた)。

ルビー・フォーラムのポスト:

cookieでphpを使用する場合、Ajax XMLHttpRequestsの場合でも、セッションIDはリクエストヘッダーで自動的に送信されます。 URLベースのphpセッションを使用または許可する場合は、すべてのAjaxリクエストURLにセッションIDを追加する必要があります。


セッション Cookieを無効にした人数についての信頼できる統計はありますか?(私は何も見つけられませんでした。Javascriptでのみ:米国/ヨーロッパでは約2%、世界平均で約1.2%と思われます)
Sz。

URLのセッションIDは古く、安全ではありません。今日のWebでは、Cookieを無効にしてサーフィンを行っても、アカウントを保持しているWebサイトにログインできるとは誰も考えてはなりません。訪問者の1人がCookieを無効にしている場合は、おそらく次のいずれかを想定しても安全です。またはb)誤ってそれを行ったため、自分のサイトだけでなく、どのサイトにログインできない。
thomasrutter 2013

3

AJAXリクエストがセッションを保持することは非常に重要です。最も簡単な例は、管理パネルに対してAJAXリクエストを実行しようとした場合です。もちろん、管理者のログイン後に取得したセッションを持たない他の人がアクセスできないように、リクエストを行うページを保護します。理にかなっていますか?


0

ただし、フレームワークを使用している場合は特に、アプリケーションがリクエスト間でセッションIDを再生成しているかどうかを確認する必要があります。セッションIDに明示的に依存するものはすべて問題が発生しますが、セッションは影響を受けません。

アプリケーションがこのようにセッションIDを再生成している場合、ajaxリクエストが実際にリクエストしているページのセッションIDを無効にするか、置き換える状況になる可能性があります。


0

それがフレームワークが行うことです。たとえば、フロントコントローラーまたはブーストラップスクリプトでセッションを初期化する場合、ページコントローラーまたはajaxコントローラーのどちらの初期化についても気にする必要はありません。PHPフレームワークは万能薬ではありませんが、このような非常に多くの便利な機能を備えています。


0

ajaxリクエストを受け入れるすべてのサーバーサイドページにsession()認証を配置します。

if(require_once("auth.php")) {

//run json code

}

// do nothing otherwise

これが、私がこれまでに行った唯一の方法です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.