php - कुकी सत्र ड्राइवर किसी भी सत्यापन त्रुटि या फ़्लैश डेटा को सहेज नहीं पाएगा




laravel session (2)

मुझे लैरावेल में कुकी सत्र चालक के साथ कठिन समय है।

मेरे पास एक सत्यापन के साथ एक सरल रूप है। यह फ़ॉर्म डेटा सहेजने के लिए यह मेरी विधि है:

public function store()
{
    $this->validate(request(), [
        'name'        => 'required',
        'title'       => 'required',
        'description' => 'required|max:600',
        'image'       => 'required|file|mimes:jpeg,png',
    ]);

    $member = TeamMember::create(request()->all());
    $member->addImage(request()->file('image'));

    return redirect()->route('backoffice.team-members');
}

बहुत साधारण।

समस्या यह है कि, कुकी सत्र ड्राइवर का उपयोग करते समय, यदि मैं इस फ़ॉर्म को 1024 वर्णों के विवरण के साथ सहेजता हूं, तो मुझे वापस रीडायरेक्ट किया जाएगा, लेकिन अगले फ़्लैश अनुरोध के लिए कोई फ्लैश डेटा नहीं होगा और दृश्य में कोई $errors नहीं होगी।

उदाहरण:

इस लाइन का उपयोग करने के बाद यह एक पोस्ट है:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce gravida eros ut leo commodo luctus. Nulla neque dui, laoreet quis felis in, porta tincidunt felis. Phasellus in lacus et sem condimentum ornare. Praesent vitae nisi tempus, gravida tortor eu, convallis dui. Cras lacinia posuere scelerisque. Vestibulum tincidunt purus id sollicitudin varius. Sed eros urna, mattis nec nunc eu, finibus suscipit ipsum. Aliquam varius faucibus congue. Vivamus convallis imperdiet sem a commodo. Proin cursus feugiat sem a pharetra. Curabitur rhoncus non quam sit amet lacinia. Sed ut nisl id odio faucibus vehicula vel ut erat. Vestibulum ut iaculis magna. Quisque sit amet massa sodales, suscipit nisl eu, dapibus elit. Morbi posuere ligula pretium commodo semper. Nam odio elit, rutrum finibus tortor eget, viverra viverra metus. Proin tincidunt tempor ex pretium rhoncus. Proin egestas erat sed eros congue, mollis gravida magna bibendum. Pellentesque vel bibendum nunc. Orci varius natoque penatibus et magnis dis viverra fusce.

विवरण फ़ील्ड में। सटीक होने के लिए 1024 बाइट्स।

इसके बजाय, अगर मैं सिर्फ कुछ और डमी डेटा के साथ फ़ील्ड भरता हूं लेकिन कुछ भी पागल नहीं है:

यदि मैं सत्र ड्राइवर को फ़ाइल में बदलता हूं:

... यह काम करता हैं।

लेकिन यह मेरी समस्या को ठीक नहीं करता है। मुझे सत्र के लिए कुकी ड्राइवर का उपयोग करने की आवश्यकता है क्योंकि उच्च उपलब्धता प्राप्त करने के लिए उत्पादन वेबसाइट 3 अलग-अलग डेटासेंटर में चल रही है। सत्र के लिए कुकी का उपयोग करने से उपयोगकर्ता को 3 सर्वरों में से किसी एक को हिट करने की अनुमति मिलती है और फिर भी किसी भी चिपचिपा सत्र या किसी केंद्रीय सत्र ड्राइवर का उपयोग किए बिना इसके अनुरोध के साथ जारी रहता है।

डेटाबेस के रूप में डेटाबेस का उपयोग करना-जो एचए के साथ क्लस्टर में भी है- यह विकल्प नहीं है क्योंकि यह वास्तव में एक उच्च ट्रैफिक वेबसाइट है और यह प्रति अनुरोध लिखना होगा जो बिल्कुल आकर्षक नहीं है। मैं इसे किसी भी कीमत पर रोकना चाहता हूं।

वैसे भी हल किया जा सकता है?

मुझे कहना होगा कि यह वेबसाइट का बैक ऑफिस है, लेकिन जल्द ही उपयोगकर्ता फ्रंटएंड में 1024 से अधिक अक्षरों को भी लिखने में सक्षम होगा ... इसलिए यदि मैं बैकऑफिस के लिए ड्राइवर को बदलता हूं तो मदद नहीं करता है हम अपने उपयोगकर्ताओं के लिए भी इसमें भाग लेंगे।

https://code.i-harness.com


ब्राउज़र में कुकी की सीमा है। जब आप cookie ड्राइवर के रूप में cookie उपयोग करते हैं तो ब्राउज़र को कुकी स्टोर करने के लिए यह बहुत बड़ा होता है। आप ब्राउजर कुकी सीमा को यहां देख सकते हैं http://browsercookielimits.squawky.net/

सिफारिश :
सत्र चालक के रूप में redis प्रयोग करें।

कदम :
1. स्थापित Redis सर्वर के बाद, predis/predis पैकेज जोड़ें:

composer require predis/predis

2. अपनी कॉन्फ़िगरेशन फ़ाइल config/database.php डेटाबेस.एचपी बदलें:

'redis' => [

    'client' => 'predis',

    'default' => [
        'host' => env('REDIS_HOST', 'localhost'),
        'password' => env('REDIS_PASSWORD', null),
        'port' => env('REDIS_PORT', 6379),
        'database' => 0,
    ],

],

कुकी सत्र ड्राइवर उन अनुप्रयोगों के लिए उपयुक्त नहीं है जिन्हें उपयोगकर्ता के सत्र में किसी भी महत्वपूर्ण मात्रा में डेटा स्टोर करना होगा। ब्राउज़र आमतौर पर एक कुकी में संग्रहीत डेटा को लगभग 4 KB (4096 बाइट्स) तक सीमित करते हैं। जैसा कि हमने पाया, हम सत्र कुकी में 1024-वर्ण-लंबी स्ट्रिंग को स्टोर करने का प्रयास करके आसानी से इस क्षमता को समाप्त कर सकते हैं- प्रश्न में "Lorem ipsum ..." स्ट्रिंग में केवल ASCII वर्ण होते हैं, और प्रत्येक ASCII वर्ण का उपयोग करके दर्शाया जाता है 4 बाइट्स, तो 1024 × 4 = 40 9 6 बाइट्स।

जैसा कि हम देख सकते हैं, जब हम एक सत्र कुकी में अतिरिक्त आइटम स्टोर करने की आवश्यकता होती है, तो हम जल्दी से अंतरिक्ष से बाहर निकलना शुरू करते हैं, जैसे PHP मानों के लिए क्रमबद्धता मेटाडेटा, या जब डेटा में यूटीएफ -8 वर्ण होते हैं जो प्रति 4 से अधिक बाइट्स का उपभोग करते हैं चरित्र। 4 KB से अधिक सत्र डेटा संग्रहीत करने के लिए कुकीज़ का उपयोग जारी रखने के लिए, हमें एक कस्टम सत्र ड्राइवर लिखना होगा जो विभाजन के सत्र डेटा को प्रत्येक प्रतिक्रिया के लिए एकाधिक कुकीज में विभाजित करता है और फिर प्रत्येक अनुरोध पर उन्हें फिर से इकट्ठा करता है। अच्छे कारण के लिए, कोई मौजूदा पैकेज ऐसा नहीं करता है जिसे मैं जानता हूं। इसके साथ अब अगली बात पर चलते हैं...

मैं एक पूर्ण सत्र (केवल एक सत्र आईडी के बजाय) स्टोर करने के लिए कुकीज़ के उपयोग को दृढ़ता से हतोत्साहित करना चाहता हूं। यह दृष्टिकोण सुरक्षा भेद्यता का पर्दाफाश कर सकता है, अनुरोधों और प्रतिक्रियाओं (उसी डोमेन पर स्थैतिक परिसंपत्तियों के अनुरोध सहित) के लिए ओवरहेड जोड़ता है, डेटा को डिस्क्रॉन्गनाइज़ करने का जोखिम (ऐप टैब पर राइट-क्लिक करें → खुशियों को देखने के लिए डुप्लिकेट ), परीक्षण और डिबगिंग को जटिल बनाता है, और समस्याएं उत्पन्न करता है कुछ प्रकार के डेटा भंडारण करते समय।

प्रश्न में वितरित आवेदन के लिए, हमारे पास चार विकल्प हैं:

  1. प्रत्येक एप्लिकेशन उदाहरण द्वारा उपयोग किए गए केंद्रीय सर्वर पर सत्र डेटा स्टोर करें
  2. प्रत्येक साइट पर सत्र स्थिति स्टोर करें, और साइटों के बीच इसे दोहराएं
  3. एक सत्र शुरू करने के बाद उपयोगकर्ता को एक साइट पर एंकर करने के लिए "चिपचिपा" सत्र का उपयोग करें
  4. कस्टम सत्र ड्राइवर को लागू करने के लिए कोड की एक गैर-मामूली राशि लिखें जो क्लाइंट को कुकीज का उपयोग किए बिना सत्र स्थिति पास करने की अनुमति देता है, या एक विभाजन कुकीज़

मुझे लगता है कि हम चौथे विकल्प को उचित रूप से खत्म कर सकते हैं। जब तक कि हमारे पास पहले तीन दृष्टिकोणों का उपयोग करने से बचने के लिए बहुत अच्छा कारण नहीं है, और सामान्य अनुप्रयोगों के लिए हम आम तौर पर नहीं करते हैं, हम पूरे समय सत्र डेटा को स्थानांतरित करने के लिए सिस्टम बनाने के लिए आवश्यक कार्य, जटिलता और ओवरहेड की मात्रा को उचित नहीं ठहरा सकते HTTP जब पहले तीन विकल्प मानक, व्यापक रूप से स्वीकार्य समाधान हैं।

प्रश्न में दी गई जानकारी के आधार पर, यह मुझे लगता है जैसे आप पहले से ही अन्य तीन विकल्पों के पीछे अवधारणाओं और प्रभावों को समझते हैं, इसलिए मैं प्रत्येक के लिए स्पष्टीकरण पर विस्तार नहीं करूंगा (लेकिन अगर मुझे करना चाहिए तो मुझे बताने के लिए टिप्पणी करें)।

उन्नत बुनियादी ढांचे आवश्यकताओं के बिना अनुप्रयोगों के लिए, मैं तीसरे दृष्टिकोण की सिफारिश करता हूं: चिपचिपा सत्र । ये सेट अप करने के लिए अपेक्षाकृत आसान हैं और आमतौर पर लोड बैलेंसर पर कॉन्फ़िगरेशन की आवश्यकता होती है ताकि एक बार ग्राहक एक सर्वर सर्वर के साथ सत्र शुरू कर लेता है, तो लोड बैलेंसर सत्र समाप्त होने तक उसी सर्वर पर किसी भी अनुरोध को रूट करता है। उच्च उपलब्धता के लिए, हम इस दृष्टिकोण को Redis सत्र ड्राइवर और डेटासेंटर के बीच मास्टर-गुलाम प्रतिकृति के लिए कॉन्फ़िगर किए गए Redis सर्वर, और वैकल्पिक रूप से, विफलता स्वचालित करने के लिए Redis Sentinel के साथ कॉन्फ़िगर कर सकते हैं। Redis सत्र डेटा अच्छी तरह से सूट और एक संबंधपरक डेटाबेस से बेहतर प्रदर्शन प्रदान करता है। यदि हमारे पास प्रत्येक डेटा सेंटर पर एकाधिक एप्लिकेशन उदाहरण हैं, तो Redis एक साइट पर सभी उदाहरणों के लिए सत्र डेटा के लिए एक केंद्रीय स्थान प्रदान करता है।

पूर्णता के लिए, और सीधे प्रश्न का उत्तर देने के लिए, यहां एक कुकी-आधारित सत्र ड्राइवर बनाने के लिए आवश्यक विकास के लिए एक सिंहावलोकन है जो 4 KB से अधिक सत्र डेटा को संभालता है। फिर, मैं ऊपर वर्णित अन्य दृष्टिकोणों में से एक की सिफारिश करता हूं:

  • सबसे पहले, हमें एक नई कक्षा बनाने की आवश्यकता होगी जो PHP के सत्र हैंडलर SessionHandlerInterface लागू करता है (प्रारंभिक बिंदु के लिए लैरवेल के कुकी सत्र हैंडलर को SessionHandlerInterface हम शायद इस कक्षा को बढ़ा सकते हैं)।

  • इस कक्षा के write() विधि को सत्र $data को क्रमबद्ध करने की आवश्यकता होगी और फिर डेटा को 4 केबी से कम भाग में विभाजित करने की आवश्यकता होगी (कुछ ब्राउज़रों के लिए, 40 9 3 बाइट कम)। मल्टीबाइट वर्णों के लिए जिम्मेदार होना सुनिश्चित करें। डेटा को विभाजित करने से पहले, यदि सत्र में संवेदनशील जानकारी हो या हम चालाक उपयोगकर्ताओं को मूल्यों के साथ गड़बड़ नहीं करना चाहते हैं तो हम इसे एन्क्रिप्ट करना भी चाहेंगे। फिर, विधि डेटा सत्र के प्रत्येक खंड के लिए विधि को एक नई कुकी जोड़नी चाहिए। प्रत्येक कुकी को अनुक्रम को इसके नाम में रखना होगा, और हम एक अतिरिक्त कुकी जोड़ सकते हैं जिसमें भाग की संख्या शामिल है।

  • read() विधि इन परिचालनों को विपरीत में निष्पादित करेगी। सबसे पहले, कुकी के मूल्य का उपयोग करके अनुरोध में कुकीज़ से प्रत्येक खंड को फिर से इकट्ठा किया जाएगा जिसमें भाग की संख्या होती है, और फिर, वैकल्पिक रूप से, डेटा को डिक्रिप्ट करते हैं, अगर हमने इसे एन्क्रिप्ट किया है।

  • destroy() विधि को प्रत्येक कुकी की सामग्री को साफ़ करना चाहिए जिसमें एक हिस्सा शामिल है।

  • फिर हम सत्र चालक के लिए एक नाम चुनेंगे, जैसे कि cookie-extended , और, सेवा प्रदाता की boot() विधि में, इसे एक उपलब्ध ड्राइवर के रूप में पंजीकृत करें:

    Session::extend('cookie-extended', ...);
    

    उपयोगकर्ता सत्रों के लिए नए ड्राइवर का उपयोग करने के लिए, हमें कॉन्फ़िगर / session.php या .env में एप्लिकेशन को निर्देश देना होगा।

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

एक अंतिम नोट के रूप में, डेटाबेस में सत्र संग्रहीत करने से आप जितना सोचते हैं उतना प्रदर्शन प्रभावित नहीं कर सकते हैं। एक वास्तविक समस्या नहीं हो सकती है कि चिंता के लिए कई घंटों का अनुकूलन करने से पहले इस सरल समाधान द्वारा बनाए गए वास्तविक भार को मापने के लायक हो सकता है।