🏕️ 🧑🏻‍🤝‍🧑🏻 🛂 Yii1 / yii2 प्रमाणीकरण साझा करना 🚲 👏 🚶🏿

यह लेख पहले भाग के बिना समझ में नहीं आता है, जिसमें एक उत्तर है "ऐसा क्यों करें।"

यह yii1 से yii2 तक एक परियोजना को सुचारू रूप से स्थानांतरित करने की तकनीक के बारे में है। इसका सार यह है कि yii1 पर प्रोजेक्ट की शाखाएँ और yii2 पर इसका नया संस्करण एक ही होस्ट में एक ही डोमेन पर एक साथ काम करते हैं, और माइग्रेशन को धीरे-धीरे, छोटे चरणों में (पृष्ठों, नियंत्रकों, मॉड्यूल, आदि के माध्यम से) किया जाता है।

पहला भाग मौजूदा वर्चुअल होस्ट में yii2 पर एक नंगे प्रोजेक्ट को चलाने के तरीके के बारे में था, अर्थात। एक दूसरे के साथ हस्तक्षेप किए बिना दोनों शाखाएं एक साथ काम करें।

उसके बाद सबसे मनोवैज्ञानिक रूप से कठिन चरण शुरू होता है: आपको शुरुआत के लिए एक न्यूनतम बुनियादी ढांचा बनाने की आवश्यकता है। मैं 2 कार्यों को एकल करूंगा: डुप्लिकेट डिज़ाइन और एंड-टू-एंड उपयोगकर्ता प्रमाणीकरण।

बोरिंग द्वारा डिजाइन की नकल को पहला स्थान दिया गया है। यदि आप अशुभ हैं, तो आप पुराने "1 में 1" को कॉपी / रिवर्ट कर सकते हैं। व्यक्तिगत रूप से, मैंने हमेशा रिडिजाइन के साथ संयोजन किया। यानी इंटरफ़ेस और डिज़ाइन को काफी अपडेट किया गया है और इस संबंध में, काम बेवकूफ नहीं है। लेकिन यहां प्रत्येक अपने स्वयं के लिए - मैं इंटरफ़ेस और डिज़ाइन पर बहुत ध्यान देता हूं, कोई, इसके विपरीत, बैकएंड और कंसोल को अधिक पसंद करता है। फिर भी, वरीयताओं की परवाह किए बिना, इस कार्य को पूरा करने का कोई तरीका नहीं है - आपको एक इंटरफ़ेस बनाना होगा, और काम की मात्रा काफी बड़ी होगी।

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

यदि यह आपका मामला है, तो कटौती के तहत अधिक विवरण

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

Yii1 / yii2 का प्रमाणीकरण तंत्र थोड़ा अलग है और आपको yii2 कोड को ट्विक करने की आवश्यकता है ताकि यह एक प्रामाणिक उपयोगकर्ता को देख सके। क्योंकि प्रमाणीकरण डेटा सत्र में संग्रहीत किया जाता है, आपको बस सत्र डेटा पढ़ने के लिए मापदंडों पर सहमत होना होगा।

Yii1 से एक सत्र में, इसे किसी तरह संग्रहीत किया जाता है:

print_r($_SESSION); Array ( [34e60d27092d90364d1807021107e5a3__id] => 123456 [34e60d27092d90364d1807021107e5a3__name] => tester [34e60d27092d90364d1807021107e5a3__states] => Array ( ) )

यह आपके साथ कैसे संग्रहीत किया जाता है - चेक करें, उदाहरण के लिए, prefixKey अलग तरीके से yii1 के विभिन्न संस्करणों में उत्पन्न होता है।

यहाँ डेटा है जो आपको yii1 से चाहिए

 Yii::app()->user->getStateKeyPrefix() Yii::app()->name Yii::app()->getBasePath() Yii::app()->getId() get_class(Yii::app()->user)

सबसे आसान तरीका एक परीक्षण पृष्ठ बनाना है और उस पर सभी आवश्यक डेटा दिखाना है - भविष्य में उनकी आवश्यकता होगी।

Yii2 में प्रमाणीकरण

Yii2 में, हमारे द्वारा आवश्यक सभी कार्यक्षमता उपयोगकर्ता घटक ( \ yii \ web \ उपयोगकर्ता ) में स्थित है, जो प्रमाणीकरण स्थिति को नियंत्रित करती है।

इसके getIdentity () मेथड में, renewAuthStatus () कहा जाता है, जिसमें प्रमाणीकरण सत्र $ idParam चर से कुंजी द्वारा देखा जाता है (डिफ़ॉल्ट रूप से '__id' वहां संग्रहीत होता है);
सत्र चर में, उपयोगकर्ता आईडी कुंजी $ idParam (उदाहरण के लिए, ऐप / मॉडल / उपयोगकर्ता से ) का उपयोग करके संग्रहीत की जाती है।

आधिकारिक एल्गोरिथ्म में प्रमाणीकरण एल्गोरिथ्म का विस्तार से वर्णन किया गया है।

बेशक, yii1 में, सत्र एक अलग कुंजी के साथ संग्रहीत किए जाते हैं। इसलिए, आपको उसी कुंजी का उपयोग करके उपयोगकर्ता आईडी के लिए yii2 बनाने की आवश्यकता है जिसके साथ यह yii1 में संग्रहीत है।

ऐसा करने के लिए:

1. yi / web / user in config / web.php से विरासत में मिली प्रमाणीकरण स्थिति के प्रबंधन के लिए जिम्मेदार उपयोगकर्ता घटक के वर्ग को बदलें।

 'components' => [ 'user' => [ 'class' => 'app\models\WebUser', 'identityClass' => 'app\models\User', ], ]

2. app \ मॉडल \ WebUser में $ idParam के मूल्य को समायोजित करें।

 public function init() { //  idParam (    //    ) $this->idParam = $this->getIdParamYii1(); }

स्पॉइलर के तहत कुछ तरीके होंगे जो किसी भी तरह yii1 से समान व्यवहार का अनुकरण करेंगे।

सामान्य तौर पर, आप मूल ykey1 से मूल _keyPrefix (या यहाँ तक कि idParam ) को कॉपी कर सकते हैं और इसकी पीढ़ी का अनुकरण नहीं कर सकते हैं, लेकिन फिर यह निर्देश "नकल योग्य कचरा" की तरह होगा।

वास्तव में, आप कॉपी कर सकते हैं क्योंकि ykey1 में _keyPrefix लगभग स्थिर है। यह उपयोगकर्ता घटक के वर्ग नाम और एप्लिकेशन आईडी पर निर्भर करता है, जो बदले में आवेदन के स्थान और उसके नाम से प्राप्त होता है।

 //   yii1  _keyPrefix $this->_keyPrefix = md5('Yii.'.get_class($this).'.'.Yii::app()->getId()); //   - ID  $this->_id=sprintf('%x',crc32($this->getBasePath().$this->name));

अगर हम खुद को केवल प्रमाणीकरण कार्य तक ही सीमित रखते हैं, तो _keyPrefix मूल्य की प्रतिलिपि बनाने से काम की मात्रा में काफी कमी आती है। लेकिन मेरे पास व्यापक उपयोग के लिए उदाहरण होंगे।

उपयोगकर्ता घटक (एप्लिकेशन \ मॉडल \ WebUser)

 namespace app\models; use yii\web\User; class WebUser extends User { /** *    cookies  yii2, *     yii1 */ public $autoRenewCookie = false; /** * _keyPrefix    CWebUser  Yii1 */ private $_keyPrefix; /** *    Yii1,    */ private $paramsYii1 = [ //    user   Yii1 'classUserComponent' => 'CWebUser', // ID  Yii1 //  ,  Yii::app()->getId() 'appId' => '', //     Yii1 'appName' => 'My Web Application', //     yii1  \Yii::getAlias('@app') 'relPath' => '../htdocs/protected', ]; public function init() { //  idParam (    //    ) $this->idParam = $this->getIdParamYii1(); } }

और इसके अतिरिक्त तरीके (वेबउज़र)। आसान देखने के लिए अलग।

 /** *     Yii1,    ID  */ public function getIdParamYii1() { return $this->getStateKeyPrefix() . '__id'; } /** *    Yii 1 * @return string */ public function getStateKeyPrefix() { if ($this->_keyPrefix !== null) return $this->_keyPrefix; $class = $this->paramsYii1['classUserComponent']; return $this->_keyPrefix = md5('Yii.' . $class . '.' . $this->getAppIdYii1()); } /** *   getId()  CApplication * @return string ID  Yii1 */ public function getAppIdYii1() { if ($this->paramsYii1['appId']) return $this->paramsYii1['appId']; return $this->paramsYii1['appId'] = sprintf('%x', crc32($this->getBasePathYii1() . $this->paramsYii1['appName'])); } /** * @return string    Yii1 */ private function getBasePathYii1() { $basePath = realpath(\Yii::getAlias('@app') . DIRECTORY_SEPARATOR . $this->paramsYii1['relPath']); if (!$basePath) throw new InvalidConfigException('basePath  yii1  .'); return $basePath; }

केवल " सत्र कुंजी के प्रारूप पर सहमति " के कार्य के लिए विधियों का अपघटन थोड़ा जटिल है, लेकिन वे नीचे दिए गए उदाहरणों के लिए उपयोगी हैं।

उसके बाद, yii2 पर एक नई शाखा में, पहले से yii1 में अधिकृत उपयोगकर्ताओं की मान्यता काम करना शुरू कर देती है। आदर्श रूप से, इसे रोकना आवश्यक होगा, क्योंकि फिसलन मार्ग आगे शुरू होता है।

Yii2 में उपयोगकर्ता लॉगिन

सत्र में उपयोगकर्ता आईडी के लिए संग्रहण प्रारूप पर सहमति होने के बाद, यह संभव है कि उपयोगकर्ता लॉगिन "स्वचालित रूप से" भी yii2 के माध्यम से काम करेगा।

मैं yii1 पर संबंधित प्रपत्र को अक्षम किए बिना कॉम्बैट मोड में yii2 पर लॉगिन फॉर्म का उपयोग करना गलत मानता हूं, हालांकि, बुनियादी कार्यक्षमता थोड़ा समन्वय के बाद काम करेगी।

क्योंकि हम मानते हैं कि उपयोगकर्ता पंजीकरण, और तदनुसार पासवर्ड हैशिंग, yii1 में रहता है, yii2 के माध्यम से काम करने वाले लॉगिन के लिए हमें यह सुनिश्चित करने की आवश्यकता है कि yii2 में सहेजे गए पासवर्ड की सत्यापन विधि समझ सकती है कि क्या हैशेड और Yii1 में संग्रहीत है।

जांच करें कि ये तरीके क्या करते हैं।

उदाहरण के लिए, यदि Yii2 में, सशर्त रूप से मानक उपयोगकर्ता मॉडल उपयोगकर्ता पासवर्ड को निम्नानुसार मान्य करता है:

 public function validatePassword($password) { return \Yii::$app->getSecurity()->validatePassword($password, $this->password); }

उसके बाद, yii \ base \ Security (Yii2) से वैद्युतशब्द ($ पासवर्ड, $ हैश) विधि देखें

सत्यापनकर्ता ()

 public function validatePassword($password, $hash) { if (!is_string($password) || $password === '') { throw new InvalidArgumentException('Password must be a string and cannot be empty.'); } if (!preg_match('/^\$2[axy]\$(\d\d)\$[\.\/0-9A-Za-z]{22}/', $hash, $matches) || $matches[1] < 4 || $matches[1] > 30 ) { throw new InvalidArgumentException('Hash is invalid.'); } if (function_exists('password_verify')) { return password_verify($password, $hash); } $test = crypt($password, $hash); $n = strlen($test); if ($n !== 60) { return false; } return $this->compareString($test, $hash); }

और अगर उपयोगकर्ता मॉडल में Yii1 पासवर्ड हैशिंग पर इस तरह किया जाता है:

 public function hashPassword($password) { return CPasswordHelper::hashPassword($password); }

फिर yii \ Framework \ utils \ CPasswordHelper से VerPassword ($ पासवर्ड, $ हैश) से तुलना करें

hashPassword ()

 public static function hashPassword($password,$cost=13) { self::checkBlowfish(); $salt=self::generateSalt($cost); $hash=crypt($password,$salt); if(!is_string($hash) || (function_exists('mb_strlen') ? mb_strlen($hash, '8bit') : strlen($hash))<32) throw new CException(Yii::t('yii','Internal error while generating hash.')); return $hash; }

यदि हैशिंग और सत्यापन के तरीके अलग-अलग हैं, तो आपको ऐप्पल / मॉडल के उपयोगकर्ता से वैलिडेटपासवर्ड () में सत्यापन को बदलने की आवश्यकता है।

फ्रेमवर्क के नवीनतम संस्करणों के बक्से से, Yii1 / Yii2 पासवर्ड हैश संगत हैं। लेकिन इसका मतलब यह बिल्कुल नहीं है कि वे आपके साथ संगत होंगे या भविष्य में यह मेल खाएंगे। संभावना की एक उच्च डिग्री के साथ, Yii1 में परियोजना के हैशिंग तरीके और Yii2 पर नई परियोजना में मान्यता अलग-अलग होगी।

Yii1 से कुकीज़ पर Yii2 में ऑटोलॉगिन

चूंकि Yii2 पर एक शाखा पहले से ही जानती है कि Yii1 से उपयोगकर्ता प्रमाणीकरण डेटा का पारदर्शी रूप से उपयोग कैसे किया जाता है, क्यों कुकी द्वारा ऑटो-लॉगिन सेट नहीं किया जाता है?

यदि ऐसा विचार आपको परेशान करता है, तो मैं आपको इसे त्यागने की सलाह देता हूं। मुझे उपयोगकर्ता थ्रेड (प्रमाणीकरण, सबसे पहले) को इस थ्रेड में स्थानांतरित किए बिना Yolog2 पर ऑटोलॉगिन को सक्षम करने का कोई अच्छा कारण नहीं दिखता। यानी मेरा मतलब है कि निम्नलिखित मामले:

उपयोगकर्ता प्रमाणीकरण Yii1 पर किया जाता है, लेकिन Yii2 शाखा Yii1 में संग्रहीत कुकीज़ पर ऑटोलॉगिन करने में सक्षम होना चाहिए।

सच कहूं तो, यह एक फ्रॉड विकृति है। यह करना आसान और सुरुचिपूर्ण नहीं होगा, और यहाँ सिर्फ प्रवास के सचेत और न्यायसंगत कार्य और अनावश्यक साइकिल के आविष्कार के बीच की रेखा गुजरती है।

कठिनाई यह है कि दोनों शाखाओं में Yii नकली कुकीज़ से सुरक्षित है, इसलिए तरीकों पर सहमत होना मुश्किल है।

Yii2 में शामिल घटक हैं: उपयोगकर्ता ( \ yii \ web \ उपयोगकर्ता ), अनुरोध , सुरक्षा + कुकीकरण
Yii1 में: CWebUser , CHttpRequest , CSecurityManager , CStatePersister , CCookieCollection

हालांकि, मामले अलग हैं। नीचे एक उदाहरण है कि साइकिल के साथ एक ऑटोलॉग कैसे बनाया जाए।

Yii2 में, हम getIdentityAndDurationFromCookie () मेथड में \ yii \ web \ User से रुचि रखते हैं। इस विधि की पहली पंक्ति में, वांछित कुकी प्राप्त की जानी चाहिए:

 $value = Yii::$app->getRequest()->getCookies()->getValue($this->identityCookie['name']);

लेकिन वह नहीं होगी, क्योंकि संग्रह Yii :: $ ऐप-> getRequest () -> getCookies () खाली हो जाएगा, क्योंकि अनुरोध कुकीज़ में लोडकुकियों () में सत्यापन के साथ लोड किया जाता है और निश्चित रूप से, यह पास नहीं होता है।

GetIdentityAndDurationFromCookie () ओवरराइट करके कांटा का सबसे आसान तरीका मानक व्यवहार है। उदाहरण के लिए, इस तरह:

सुपर कुकी $ _COOKIE से वांछित कुकी को सीधे डाउनलोड करें ताकि मानक कुकी लोडिंग तंत्र के अनुकूल न हो।

पहचान कुकी का नाम सिर्फ _keyPrefix है, जिसे हम पहले से ही जानते हैं कि कैसे प्राप्त करें (या कॉपी किया गया)। इसलिए, हम मानक $ पहचान बदल जाते हैं init () ।
परिणामी कुकी को डिक्रिप्ट करें "लगभग yii1 में।" जैसी आपकी इच्छा। उदाहरण के लिए, मैंने CSecurityManager से आवश्यक विधियों की प्रतिलिपि बनाई।

नीचे, वास्तव में, कोड है।

हम ऐप / मॉडल / वेबउज़र में काम करते हैं

1. नाम पहचान कुकी कुकीज़ yii1 के अनुसार निर्धारित किया है

 public function init() { $this->idParam = $this->getIdParamYii1(); //     $this->identityCookie = ['name' => $this->getStateKeyPrefix()]; }

2. दो और विधियाँ जोड़ें

 /** *    */ protected function getIdentityAndDurationFromCookie() { $id = $this->getIdIdentityFromCookiesYii1(); if (!$id) { return null; } $class = $this->identityClass; $identity = $class::findOne($id); if ($identity !== null) { return ['identity' => $identity, 'duration' => 0]; } return null; } /** *  ID identity  cookies,   yii1 * * @return null|integer  ID     null */ protected function getIdIdentityFromCookiesYii1() { if (!isset($_COOKIE[$this->identityCookie['name']])) return null; $cookieValue = $_COOKIE[$this->identityCookie['name']]; // Cookies  yii1 ,  $utilSecurity = new UtilYii1Security($this->getBasePathYii1()); $data = $utilSecurity->validateData($cookieValue); if ($data === false) { return null; } $data = @unserialize($data); if (is_array($data) && isset($data[0], $data[1], $data[2], $data[3])) { list($id, $name, $duration, $states) = $data; return $id; } return null; }

कोड एक निश्चित UtilYii1Security क्लास का उपयोग करता है - यह CSecurityManager से आवश्यक विधियों का संशोधित कॉपी-पेस्ट है, ताकि एक ओर यह मूल जैसा दिखे , लेकिन सरलीकरण के साथ। उदाहरण के लिए, CSecurityManager में HMAC (हैश-आधारित संदेश प्रमाणीकरण कोड) बनाने के लिए कई विकल्प हैं , जो php संस्करण और mbstring की उपस्थिति पर निर्भर करते हैं। लेकिन कब से यह ज्ञात है कि yii1 समान वातावरण में yii2 के रूप में काम करता है, फिर कार्य सरल हो जाता है और, तदनुसार, कोड भी।

क्योंकि यह बिल्कुल स्पष्ट है कि एक स्पष्ट बैसाखी यहाँ लिखी गई है, फिर इसे सार्वभौमिक बनाने और इसे एक सुंदर आकार देने की कोशिश करने की आवश्यकता नहीं है, यह आपकी शर्तों के तहत इसे "कैद" करने के लिए पर्याप्त है।

UtilYii1Security.php

 <?php namespace app\components; /* *   CSecurityManager  Yii1, *     * */ use yii\base\Exception; use yii\base\Model; use yii\base\InvalidConfigException; class UtilYii1Security { /** * ,   yii1 */ const STATE_VALIDATION_KEY = 'Yii.CSecurityManager.validationkey'; /** *  ,    yii1 */ public $hashAlgorithm = 'sha1'; /** *   cookies */ private $_validationKey; /** *    Yii1 */ private $basePath; /** *      yii1 */ private $stateFile; /** * @param string $basePath -    Yii1 *        stateFile */ public function __construct($basePath) { $this->basePath = $basePath; $this->stateFile = $this->basePath . DIRECTORY_SEPARATOR . 'runtime' . DIRECTORY_SEPARATOR . 'state.bin'; if (!realpath($this->stateFile)) throw new InvalidConfigException('    '); } public function validateData($data, $key = null) { if (!is_string($data)) return false; $len = $this->strlen($this->computeHMAC('test')); if ($this->strlen($data) >= $len) { $hmac = $this->substr($data, 0, $len); $data2 = $this->substr($data, $len, $this->strlen($data)); return $this->compareString($hmac, $this->computeHMAC($data2, $key)) ? $data2 : false; } else return false; } public function computeHMAC($data, $key = null) { if ($key === null) $key = $this->getValidationKey(); return hash_hmac($this->hashAlgorithm, $data, $key); } public function getValidationKey() { if ($this->_validationKey !== null) return $this->_validationKey; if (($key = $this->loadStateValidationKey(self::STATE_VALIDATION_KEY)) !== null) { $this->_validationKey = $key; } return $this->_validationKey; } //  validationKey    Yii1 private function loadStateValidationKey($key) { $content = $this->loadState(); if ($content) { $content = unserialize($content); if (isset($content[$key])) return $content[$key]; } return false; } //      Yii1 protected function loadState() { $filename = $this->stateFile; $file = fopen($filename, "r"); if ($file && flock($file, LOCK_SH)) { $contents = @file_get_contents($filename); flock($file, LOCK_UN); fclose($file); return $contents; } return false; } public function compareString($expected, $actual) { $expected .= "\0"; $actual .= "\0"; $expectedLength = $this->strlen($expected); $actualLength = $this->strlen($actual); $diff = $expectedLength - $actualLength; for ($i = 0; $i < $actualLength; $i++) $diff |= (ord($actual[$i]) ^ ord($expected[$i % $expectedLength])); return $diff === 0; } private function strlen($string) { return mb_strlen($string, '8bit'); } private function substr($string, $start, $length) { return mb_substr($string, $start, $length, '8bit'); } }

कर्मों का अनुक्रम

जब प्रमाणीकरण के संदर्भ में yii1 से yii2 पर माइग्रेट किया जा रहा है, तो मैंने निम्नलिखित अनुक्रम का अनुसरण किया:

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

यदि हाँ, तो यह व्यक्तिगत खाते के कार्यान्वयन (माइग्रेशन) को yii2 (कम से कम आंशिक रूप से) तक ले जाएगा।
यदि "नहीं" है, तो आपको अभी भी अपने व्यक्तिगत खाते के प्रवासन के बारे में सोचना चाहिए (नए उत्पादों के बिना भी)।

पुनश्च:

यह हमेशा एक विशिष्ट कार्य में अस्पष्ट समाधानों का वर्णन नहीं करता है और उन सभी को लागू करने की आवश्यकता नहीं है।

वे कहने के प्रयोजन के लिए वर्णित नहीं हैं "जैसा मैं करता हूं वैसा करो।" उदाहरण के लिए, yii1 से कुकीज़ के लिए yii2 ऑटोलॉगिन बनाना संभव है, लेकिन, इसे हल्के ढंग से डालने के लिए, अच्छा नहीं है (और इस तरह के बैसाखी को किसी तरह से उचित ठहराया जाना चाहिए)।

लेकिन मैंने पहले ही परियोजनाओं के इस चरण-दर-चरण प्रवास पर समय बिताया है और खुशी होगी अगर कोई, मेरे अनुभव को देखकर, उसे बचाता है।

Yii1 / yii2 प्रमाणीकरण साझा करना

Yii2 में प्रमाणीकरण

Yii2 में उपयोगकर्ता लॉगिन

Yii1 से कुकीज़ पर Yii2 में ऑटोलॉगिन

कर्मों का अनुक्रम

पुनश्च:

More articles: