Magento與幾乎所有其他基於PHP的框架沒有區別,因爲它具有串行執行流程。從請求流的角度來看,一個入口點來表達你的需求將是處理登錄表單POST的類。你可以在rendered source in your browser:action="https://demo.magentocommerce.com/customer/account/loginPost/"
中看到。
上述URI解析爲方法Mage_Customer_AccountController::loginPostAction()
。在那裏可以找到登錄控制器操作的典型登錄邏輯:用戶是否登錄?用戶是否在登錄數據中發帖?登錄數據是否有效?等等。這很快指向客戶會話模型Mage_Customer_Model_Session
,特別是authenticate()
方法。在這個方法中,調用Mage_Customer_Model_Customer->loadByEmail()
,它使我們得到Mage_Customer_Model_Entity_Model-> loadByEmail()`。
此時,我們知道我們可以重寫資源模型並更改其loadByEmail()
以處理查找輔助電子郵件方法(雜亂&令人發狂)。我們還可以重寫和更改Mage_Customer_Model_Session->authenticate()
,提供一些預處理功能,以便首先通過輔助電子郵件加載客戶記錄,然後提取主電子郵件並允許正常進行。
//rewritten authenticate method
public function authenticate($username,$password) {
$customer = Mage::getResourceModel('customer/customer_collection')
->addAttributeToFilter('secondary_email',$username)
->getFirstItem();
//check we found customer record by secondary email
if ($customer->getId()) {
parent::authenticate($login,$customer->getEmail());
}
else {
parent::authenticate($username,$password)
}
}
我不是真的看着上面的代碼中,我也不會保證其安全性,但希望這表明了過程,其中一個可以回答這些類型的使用框架的認識問題。這可能不是一個不好的起點;在配置的類重寫中加入一個類似的設置腳本來添加secondary_email
屬性,這應該很快實現。
的注意事項值得一提:
它也可以通過觀察運行時構建的controller_action_predispatch_customer_account_loginpost
事件(見Mage_Core_Controller_Varien_Action::preDispatch()
)做到這一點。雖然通常建議儘可能使用事件觀察系統來實現功能重寫,但這將是相當不直觀的,也是最麻煩的選項。