Kegagalan validasi sesi di Magento 1 EE v 1.14.3.x (dan CE 1.9.3.x)

Saya menjaga toko Magento dengan 400-500 pengunjung dan 40-50 pesanan per hari. Baru-baru ini sistem ditingkatkan dari Magento EE 1.14.2.4 ke Magento EE 1.14.3.2 dan saya melihat beberapa pengecualian aneh dalam log:

exception 'Mage_Core_Model_Session_Exception' in
/var/www/.../app/code/core/Mage/Core/Model/Session/Abstract/Varien.php:418

Saya mengejar pengecualian itu dan saya tahu bahwa itu sedang dipecat karena kode validasi sesi berikut gagal memvalidasi sesi:

class Mage_Core_Model_Session_Abstract_Varien extends Varien_Object
{
// ...
    protected function _validate()
    {
//    ...
        if ($this->useValidateSessionExpire()
            && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
            && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {

Blok if ini ditambahkan ke file dengan rilis terbaru dari Magento. Dan ini sepertinya perubahan pengereman, lihat detail lebih lanjut di bawah ini.

Pengecualian terjadi cukup sering, seperti belasan kali per hari. tapi saya tidak dapat membuat ulang kondisi yang mengarah ke pengecualian, kecuali saya benar-benar mengemukakan kondisi di atas. Pengecualian paling sering terjadi pada halaman detail produk dan pada langkah terakhir dari satu checkout halaman. Toko adalah toko b2b, pengguna harus masuk untuk melihat halaman produk atau dapat checkout, berarti pengguna diarahkan ke halaman login saat sesi tidak valid / kedaluwarsa. Saat ini lebih penting bagi saya untuk memperbaiki masalah ini saat checkout.

Apa yang terjadi dari perspektif pengguna: Pengguna mengisi troli, melanjutkan ke checkout, dan mencapai langkah terakhir, kemudian ia menekan tombol "kirim pesanan" dan tidak ada yang terjadi. Di belakang layar JS Magento melakukan permintaan AJAX dan JS mengharapkan untuk menerima JSON kembali, tetapi jika kesalahan ini terjadi, halaman login HTML dikembalikan, yang tidak dapat diuraikan oleh JavaScript dan hanya tidak melakukan apa-apa. Itu sangat membingungkan bagi pengguna.

Ya, itu bukan skenario pengguna yang lengkap, kami menghubungi pengguna dan mereka memberi tahu kami bahwa mereka menunggu beberapa hari antara mengisi keranjang dan mengirimkan pesanan, apa artinya itu sebenarnya sulit diketahui, karena orang tidak ingat itu.

Seumur hidup sesi PHP - 350000 (~ 4 hari dalam hitungan detik) Seumur hidup cookie - 345600 (4 hari)

Inilah pertanyaan aktual: bagaimana saya bisa mengetahui perilaku pengguna seperti apa yang menyebabkan pengecualian?

PEMBARUAN Sejauh ini saya tahu bahwa pengecualian terjadi dalam mengikuti kelas sesuai dengan permintaan yang dibuat, bagi saya itu tidak berarti apa-apa.

/catalogsearch/result/?q=…    Mage_Core_Model_Session
/checkout/cart/               Mage_Core_Model_Session
/checkout/onepage/saveOrder/… Mage_Rss_Model_Session
/customer/account/loginPost/  Mage_Core_Model_Session
/customer/account/loginPost/  Mage_Reports_Model_Session
/customer/account/logout/     Mage_Reports_Model_Session
/catalog/product/view/…       Mage_Reports_Model_Session
/catalog/product/view/…       Mage_Tag_Model_Session

PEMBARUAN 2 : sesi disimpan dalam file dan dibersihkan oleh pemungut sampah sesi PHP, apakah ini pilihan yang baik atau tidak berada di luar cakupan pertanyaan ini.

Setelah beberapa debugging lanjutan, sesi pelacakan dan memikirkan semua keajaiban itu saya dapat mereproduksi masalah dan memahami alasannya. Saya menyiapkan sedikit ilustrasi waktu, Anda dapat melihatnya di bawah.

• bendera merah adalah momen login pengguna dan pembuatan sesi
• bendera biru adalah saat ketika pengguna membuka halaman katalog, mari kita asumsikan itu adalah halaman kategori yang dibuka.
• bendera hijau adalah saat di mana pengguna mengirimkan pesanan ( /sales/order/save/...permintaan)

Berikut cara mereproduksi:

1. Sebelum Anda mulai: Tetapkan batas waktu sesi PHP dan Batas waktu cookie Magento Anda menjadi 1440 yang merupakan nilai PHP default.
2. Bunuh semua cookie Anda atau buka tab penyamaran.
3. Pergi ke toko Magento Anda dan masuk (lihat Bendera 1)
4. Buka katalog dan tambahkan beberapa produk ke troli (Bendera 2)
5. Pergi melalui kasir dan kirimkan pesanan. Catat waktu ketika Anda melakukannya. (Bendera 3)
6. Buka katalog dan tambahkan beberapa produk ke troli (Bendera 4)
7. Terus menyegarkan halaman kereta Anda atau melalui halaman katalog begitu lama sehingga batas waktu yang telah Anda konfigurasikan untuk cookie magento kedaluwarsa (Bendera 5-6). Perhatikan bahwa waktu antara Bendera 7 dan Bendera 3 harus lebih besar dari batas waktu cookie.
8. Pergi melalui kasir dan kirimkan pesanan (Bendera 7). Pengiriman pesanan akan gagal karena pengecualian yang dijelaskan dalam pertanyaan saya di atas.

Alasan:

Ada sesi tertentu yang hanya dipakai pada permintaan yang diberikan, misalnya Mage_Rss_Model_Sessionhanya dipakai selama checkout aktual dan tidak saat browsing melalui katalog. Pada saat yang sama, timestamp kadaluwarsa sesi hanya diatur ketika sesi dipakai. Itu berarti bahwa jika ada cukup waktu antara dua checkout dan sesi tidak terbunuh sementara itu (karena pengguna logout atau cookie kedaluwarsa) kode Magento baru akan menganggap sesi itu tidak lulus validasi dan akan mengeluarkan pengecualian, yang entah bagaimana terdengar aneh untuk saya.

Bagaimana cara memperbaiki:

Yah, saya punya beberapa pilihan:

1. Tunggu sampai Magento bereaksi dan pertimbangkan kembali kode itu.
2. Hapus kode ini.
3. Coba atur waktu habis cookie Magento ke 0 jika itu opsi untuk Anda.

Bagaimana saya mengetahuinya:

1. Saya mulai dengan menambahkan berikut ini ke kode asli Mage_Core_Model_Session_Abstract_Varien

   Mage::log(
       sprintf(
           'useValidateSessionExpire fail "%s" "%d" "%d" "%s" "%s" "%s"',
           print_r($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP], 1),
           time(),
           $this->_time,
           get_class($this),
           session_name(),
           session_id()
       ),
       Zend_Log::DEBUG,
       'session-validation.log',
       true
   );

   itu memberi saya wawasan yang baik tentang kelas yang terkena dampak dan korelasinya dan berapa banyak sesi yang berakhir. Tapi itu tidak menjelaskan mengapa itu terjadi dan tindakan pengguna mana yang mengarah ke masalah.

2. Kemudian saya mulai berpikir tentang bagaimana saya bisa melacak semua perubahan pada data sesi dan menemukan pertanyaan ini /superuser/368231/automatic-versioning-upon-file-change-modify-create-delete saya memutuskan untuk memberikan mencoba gitdan incronkombinasi, tetapi setelah saya menerapkannya dan diuji di sandbox, saya menyadari bahwa saya akan kehabisan ruang disk yang sangat cepat dalam produksi.

3. Saya memutuskan untuk membuat skrip PHP kecil yang akan men-decode data sesi dan menulis log untuk setiap sesi. Script ini dipanggil olehincron

   <?php
   //log-session-data-change.php
   
   $sessionLogStoragePath = '/var/www/html/logged-session-storage/';
   
   $sessionFilePath = $argv[1];
   $sessionOperationType = $argv[2];
   $sessionFileName = basename($sessionFilePath);
   
   session_start();
   session_decode(file_get_contents($sessionFilePath));
   
   $logString = sprintf(
     '"%s","%s","%s",""' . PHP_EOL,
     date(DateTime::COOKIE),
     $sessionOperationType,
     $sessionFileName
   );
   
   if (file_exists($sessionFilePath)) {
     session_start();
     session_decode(file_get_contents($sessionFilePath));
   
     foreach ($_SESSION as $name => $data) {
       $value = '<empty>';
       if (isset($data['_session_validator_data']) && isset($data['_session_validator_data']['session_expire_timestamp'])) {
         $value = $data['_session_validator_data']['session_expire_timestamp'];
       }
       $logString .= sprintf(
         '"","","","%s","%s"' . PHP_EOL,
         $name,
         $value
       );
     }
   }
   
   file_put_contents($sessionLogStoragePath . $sessionFileName, $logString, FILE_APPEND);

   dan di sini adalah incrontabentri yang sesuai

   /var/www/html/magento-doc-root/var/session IN_MODIFY,IN_CREATE,IN_DELETE,IN_MOVE /usr/bin/php /var/www/html/log-session-data-change.php $@/$# $%

   output sampel

   "Wednesday, 05-Apr-2017 18:09:06 CEST","IN_MODIFY","sess_94rfglnua0phncmp98hbr3k524",""
   "","","","core","1491408665"
   "","","","customer_base","1491408665"
   "","","","catalog","1491408665"
   "","","","checkout","1491408665"
   "","","","reports","1491408494"
   "","","","store_default","1491408665"
   "","","","rss","1491408524"
   "","","","admin","1491408524"

PS:

Versi saat ini keduanya

skin/frontend/enterprise/default/js/opcheckout.js 
src/skin/frontend/base/default/js/opcheckout.js

tidak dapat menangani pengecualian di atas selama permintaan AJAX. Mereka benar-benar tidak menampilkan apa pun kepada pengguna, sementara pengguna keluar secara efektif!

PPS:

rupanya versi Magento CE 1.9.3.x juga terpengaruh, lihat https://github.com/OpenMage/magento-mirror/blame/magento-1.9/app/code/core/Mage/Core/Model/Session/Abstract/ Varien.php

PPPS:

Ketika saya mengatakan "Hapus kode ini." Maksud saya mengecualikan blok berikut

if ($this->useValidateSessionExpire()
    && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP])
    && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
    return false;
} else {
    $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
        = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
}

Anda dapat melakukannya dengan banyak cara, termasuk:

1. Cukup hapus bit itu dari file
2. Mengomentari itu
3. Kembali sebelum itu
4. Membuat $this->useValidateSessionExpire()pengembalian menjadi benar
5. ...
6. Ini pemrograman - menjadi kreatif;)

6. Ini pemrograman - menjadi kreatif;)

Cara lain untuk memperbaikinya (dan meningkatkan validasi sesi)

ColinM @ https://github.com/OpenMage/magento-lts

Kode sesi saat ini menyimpan data validator sesi dalam setiap namespace dan juga memvalidasinya setiap kali namespace dimasukkan. Ini buruk karena:

1. Ruang penyimpanan sesi sangat tidak efisien. Data validator sering kali terdiri atas lebih dari 50% ruang yang digunakan oleh namespace dan ketika ada banyak ruang nama ini menambahkan hingga satu ton limbah. Penyimpanan sesi dapat dipotong secara drastis dengan tambalan ini dan saat menggunakan penyimpanan dalam memori seperti Redis atau Memcached yang sangat berarti.
2. Siklus komputasi yang tidak efisien karena beberapa ruang nama berarti banyak validasi dan tidak ada alasan yang baik untuk ini berbeda satu sama lain.
3. Sebenarnya menciptakan bug seperti # 394 mana data validator diperbarui pada beberapa permintaan tetapi tidak pada yang lain (sehingga bisa berbeda tetapi tidak seharusnya). Saya belum menguji tetapi saya yakin ini juga akan memperbaiki masalah ini.

diff --git a/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php b/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
index 45d736543..ea6b464f1 100644
--- a/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
+++ b/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
@@ -35,6 +35,9 @@ class Mage_Core_Model_Session_Abstract_Varien extends Varien_Object
     const VALIDATOR_SESSION_EXPIRE_TIMESTAMP    = 'session_expire_timestamp';
     const SECURE_COOKIE_CHECK_KEY               = '_secure_cookie_check';

+    /** @var bool Flag true if session validator data has already been evaluated */
+    protected static $isValidated = FALSE;
+
     /**
      * Map of session enabled hosts
      * @example array('host.name' => true)
@@ -406,16 +409,21 @@ public function getValidateHttpUserAgentSkip()
     /**
      * Validate session
      *
-     * @param string $namespace
+     * @throws Mage_Core_Model_Session_Exception
      * @return Mage_Core_Model_Session_Abstract_Varien
      */
     public function validate()
     {
-        if (!isset($this->_data[self::VALIDATOR_KEY])) {
-            $this->_data[self::VALIDATOR_KEY] = $this->getValidatorData();
+        // Backwards compatibility with legacy sessions (validator data stored per-namespace)
+        if (isset($this->_data[self::VALIDATOR_KEY])) {
+            $_SESSION[self::VALIDATOR_KEY] = $this->_data[self::VALIDATOR_KEY];
+            unset($this->_data[self::VALIDATOR_KEY]);
+        }
+        if (!isset($_SESSION[self::VALIDATOR_KEY])) {
+            $_SESSION[self::VALIDATOR_KEY] = $this->getValidatorData();
         }
         else {
-            if (!$this->_validate()) {
+            if ( ! self::$isValidated && ! $this->_validate()) {
                 $this->getCookie()->delete(session_name());
                 // throw core session exception
                 throw new Mage_Core_Model_Session_Exception('');
@@ -432,8 +440,9 @@ public function validate()
      */
     protected function _validate()
     {
-        $sessionData = $this->_data[self::VALIDATOR_KEY];
+        $sessionData = $_SESSION[self::VALIDATOR_KEY];
         $validatorData = $this->getValidatorData();
+        self::$isValidated = TRUE; // Only validate once since the validator data is the same for every namespace

         if ($this->useValidateRemoteAddr()
                 && $sessionData[self::VALIDATOR_REMOTE_ADDR_KEY] != $validatorData[self::VALIDATOR_REMOTE_ADDR_KEY]) {
@@ -444,10 +453,8 @@ protected function _validate()
             return false;
         }

-        $sessionValidateHttpXForwardedForKey = $sessionData[self::VALIDATOR_HTTP_X_FORVARDED_FOR_KEY];
-        $validatorValidateHttpXForwardedForKey = $validatorData[self::VALIDATOR_HTTP_X_FORVARDED_FOR_KEY];
         if ($this->useValidateHttpXForwardedFor()
-            && $sessionValidateHttpXForwardedForKey != $validatorValidateHttpXForwardedForKey ) {
+                && $sessionData[self::VALIDATOR_HTTP_X_FORVARDED_FOR_KEY] != $validatorData[self::VALIDATOR_HTTP_X_FORVARDED_FOR_KEY]) {
             return false;
         }
         if ($this->useValidateHttpUserAgent()

^{Sumber: https://github.com/OpenMage/magento-lts/commit/de06e671c09b375605a956e100911396822e276a}

Memperbarui:

Perbaiki untuk web/session/use_http_x_forwarded_for optionopsi yang dinonaktifkan ... https://github.com/OpenMage/magento-lts/pull/457/commits/ec8128b4605e82406679c3cd81244ddf3878c379

Bagaimana Anda menyimpan sesi? (mis. dalam var / session / atau dalam DB, atau menggunakan mesin caching lainnya seperti Redis atau Memcached)

Apa pun yang Anda gunakan, pastikan izin menulis Anda sudah benar var/session/(biasanya diatur ke 755 untuk dir dan 644 untuk file), atau jika Anda menggunakan Redis atau Memcache, pastikan pengaturan koneksi dan batas waktu Anda baik untuk .

Inchoo memiliki tutorial yang bagus untuk Redis: http://inchoo.net/magento/using-redis-cache-backend-and-session-storage-in-magento/

Jika menggunakan Memcache, periksa artikel ini (merujuk pada v1.10, tetapi seharusnya tidak jauh berbeda): http://www.magestore.com/magento/magento-sessions-disappearing-with-memcache-turned-on.html

Juga, jika Anda kebetulan menggunakan sesuatu seperti Varnish, ada masalah di masa lalu dengan sesi di mana lubang-lubang halaman tertentu diperlukan.

Terakhir, jika Anda menggunakan sistem file untuk sesi Anda, Anda mungkin merasa lega hanya dengan mengalihkan <session_save>node di local.xml"db" alih-alih "file".

Dari ini <session_save><![CDATA[files]]></session_save>

Untuk ini <session_save><![CDATA[db]]></session_save>

Detail oleh Anton Boritskiy fantastis. Tetapi alih-alih mengecualikan blok ini Anda bisa membuat salinan lokal sehingga Anda tidak mengedit inti dan menulis ulang blok seperti:

if ($this->useValidateSessionExpire() ) {
    // If the VALIDATOR_SESSION_EXPIRE_TIMESTAMP key is not set, do it now
    if( !isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]) ) {
        // $this->_data is a reference to the $_SESSION variable so it will be automatically modified
        $this->_data[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] = time() + $this->getCookie()->getLifetime();
        return true;
    } elseif ( $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) {
        return false;
    }
} else {
    $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]
        = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP];
}

Ini memastikan bahwa perbandingan antara waktu () dan session_expire_timestamp hanya dieksekusi ketika kunci ada dan bahwa ketika sesi ditemukan yang tidak memiliki kunci (yaitu sesi pra 1.9.3) kunci ditambahkan.