ম্যাজেন্টো 1 EE বনাম 1.14.3.x (এবং সিই 1.9.3.x) এ সেশনের বৈধতা ব্যর্থতা

18

আমি প্রতিদিন 400-500 দর্শনার্থী এবং 40-50 অর্ডার সহ একটি ম্যাজেন্টো শপ যত্ন করছি। সম্প্রতি সিস্টেমটি ম্যাজেন্টো 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() ) {

এই ই-ব্লকটি ম্যাজেন্টো থেকে সর্বশেষ প্রকাশের সাথে ফাইলটিতে যুক্ত করা হয়েছিল। এবং এটি আপাতদৃষ্টিতে ব্রেকিং পরিবর্তন, নীচে আরও বিশদ দেখুন।

ব্যতিক্রম বেশিরভাগ ক্ষেত্রেই ঘটছে, প্রতিদিন এক ডজন বারের মতো। আমি যদি উপরে অবস্থার সাথে আক্ষরিকভাবে সত্য না রাখি তবে আমি এমন শর্ত পুনরায় তৈরি করতে পারছি না যা ব্যতিক্রম ঘটায়। ব্যতিক্রমগুলি বেশিরভাগ ক্ষেত্রে পণ্যের বিবরণ পৃষ্ঠাগুলিতে এবং এক পৃষ্ঠার চেকআউটের শেষ ধাপে ঘটে। দোকানটি একটি বি 2 বি শপ, ব্যবহারকারীর পণ্য পৃষ্ঠা দেখতে বা চেকআউট করতে সক্ষম হতে হবে, মানে সেশনটি অবৈধ / মেয়াদোত্তীর্ণ হওয়ার পরে ব্যবহারকারীর পাতাগুলি লগইন করতে হবে। এই মুহুর্তে আমার পক্ষে চেকআউট করার সময় এই সমস্যাটি সমাধান করা আরও গুরুত্বপূর্ণ।

ব্যবহারকারীর দৃষ্টিকোণ থেকে যা ঘটে: ব্যবহারকারী কার্টটি পূরণ করে, চেকআউট করতে এগিয়ে যায় এবং শেষ ধাপে পৌঁছে যায়, তারপরে সে "অর্ডার জমা দিন" বোতামটি আঘাত করে এবং কিছুই ঘটে না। পর্দার আড়ালে ম্যাজেন্টোর জেএস একটি এজেএক্স অনুরোধ সম্পাদন করে এবং জেএস জেএসএনকে ফিরে পাওয়ার প্রত্যাশা করে, তবে এই ত্রুটিটি ঘটলে লগইন পৃষ্ঠার এইচটিএমএল ফিরে আসে, যা জাভাস্ক্রিপ্ট দ্বারা পার্স করা যায় না এবং এটি ঠিক কিছুই করে না। এটি ব্যবহারকারীদের জন্য অত্যন্ত বিভ্রান্তিকর।

ঠিক আছে, এটি সম্পূর্ণ ব্যবহারকারীর পরিস্থিতি নয়, আমরা ব্যবহারকারীদের সাথে যোগাযোগ করেছি এবং তারা আমাদের জানিয়েছিল যে তারা কার্টটি পূরণ এবং অর্ডার জমা দেওয়ার মধ্যে কয়েক দিনের জন্য অপেক্ষা করেছিলেন, এর সঠিক অর্থটি কী তা খুঁজে পাওয়া শক্ত, কারণ লোকেরা কেবল এটি মনে রাখে না।

পিএইচপি সেশন আজীবন - 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 : সেশনগুলি ফাইলগুলিতে সঞ্চয় করা হয় এবং পিএইচপি সেশন আবর্জনা সংগ্রহকারী দ্বারা পরিষ্কার করা হয়, এটি ভাল পছন্দ কিনা তা এই প্রশ্নের আওতার বাইরে নয়।

session  magento1.9.3  bug  ee-1.14  ee-1.14.3.0 
— আন্তন বরিটস্কি
সূত্র
সম্পর্কিত: maxchadwick.xyz/blog/…
— সাইমন

উত্তর:

24

কিছু উন্নত ডিবাগিংয়ের পরে, সেশনটি ট্রেসিং এবং সমস্ত যাদু সম্পর্কে চিন্তাভাবনা করার পরে আমি সমস্যার পুনরুত্পাদন করতে এবং এর কারণ বুঝতে সক্ষম হয়েছি। আমি একটি সামান্য সময়ের চিত্র প্রস্তুত করেছি, আপনি নীচে এটি দেখতে পারেন।

সমস্যা সময়

  • লাল পতাকাটি ব্যবহারকারী লগইন এবং সেশন তৈরির মুহূর্ত
  • নীল পতাকাটি সেই মুহুর্তে যখন ব্যবহারকারী ক্যাটালগ পৃষ্ঠাটি খুলবে, ধরা যাক এটি একটি বিভাগ পৃষ্ঠা যা খোলা আছে।
  • সবুজ পতাকা হল সেই মুহুর্তে যেখানে ব্যবহারকারী অর্ডার জমা দেয় ( /sales/order/save/...অনুরোধ)

পুনরুত্পাদন করার উপায় এখানে:

  1. আপনি শুরু করার আগে: আপনার পিএইচপি সেশন সময়সীমা এবং ম্যাজেন্টো কুকির সময়সীমা উভয়ই 1440 হিসাবে সেট করুন যা ডিফল্ট পিএইচপি মান।
  2. আপনার সমস্ত কুকি হত্যা করুন বা ছদ্মবেশী ট্যাবটি খুলুন।
  3. আপনার ম্যাজেন্টোর দোকানে যান এবং লগইন করুন (পতাকা 1 দেখুন)
  4. ক্যাটালগ মাধ্যমে যান এবং কার্টে কিছু পণ্য যুক্ত করুন (পতাকা 2)
  5. চেকআউট মাধ্যমে যান এবং একটি আদেশ জমা দিন। আপনি যখন এটি করেছিলেন তখন নোট করুন। (পতাকা 3)
  6. ক্যাটালগ মাধ্যমে যান এবং কার্টে কিছু পণ্য যুক্ত করুন (পতাকা 4)
  7. আপনার কার্ট পৃষ্ঠাটি রিফ্রেশ করে রাখুন বা ক্যাটালগ পৃষ্ঠাগুলি এতক্ষণ ধরে রাখুন যে আপনি ম্যাজেন্টো কুকিগুলির জন্য কনফিগার করেছেন এমন সময়সীমা সমাপ্ত হবে (পতাকা 5-6)। নোট করুন যে পতাকা 7 এবং পতাকা 3 এর মধ্যে সময়টি কুকির সময়সীমা চেয়ে বড় হওয়া উচিত।
  8. চেকআউট মাধ্যমে যান এবং একটি আদেশ জমা দিন (পতাকা 7)। উপরের আমার প্রশ্নে বর্ণিত ব্যতিক্রমের কারণে অর্ডার জমা দেওয়া ব্যর্থ হবে।

কারণ:

কিছু নির্দিষ্ট সেশন রয়েছে যা কেবলমাত্র প্রদত্ত অনুরোধগুলিতে তাত্ক্ষণিকভাবে প্রয়োগ করা হয়, উদাহরণস্বরূপ Mage_Rss_Model_Sessionকেবল প্রকৃত চেকআউট চলাকালীন তা ইনস্টল করা হয় এবং ক্যাটালগের মাধ্যমে ব্রাউজ করার সময় নয়। একই সময়ে সেশনটির মেয়াদ শেষ হওয়ার টাইমস্ট্যাম্পটি তখনই সেট করা থাকে যখন সেশনটি তাত্ক্ষণিকভাবে চালু করা হয়েছিল। এর অর্থ হ'ল যদি দুটি চেকআউটগুলির মধ্যে পর্যাপ্ত সময় ছিল এবং সেশনের মধ্যে না মারা গিয়েছিল (কারণ ব্যবহারকারী লগ আউট করেছেন বা কুকির মেয়াদ উত্তীর্ণ হয়েছে) তবে নতুন ম্যাজেন্টো কোড সেই অধিবেশনটিকে বৈধতা পাবে না বলে বিবেচনা করবে এবং একটি ব্যতিক্রম ছুঁড়ে দেবে, যা কিছুটা অদ্ভুত বলে মনে হয় sounds আমাকে.

কিভাবে ঠিক করবো:

ঠিক আছে, আমার কাছে কয়েকটি বিকল্প রয়েছে:

  1. ম্যাজেন্টো সে পর্যন্ত প্রতিক্রিয়া জানায় এবং সেই কোডটি পুনর্বিবেচনা করা পর্যন্ত অপেক্ষা করুন।
  2. ইতিমধ্যে এই কোডটি সরান।
  3. যদি এটি আপনার জন্য বিকল্প হয় তবে ম্যাজেন্টো কুকির সময়সীমা 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-create-delete আমি দেওয়ার সিদ্ধান্ত নিয়েছেন চেষ্টা gitএবং incronসংমিশ্রণ, কিন্তু আমি এটি প্রয়োগ করে এবং স্যান্ডবক্সে পরীক্ষা করার পরে, আমি বুঝতে পেরেছিলাম যে উত্পাদনের ক্ষেত্রে আমি খুব দ্রুত ডিস্কের জায়গা ছেড়ে চলে যাব।

  3. আমি একটি ছোট পিএইচপি স্ক্রিপ্ট তৈরি করার সিদ্ধান্ত নিয়েছি যা সেশন ডেটা ডিকোড করবে এবং প্রতিটি সেসনের জন্য লগ লিখবে। এই স্ক্রিপ্ট দ্বারা ডাকা হয়েছিল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 অনুরোধের সময় উপরের ব্যতিক্রমটি পরিচালনা করতে সক্ষম নয়। তারা ব্যবহারকারীর কাছে আক্ষরিক কিছুই প্রদর্শন করে না, যখন ব্যবহারকারী কার্যকরভাবে লগ আউট করে!

PPS:

আপাতদৃষ্টিতে ম্যাজেন্টো সিই 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>এবং এটি সমস্যার সমাধান করেছে (অস্থায়ী স্থির) এবং ম্যাজেন্টো সমর্থন দিয়ে টিকিটটি জমা দিয়েছি।
— দামোদর বাশিয়াল 12'17
1
@ দামোদরবাশিয়াল দয়া করে সচেতন হন যে বিষয়টি কেবল চেকআউটকেই প্রভাবিত করে না। এটি পণ্যের পৃষ্ঠাগুলিকেও প্রভাবিত করে, আমি বিশ্বাস করি যে অন্য কয়েকটি পৃষ্ঠাও প্রভাবিত হতে পারে। কারণ - প্রতিটি ম্যাজেন্টো নিয়ামক ক্রিয়ায় সেশন অবজেক্টের বিভিন্ন সেট শুরু করা হয়। প্রয়োজনে আমি আরও ব্যাখ্যা সরবরাহ করতে পারি।
— আন্তন বরিটস্কি
চালান তৈরি করার সময় আমার ত্রুটি হচ্ছে API পড়ুন ঠিক ছিল তবে এটি অক্ষম না হওয়া পর্যন্ত লেখার বিষয়টি ছিল। তথ্য জন্য Thx।
— দামোদর বাশিয়াল
9

It. এটি প্রোগ্রামিং - সৃজনশীল হোন;)

এটি ঠিক করার আরেকটি উপায় (এবং সেশনের বৈধতা উন্নত করতে হবে)

কলিনম @ https://github.com/OpenMage/magento-lts

সেশন কোডটি বর্তমানে প্রতিটি নেমস্পেসের মধ্যে সেশন বৈধকরণকারীর ডেটা সঞ্চয় করে এবং প্রতিবার নেমস্পেসটি প্রবেশ করা গেলে এটি বৈধ করে তোলে। এটি খারাপ কারণ:

  1. সেশন স্টোরেজ স্পেসের জন্য অত্যন্ত অদক্ষ fficient বৈধকরণকারীর ডেটা প্রায়শই একটি নেমস্পেস দ্বারা ব্যবহৃত স্থানের 50% এর উপরে থাকে এবং যখন অনেক নামস্থান থাকে তখন এতে এক টন বর্জ্য যোগ হয়। এই প্যাচটি দিয়ে এবং রেডিস বা মেমক্যাচের মতো একটি ইন-মেমরি স্টোরেজ ব্যবহার করার সময় সেশন স্টোরেজটি খুব গুরুত্বপূর্ণভাবে কাটা যায়।
  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
যে দেখতে আসলে দেখতে ভাল, কোন উত্পাদন যে ব্যবহার করে?
— আন্তন বরিটস্কি
@ অ্যান্টনবোরিটস্কি হ্যাঁ, আমি এটি প্রযোজনায় ব্যবহার করি। নিখুঁত কাজ করে।
— এসভি 3 ই
এসভি 3 এন সমাধানের এই পদ্ধতির কোনও সম্ভাব্য খারাপ দিক রয়েছে?
— বৈশাল প্যাটেল
@ ভাইশালপ্যাটেল যদি কোনও সম্ভাব্য খারাপ দিক থাকে তবে আমি তাদের আসলে দেখতে চাই না :) আমি এটি উত্পাদনতে ব্যবহার করি এবং এটি সমস্ত সেশনের বৈধতা সমস্যার সমাধান করে। আমার যদি কোনও উদ্বেগ থাকে তবে আমি এটি পোস্ট করব না, তবে আপনার যদি সন্দেহ থাকে তবে দয়া করে এখানে জিজ্ঞাসা করুন: github.com/OpenMage/magento-lts/pull/406 । হয়তো কিছু এসই "পেশাদার" এরও এটি পর্যালোচনা করার জন্য কিছু সময় আছে?
— এসভি 3 ই
আমি আমার প্রযোজনা করা হবে। যে কোনও উপায়ে এটি একটি সমাধানের দিকে অগ্রসর হচ্ছে।
— বৈশাল প্যাটেল
1

আপনি সেশনগুলি কীভাবে সংরক্ষণ করছেন? (উদাহরণস্বরূপ ভার / সেশনে / বা ডিবিতে, বা অন্যান্য ক্যাশিং ইঞ্জিন যেমন রেডিস বা মেমক্যাচ ব্যবহার করে)

আপনি যেটি ব্যবহার করছেন তা নিশ্চিত হয়ে নিন যে আপনার লেখার অনুমতিগুলি সঠিক রয়েছে var/session/(সাধারণত ডায়ারের জন্য 755 এবং ফাইলগুলির জন্য 64৪৪ নির্ধারণ করা হয়েছে), বা আপনি রেডিস বা মেমক্যাচ ব্যবহার করছেন তবে নিশ্চিত হয়ে নিন যে আপনার সংযোগ এবং সময়সীমা সেটিংস সেগুলির জন্য ভাল ।

Inchoo Redis একটি ভাল টিউটোরিয়াল রয়েছে: http://inchoo.net/magento/using-redis-cache-backend-and-session-storage-in-magento/

মেমকেচে ব্যবহার করা থাকলে, এই নিবন্ধটি পরীক্ষা করুন (এটি v1.10 উল্লেখ করে, তবে এটির চেয়ে আলাদা হওয়া উচিত নয়): http://www.magestore.com/magento/ छविnto-sessions-disappering-with-memcache-turned-on.html

এছাড়াও, আপনি যদি বার্নিশের মতো কোনও কিছু ব্যবহার করছেন বলে মনে হয় তবে অতীতে সেশনগুলির ক্ষেত্রে এমন কিছু সমস্যা দেখা গিয়েছিল যেখানে নির্দিষ্ট পৃষ্ঠাগুলি ছিদ্র করে ছিদ্র করা দরকার ছিল।

অবশেষে, আপনি আপনার সেশন জন্য ফাইল সিস্টেম ব্যবহার করছি, আপনি ত্রাণ কেবল সুইচিং দ্বারা পেতে পারে <session_save>আপনার নোড local.xmlপরিবর্তে "ফাইল" এর "ডিবি"।

এটা থেকে <session_save><![CDATA[files]]></session_save>

এই <session_save><![CDATA[db]]></session_save>

— gtr1971
সূত্র
ইঙ্গিতটির জন্য ধন্যবাদ - আমি আসলে সেশনগুলি কীভাবে সংরক্ষণ করব, আমি সেগুলি ফাইলে সংরক্ষণ করি question এই প্রশ্নে আমার তথ্য যুক্ত করা উচিত ছিল। আমি কেবল আসল সমস্যাটি সন্ধান করেছি, আমি বিবেচনা করি একটি ম্যাজেন্টো বাগ। আমি এটিকে
— গুটিয়ে রাখব
দুর্দান্ত! ... আমার উত্তর কি সমাধানের সাথে আদৌ সহায়তা করেছিল?
— 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];
}

এটি আশ্বাস দেয় যে সময় () এবং সেশন_একপায়ার_টাইমস্ট্যাম্পের মধ্যে তুলনা কেবল তখনই চালিত হয় যখন কী উপস্থিত থাকে এবং যখন একটি সেশন পাওয়া যায় যা কী (যেমন একটি পূর্ববর্তী 1.9.3 সেশন) থাকে না কীটি যুক্ত হয়।

— বৈশাল প্যাটেল
সূত্র
একটি স্থানীয় অনুলিপি যুক্ত করা এবং ওভাররাইড করা অবশ্যই মূল ফাইলগুলি সংশোধন করার পরে আরও ভাল we
— আন্তন বরিটস্কি
একই সাথে আমি দেখতে পাচ্ছি না যে আপনার পরিবর্তন কীভাবে মূল সমস্যাটিকে সংশোধন করে, আরও কিছুটা প্রসারিত ব্যাখ্যা যুক্ত করতে পারে?
— আন্তন বরিটস্কি
বোরিটস্কিতে যা তালিকার সাথে একটি দুর্দান্ত চিৎকার।
— বৈশাল প্যাটেল
বোরিটস্কিতে, নতুন কীটি সেশন টাইমস্ট্যাম্পের বৈধতা যাচাই করতে ব্যবহৃত হয়। $ সেশনডেটা আসে $ এটি থেকে -> _ ডেটা [স্ব: :: VALIDATOR_KEY]; তবে সেশন_একপায়ার_টাইমস্ট্যাম্প কীটি কেবলমাত্র $ এটি-> getValidatorData () দ্বারা সেশনে যুক্ত করা হয়েছে; ফাংশন-কল শেষে ফাংশন এবং $ এটি -> _ ডেটা [...] এ সঞ্চিত। সুতরাং সমস্যাটি হ'ল বিদ্যমান সেশনে এই সেশন_একপায়ার_টাইমস্ট্যাম্প কীটি উপলভ্য নয়।
— বৈশাল প্যাটেল 16
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.