Magento 1 EE v 1.14.3.x (और CE 1.9.3.x) में सत्र सत्यापन विफलता

18

मैं 400-500 आगंतुकों और प्रति दिन 40-50 आदेशों के साथ एक Magento दुकान की देखभाल कर रहा हूं। हाल ही में सिस्टम को Magento EE 1.14.2.4 से Magento EE 1.14.3.2 में अपग्रेड किया गया था और मैंने लॉग में कुछ अजीब अपवाद देखे:

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

मैं उस अपवाद का पीछा कर रहा था और मुझे पता है कि इसे निकाल दिया जा रहा है क्योंकि निम्न सत्र सत्यापन कोड सत्र को मान्य करने में विफल रहता है:

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() ) {

यह अगर-ब्लॉक फ़ाइल में Magento की नवीनतम रिलीज़ के साथ जोड़ा गया था। और यह स्पष्ट रूप से एक ब्रेकिंग परिवर्तन है, नीचे अधिक विवरण देखें।

अपवाद काफी बार हो रहा है, प्रति दिन एक दर्जन बार की तरह। लेकिन मैं उन स्थितियों को फिर से बनाने में सक्षम नहीं हूं, जो अपवाद को जन्म देती हैं, जब तक कि मैं सचमुच ऊपर की स्थिति में सही नहीं हूं। अपवाद अक्सर उत्पाद विवरण पृष्ठों और एक पृष्ठ चेकआउट के अंतिम चरण पर होते हैं। दुकान एक b2b दुकान है, उपयोगकर्ता को उत्पाद पृष्ठ देखने या चेकआउट करने में सक्षम होना चाहिए, इसका मतलब है कि सत्र अमान्य / समाप्त होने पर उपयोगकर्ता लॉगिन पृष्ठों पर पुनर्निर्देशित हो सकता है। फिलहाल मेरे लिए चेकआउट के दौरान इस समस्या को ठीक करना अधिक महत्वपूर्ण है।

उपयोगकर्ता के दृष्टिकोण से क्या होता है: उपयोगकर्ता कार्ट को भरता है, चेकआउट करने के लिए आगे बढ़ता है और अंतिम चरण तक पहुंचता है, फिर वह "ऑर्डर सबमिट करें" बटन को हिट करता है और कुछ भी नहीं होता है। पर्दे के पीछे मैगेंटो के जेएस एक AJAX अनुरोध करते हैं और जेएस को JSON को वापस लेने की उम्मीद है, लेकिन अगर यह त्रुटि होती है तो लॉगिन पृष्ठ का HTML वापस आ जाता है, जिसे जावास्क्रिप्ट द्वारा पार्स नहीं किया जा सकता है और यह कुछ भी नहीं करता है। यह उपयोगकर्ताओं के लिए सुपर भ्रामक है।

खैर, यह पूरी तरह से उपयोगकर्ता का परिदृश्य नहीं है, हमने उपयोगकर्ताओं से संपर्क किया और उन्होंने हमें बताया कि उन्होंने गाड़ी को भरने और ऑर्डर जमा करने के बीच कुछ दिनों तक इंतजार किया, इसका क्या मतलब है यह पता लगाना मुश्किल है, क्योंकि लोगों को बस यह याद नहीं है।

PHP जीवनकाल - 350000 (सेकंड में 4 दिन) कुकी जीवनकाल - 345600 (4 दिन)

यहां वास्तविक प्रश्न है: मैं कैसे पता लगा सकता हूं कि उपयोगकर्ता व्यवहार किस प्रकार के अपवाद को जन्म देता है?

अद्यतन अब तक मुझे पता है कि मेरे द्वारा किए गए अनुरोध के अनुसार निम्न वर्गों में अपवाद होता है, जिसका अर्थ है दुर्भाग्य से कुछ भी नहीं।

/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

अद्यतन 2 : सत्र फाइलों में संग्रहीत होते हैं और PHP सत्र कचरा संग्रहकर्ता द्वारा साफ किए जाते हैं, यह एक अच्छा विकल्प है या नहीं, इस प्रश्न के दायरे से बाहर है।

session  magento1.9.3  bug  ee-1.14  ee-1.14.3.0 
— एंटोन बोरिट्सकी
स्रोत
संबंधित: maxchadwick.xyz/blog/…
— साइमन

जवाबों:

24

कुछ उन्नत डिबगिंग, सत्र अनुरेखण और उस सभी जादू के बारे में सोचने के बाद मैं समस्या को पुन: पेश करने और इसके कारण को समझने में सक्षम था। मैंने थोड़ा समय चित्रण तैयार किया, आप इसे नीचे देख सकते हैं।

समस्या का समय

  • लाल झंडा उपयोगकर्ता लॉगिन और सत्र निर्माण का क्षण है
  • नीला झंडा वह क्षण होता है जब उपयोगकर्ता कैटलॉग पेज खोलता है, मान लेते हैं कि यह एक श्रेणी पेज है जिसे खोला गया है।
  • हरी झंडी वह क्षण है जहां उपयोगकर्ता आदेश ( /sales/order/save/...अनुरोध) जमा करता है

यहाँ कैसे पुन: पेश करने के लिए है:

  1. शुरू करने से पहले: अपना PHP सत्र टाइमआउट और Magento कुकी टाइमआउट दोनों को 1440 पर सेट करें जो कि डिफ़ॉल्ट PHP मान है।
  2. अपने सभी कुकीज़ को मारें या गुप्त टैब खोलें।
  3. अपनी Magento की दुकान पर जाएं और लॉगिन करें (फ्लैग 1 देखें)
  4. कैटलॉग के माध्यम से जाओ और गाड़ी में कुछ उत्पादों को जोड़ें (फ्लैग 2)
  5. चेकआउट के माध्यम से जाओ और एक आदेश सबमिट करें। उस समय को नोट करें जब आपने इसे किया था। (झंडा ३)
  6. कैटलॉग के माध्यम से जाओ और गाड़ी में कुछ उत्पादों को जोड़ें (झंडा 4)
  7. अपने कार्ट पेज को रीफ्रेश करते रहें या कैटलॉग पेजों से इतने लंबे समय तक गुजरें कि आपके द्वारा मैगेंटो कुकीज एक्सपायर होने की समय सीमा समाप्त हो जाए (फ्लैग 5-6)। ध्यान दें कि फ्लैग 7 और फ्लैग 3 के बीच का समय कुकी टाइमआउट से बड़ा होना चाहिए।
  8. चेकआउट के माध्यम से जाओ और एक आदेश सबमिट करें (फ्लैग 7)। उपरोक्त आदेश मेरे प्रश्न में वर्णित अपवाद के कारण विफल हो जाएगा।

कारण:

कुछ निश्चित सत्र हैं जो केवल दिए गए अनुरोधों पर त्वरित हैं, उदाहरण के Mage_Rss_Model_Sessionलिए केवल वास्तविक चेकआउट के दौरान त्वरित किया जाता है और कैटलॉग के माध्यम से ब्राउज़ करते समय नहीं। एक ही समय सत्र समाप्ति समाप्ति टाइमस्टैम्प केवल तब निर्धारित किया जाता है जब सत्र तत्काल किया गया था। इसका मतलब है कि अगर दो चेकआउट के बीच पर्याप्त समय था और सत्र इस बीच नहीं मारा गया था (क्योंकि उपयोगकर्ता लॉग आउट या कुकी समाप्त हो गया है) नया मैगेंटो कोड उस सत्र को मान्य नहीं होने के रूप में मानेगा और अपवाद को फेंक देगा, जो किसी भी तरह से अजीब लगता है मुझे।

कैसे ठीक करना है:

खैर, मेरे पास कुछ विकल्प हैं:

  1. Magento के उस पर प्रतिक्रिया करने और उस कोड पर पुनर्विचार करने तक प्रतीक्षा करें।
  2. इस बीच इस कोड को हटा दें।
  3. अगर आपके लिए एक विकल्प है, तो Magento कुकी टाइमआउट को 0 पर सेट करने का प्रयास करें।

मैंने यह कैसे पता लगाया:

  1. मैंने निम्नलिखित को मूल कोड में जोड़ने के साथ शुरू किया 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
);

    इसने मुझे प्रभावित वर्गों और उनके सहसंबंध के बारे में एक अच्छी जानकारी दी और कितना सत्र समाप्त हो गया। लेकिन वह यह नहीं समझा रहा था कि ऐसा क्यों होता है और कौन से उपयोगकर्ता कार्रवाई में समस्या पैदा करते हैं।

  2. तब मैंने विचार करना शुरू किया कि मैं सत्र डेटा के सभी परिवर्तनों को कैसे ट्रेस कर सकता हूं और इस सवाल पर आया हूं /superuser/368231/automatic-versioning-upon-file-change-modify-code-delete मैंने देने का फैसला किया कोशिश gitऔर incronसंयोजन करने के लिए , लेकिन जब मैंने इसे लागू किया और सैंडबॉक्स में परीक्षण किया, तो मुझे एहसास हुआ कि मैं उत्पादन में वास्तव में तेजी से डिस्क स्थान से बाहर चला जाऊंगा।

  3. मैंने एक छोटी सी PHP स्क्रिप्ट बनाने का फैसला किया, जो सत्र डेटा को डिकोड करेगी और प्रत्येक सेशन के लिए लॉग्स लिखेगी। इस लिपि द्वारा बुलाया गया थाincron

    <?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);

    और यहाँ इसी incrontabप्रविष्टि है

    /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 $@/$# $%

    नमूना उत्पादन

    "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"

पुनश्च:

दोनों के वर्तमान संस्करण

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

AJAX अनुरोध के दौरान ऊपर दिए गए अपवाद को संभालने में सक्षम नहीं हैं। वे उपयोगकर्ता के लिए शाब्दिक रूप से कुछ भी प्रदर्शित नहीं करते हैं, जबकि उपयोगकर्ता प्रभावी रूप से लॉग आउट हो जाता है!

पी पी एस:

जाहिरा तौर पर Magento CE 1.9.3.x संस्करण भी प्रभावित होते हैं, https://github.com/OpenMage/magento-mirror/blame/magento-1.9/app/code/core/Mage/Core/Model-Session/Abstract/ देखें Varien.php

PPPS:

जब मैंने कहा "इस कोड को इस बीच हटा दें।" मेरा मतलब निम्नलिखित ब्लॉक को छोड़कर था

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];
}

आप ऐसा कई तरीकों से कर सकते हैं, जिनमें शामिल हैं:

  1. बस फ़ाइल से उस बिट को हटा रहा है
  2. टिप्पणी कर रहा है
  3. उसके पहले लौट आना
  4. बनाना $this->useValidateSessionExpire()वापसी सच
  5. ...
  6. यह प्रोग्रामिंग है - रचनात्मक हो;)
— एंटोन बोरिट्सकी
स्रोत
मैंने अभी अक्षम किया है <Mage_Rss>और इस मुद्दे को (अस्थायी फिक्स) तय किया है और मैगेंटो के समर्थन से टिकट दर्ज किया है।
— दामोदर बाश्याल
1
@DamodarBashyal कृपया ध्यान रखें कि समस्या केवल चेकआउट को प्रभावित नहीं करती है। यह उत्पाद पृष्ठों को भी प्रभावित करता है, मेरा मानना ​​है कि कुछ अन्य पृष्ठ भी प्रभावित हो सकते हैं। कारण - हर मैग्नेटो कंट्रोलर एक्शन पर सत्र ऑब्जेक्ट्स के अलग-अलग सेट को इनिशियलाइज़ किया जाता है। जरूरत पड़ने पर और स्पष्टीकरण दे सकता हूं।
— एंटोन बोरिट्सकी
मुझे एपीआई के साथ समस्या थी, जब शिपमेंट बनाने में मुझे त्रुटि हो रही थी। पढ़ें ठीक था, लेकिन मुद्दा तब तक लिख रहा था जब तक कि यह अक्षम नहीं था। जानकारी के लिए Thx।
— दामोदर बाश्याल
9

6. यह प्रोग्रामिंग है - रचनात्मक हो;)

इसे ठीक करने का एक और तरीका (और सत्र सत्यापन में सुधार)

कॉलिनम @ https://github.com/OpenMage/magento-lts

सत्र कोड वर्तमान में प्रत्येक नाम स्थान के भीतर सत्र सत्यापनकर्ता डेटा संग्रहीत करता है और हर बार यह भी पुष्टि करता है कि नाम स्थान में प्रवेश है। यह बुरा है क्योंकि:

  1. सत्र भंडारण स्थान का अत्यधिक अक्षम होना। सत्यापनकर्ता डेटा में अक्सर 50% से अधिक स्थान होते हैं जिनका उपयोग किसी नाम स्थान द्वारा किया जाता है और जब कई नामस्थान होते हैं तो यह एक टन कचरे में जुड़ जाता है। इस पैच के साथ सेशन स्टोरेज में भारी कटौती की जा सकती है और जब इन-मेमोरी स्टोरेज का उपयोग किया जाता है जैसे कि Redis या Memcached जो बहुत मायने रखता है।
  2. कई नामस्थानों का अर्थ है कि कई मान्यताओं का मतलब है और इनका एक दूसरे से अलग होने का कोई अच्छा कारण नहीं है।
  3. दरअसल # 394 जैसे बग बनाता है जहां सत्यापनकर्ता डेटा को कुछ अनुरोधों पर अपडेट किया जाता है लेकिन दूसरों को नहीं (इसलिए यह अलग हो सकता है लेकिन ऐसा नहीं होना चाहिए)। मैंने परीक्षण नहीं किया है लेकिन मेरा मानना ​​है कि यह इस समस्या को भी ठीक कर देगा।
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()

स्रोत: https://github.com/OpenMage/magento-lts/commit/de06e671c09b375605a956e100911396822e276a

अपडेट करें:

web/session/use_http_x_forwarded_for optionअक्षम विकल्प के लिए ठीक करें ... https://github.com/OpenMage/magento-lts/pull/457/commits/ec8128b4605e82406679c3cd81244ddf3878c379

— sv3n
स्रोत
1
यह वास्तव में अच्छा लग रहा है, उत्पादन में इसका उपयोग करने वाला कोई भी अनुभव?
— एंटोन बोरिट्सकी
@AntonBoritskiy हां, मैं उत्पादन में इसका उपयोग करता हूं। सही काम करता है।
— sv3n
sv3n समाधान की इस पद्धति के लिए कोई संभावित बुरे पक्ष हैं?
— वैशाल पटेल
@VaishalPatel अगर कोई संभावित खराब पक्ष हैं, तो मैं उन्हें वास्तव में नहीं देखता हूं :) मैं उत्पादन पर इसका उपयोग करता हूं और इसने सभी सत्र सत्यापन समस्याओं को हल किया। अगर मुझे कोई चिंता है तो मैं इसे पोस्ट नहीं करूंगा, लेकिन अगर आपको संदेह है तो कृपया यहां पूछें: github.com/OpenMage/magento-lts/pull/406 । शायद एसई "पेशेवरों" में से कुछ के पास इसकी समीक्षा करने के लिए कुछ समय है?
— sv3n
मैं अपने उत्पादन पर डाल देंगे। किसी भी तरह से यह एक समाधान की दिशा में प्रगति कर रहा है।
— वैशाल पटेल
1

आप सत्रों का भंडारण कैसे कर रहे हैं? (अर्थात var / सत्र / या DB में, या अन्य कैशिंग इंजन जैसे Redis या Memcached का उपयोग करके)

जो भी आप इसका उपयोग कर रहे हैं, सुनिश्चित करें कि आपकी लिखने की अनुमति सही है var/session/(आमतौर पर 755 और फ़ाइलों के लिए 644 पर सेट है), या यदि आप रेडिस या मेमेचे का उपयोग कर रहे हैं, तो सुनिश्चित करें कि आपका कनेक्शन और टाइमआउट सेटिंग्स उन लोगों के लिए अच्छी हैं। ।

इनचू में रेडिस के लिए एक अच्छा ट्यूटोरियल है: http://inchoo.net/magento/use-redis-cache-backend-and-session-storage-in-magento/

यदि मेमेचे का उपयोग किया जाता है, तो इस लेख को चेक करें (यह v1.10 का संदर्भ देता है, लेकिन बहुत अलग नहीं होना चाहिए): http://www.magestore.com/magento/magento-session-disappearing-with-memcache-turned-on.html

इसके अलावा, यदि आप वार्निश जैसी किसी चीज़ का उपयोग करते हैं, तो अतीत में सत्रों के साथ कुछ ऐसे मुद्दे रहे हैं जहाँ कुछ पन्नों को छेदने की ज़रूरत थी।

अंत में, यदि आप अपने सत्र के लिए फाइल सिस्टम का उपयोग कर रहे हैं, तो आपको "फाइल" के बजाय <session_save>नोड local.xmlको "db" में स्विच करके राहत मिल सकती है ।

इस से <session_save><![CDATA[files]]></session_save>

इसके लिए <session_save><![CDATA[db]]></session_save>

— gtr1971
स्रोत
संकेत के लिए धन्यवाद - मुझे इस सवाल को जानकारी जोड़ना चाहिए था कि मैं सत्रों को वास्तव में कैसे संग्रहीत करता हूं, मैं उन्हें फाइलों में संग्रहीत करता हूं। मैं अभी मूल मुद्दे का पता लगाता हूं, मैं समझता हूं कि मैगेंटो बग। मैं इसे
— लपेटूंगा
महान! ... क्या मेरे जवाब ने समाधान के साथ बिल्कुल मदद की?
— gtr1971
वास्तव में नहीं - मेरा उत्तर
— देखिए
0

एंटोन बोरिट्सकी द्वारा विस्तार शानदार है। लेकिन इस ब्लॉक को बाहर करने के बजाय आप एक स्थानीय प्रतिलिपि बना सकते हैं ताकि आप कोर का संपादन न करें और ब्लॉक को फिर से लिखें जैसे:

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];
}

यह आश्वासन देता है कि समय () और session_expire_timestamp के बीच तुलना केवल तब होती है जब कुंजी मौजूद होती है और जब एक सत्र पाया जाता है जिसमें कुंजी नहीं होती है (यानी पूर्व 1.9.3 सत्र) कुंजी जोड़ा जाता है।

— वैशाल पटेल
स्रोत
स्थानीय प्रतिलिपि जोड़ना और ओवरराइड करना निश्चित रूप से बेहतर है, फिर कोर फ़ाइलों को संशोधित करना, हम आंतरिक रूप से उन पैच की सूची को बनाए रखते हैं जो स्वचालित रूप से परियोजना के निर्माण के दौरान लागू होते हैं, क्योंकि मैगेंटो हाल ही में इस तरह के कुछ कीड़े जारी कर रहा था।
— एंटोन बोरिट्सकी
उसी समय मैं यह नहीं देखता कि आपका परिवर्तन मूल समस्या को कैसे ठीक करता है, थोड़ा और विस्तृत विवरण जोड़ सकता है?
— एंटोन बोरिट्सकी
Anto Boritskiy कि सूची के साथ एक अच्छा चिल्ला है।
— वैशाल पटेल
Anto Boritskiy, नई कुंजी का उपयोग सत्र टाइमस्टैम्प की वैधता की जाँच में किया जाता है। $ sessionData $ इस से आता है -> _ डेटा [स्वयं :: VALIDATOR_KEY]; लेकिन session_expire_timestamp कुंजी केवल सत्र के लिए इस $ से जोड़ दी जाती है-> getValidatorData (); फ़ंक्शन और $ में यह संग्रहीत -> _ डेटा [...] फ़ंक्शन-कॉल के अंत में। इस प्रकार समस्या यह है कि मौजूदा सत्रों में यह session_expire_timestamp कुंजी उपलब्ध नहीं है।
— वैशाल पटेल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.