【正文】 ript，效果就是這樣)。還好，彌補的辦法很簡單：只要在選購物品之后把包含flash信息的div隱藏起來即可。不過，沒有什么事情會真的那么簡單。page[:notice].hide rest as before...可是這不管用。當我們首次進入在線商店時，flash中什么都沒有，所以id叫notice的這個div也不會顯示出來：由于沒有這么一個div，RJS模板生成的JavaScript在嘗試隱藏這個div時就會出錯，剩下的腳本就不會運行了。結(jié)果是，我們將再也無法看到邊欄中的購物車被更新。最終的解決方案有些類似于hack：只有當這個div存在時。但RJS并沒有提供這種“檢查div是否存在”的功能。不過，它允許我們遍歷頁面上所有與指定的CSS selector模式匹配的元素，所以我們不妨遍歷所有id為notice的div標記。在遍歷的過程中我們可能找到一個元素，并會把它隱藏起來；也可能一個元素都找不到，此時就不會調(diào)用hide方法。depot_p/app/views/store/→ (39。divnotice39。 ).each { |div| }page[:cart].replace_html :partial = 39。cart39。 , :object = @cartpage[:cart].visual_effect :blind_down if @ == 1page[:current_item].visual_effect :highlight, :startcolor = 88ff88 , :endcolor = 114411客戶感到很滿意。我們已經(jīng)實現(xiàn)了貨品維護、基本的列表頁面、購物車，現(xiàn)在又有了一個簡單的訂單系統(tǒng)。顯然我們還必須提供某種發(fā)貨功能，不過這可以等到下一個迭代。 (本書將不再介紹那個迭代，因為其中沒有包含更多關(guān)于Rails的新東西。)我們做了什么What We Just Did時間不長，我們已經(jīng)干了不少事：l 我們新建了orders和line_items兩張表(以及對應的模型類)，并將它們連接起來。l 我們創(chuàng)建了一張表單，用于搜集訂單詳細信息，并將其與Order模型類關(guān)聯(lián)起來。l 我們添加了數(shù)據(jù)校驗，并利用輔助方法將錯誤信息回顯給用戶。游戲時間Playtime下面的東西，不妨自己動手試試。l 跟蹤購買流程，查看 save_order、add_line_items_from_cart和from_cart_item等方法。控制器、Order模型以及LineItem模型是否良好地解耦合了？(要回答這一問題，請考慮潛在的變更需求——如果修改某些東西，例如給購物車條目新增一個字段，是否會影響其他地方的代碼？)你能找到更好的辦法來減少耦合嗎？l 如果付賬頁面已經(jīng)顯示出來，而你又點擊了邊欄上的“Checkout”按鈕，會發(fā)生什么？能否想個辦法在這種情況下禁用這個按鈕？(提示：在控制器中設(shè)置的變量不僅可以在直接渲染的視圖模板中可以訪問，在布局模板和局部模板中同樣可以訪問。)l 各種支付類型目前以常量的形式保存在Order類中，你能把它們移到數(shù)據(jù)庫中嗎？遷移之后能否繼續(xù)保持數(shù)據(jù)校驗工作如常？(更多提示請看。)在本章中，我們將看到如何：● 為模型對象添加虛擬屬性 ● 更多的數(shù)據(jù)棱驗● 不對應于模型對象的表單 ● 用一個action完成對表單的所有處理● 在session中保存身份認證信息 ● 使用script/console● 使用數(shù)據(jù)庫事務 ● 編寫ActiveRecord鉤子第11章 任務F：管理Task F: Administration客戶非常開心，在很短的時間里，我們一起完成了基本的購物車功能，她已經(jīng)可以把這些展示給顧客看。不過，她還希望做一點修改：目前，任何人都可以訪問后臺管理功能，她希望再加上一個基本的用戶管理系統(tǒng)，當進入站點管理功能時要求用戶先登錄。我們也很樂意做這件事，因為這讓我們有機會嘗試一下虛擬屬性和過濾器，而且還讓我們有機會進一步完善應用程序。與客戶交流之后，我們認為并不需要給應用程序加上一個特別復雜的安全系統(tǒng)，只需要根據(jù)用戶名和密碼識別用戶即可。只要通過用戶識別，該用戶就可以使用所有的管理功能。 迭代F1：添加用戶Iteration F1:Adding Users 我們先來創(chuàng)建一張簡單的數(shù)據(jù)庫表，用于保存用戶名和經(jīng)過加密的密碼，以便管理之用。我們不能直接以明文形式保存密碼，而是要首先對其進行SHA1加密，然后保存一個160位的散列碼。當用戶再次登錄時，我們會對他輸入的密碼做同樣的加密處理，并將加密的結(jié)果與數(shù)據(jù)庫中保存的散列碼進行比較。為了讓系統(tǒng)更加安全，我們還對密碼做了salt處理：當生成散列值時將密碼與一個偽隨機字符串組合之后再生成散列碼。 如果讀者想知道實現(xiàn)這一策略的其他做法，請參閱Chad Fowler 的著作Rails Recipes [Fow06]中的“身份認證”（Authentication)與“基于角色的授權(quán)”（RoleBased Authentication)兩個章節(jié)。depot ruby script/generate scaffold \ user name:string hashed_password:string salt:string由于修改了config/(性能原因作了緩存)，所以需要重啟服務。完成后我們來看看生成的遷移任務。depot_p/db/migrate/class CreateUsers ActiveRecord::Migration def create_table :users do |t| :name :hashed_password :salt end end def drop_table :users endend和以往一樣，運行這個遷移任務。depotrake db:migrate下面該輪到User模型類粉墨登場了。乍一看這事似乎挺麻煩，因為從應用程序的角度來說，User類只能得到明文的密碼：而在數(shù)據(jù)庫這邊，保存下來的卻是salt值與密碼散列值。我們還是一步步來吧，首先看看數(shù)據(jù)校驗的部分。depot_p/app/models/class User ActiveRecord::Base validates_presence_of :name validates_uniqueness_of :name attr_accessor :password_confirmation validates_confirmation_of :password validate :password_non_blank private def password_non_blank (:password, Missing password ) if ？ endend這么一個簡單的模型類，里面的校驗規(guī)則可真不少。我們首先檢查用戶名不能為空，并且要求用戶名是全局唯一的(也就是說，不允許數(shù)據(jù)庫中有兩個用戶起同一個用戶名)。隨后是一句神秘的validates_confirmation_of聲明。你肯定用過這樣的表單：你要首先輸入一遍密碼，然后在另一個輸入框中再輸入一遍密碼，以確保你所輸入的正是你想輸入的?，F(xiàn)在好了，Rails可以自動地校驗這兩遍輸入的密碼是否相同。馬上我們就會看到這是如何發(fā)生的，現(xiàn)在只須知道：表單里有兩個密碼輸入框，其中一個是真正的密碼，另一個則用來確認密碼輸入正確。最后，我們用一個校驗鉤子來檢查密碼已經(jīng)被設(shè)上了值，但我們不會直接檢查password屬性。為什么？因為這個屬性并不真的存在——至少不存在于數(shù)據(jù)庫里。所以我們需要檢查它的替身——也就是經(jīng)過散列加密的密碼——存在。為了充分理解其中的奧妙，我們必須首先明白如何保存密碼。第一個問題是如何得到密碼的散列值的。這里的關(guān)鍵在于生成一個唯一的salt值，將其與密碼明文組合成為一個字符串，然后對這個字符串進行SHA1加密，得到一個40字符的字符串(其中的內(nèi)容是一個十六進制數(shù))。我們把這一邏輯寫在一個私有的類方法中。(此外還必須引用digest/sha1庫，參見第151頁的代碼列表。)depot_p/app/models/def (password, salt) string_to_hash = password + wibble + salt Digest::(string_to_hash)end將一個隨機數(shù)與對象ID組合起來，就得到了我們需要的salt字符串——salt值是什么并不重要，只要它是無法預測的就行(譬如說，用時間作為salt值的熵* 譯者注：即“混亂度”或者“不可預測性”就不如用隨機字符串來得高)。最后，把這個salt值放進模型對象的salt屬性中。再提醒一遍，這是一個私有方法，所以請把它放在private關(guān)鍵字的后面。depot_p/app/models/def create_new_salt = + end代碼里出現(xiàn)了一點新鮮東西：=...，以強制調(diào)用salt=方法——準確地說是“調(diào)用當前對象的salt=方法”。，Ruby會認為我們正在給一個局部變量賦值，那我們的代碼就沒有效果了 雖然直接使用實例變量也能夠得到正確的結(jié)果，但這回把你綁到某個表現(xiàn)形式上，你可能并不會總想這樣。salt/salt=是隱含屬性的“官方”接口，所以最好使用它們，而不是實例變量。從另一個角度來說，屬性形式是類的公共接口的一部分，應該使用它來存取數(shù)據(jù)。如果使用在內(nèi)部使用@xxx，而在外部使用xxx，那么很容易造成類型不匹配。 。我們還需要寫一點代碼，確保每當明文密碼被放進User對象時，都會自動生成加密后的散列碼(后者將被存入數(shù)據(jù)庫)。為此，我們將把“明文密碼”變成模型中的一個虛擬屬性(virtual attribute)——它從應用程序的角度看上去像是個屬性，但卻不會被存入數(shù)據(jù)庫。如果不是需要生成散列碼，那么只要使用Ruby提供的attr_accessor聲明就行了。attr_accessor :passwordattr_accessor會在幕后生成兩個屬性訪問方法：一個名叫password的讀方法，以及一個名叫password=的寫方法——寫方法的名稱以等號結(jié)尾，意味著它是可以被賦值的。我們不打算使用標準的訪問方法，而是自己動手來實現(xiàn)訪問方法，在寫方法中生成一個新的salt值，然后用它來生成密碼散列值。depot_p/app/models/def password @passwordenddef password=(pwd) @password = pwd return if ？ create_new_salt = (, )end還有最后一件事：如果用戶提供了正確的用戶名和密碼，我們需要用公有的類方法來返回一個User對象。由于用戶輸入的密碼是明文，所以我們必須根據(jù)用戶名取出數(shù)據(jù)庫中的記錄，然后根據(jù)記錄中的salt值再對密碼做一次散列處理；如果密碼散列值與數(shù)據(jù)庫中保存的值匹配，則返回User對象?，F(xiàn)在我們就可以用這個方法來驗證用戶身份了。depot_p/app/models/def (name, password) user = (name) if user expected_password = encrypted_password(password, ) if != expected_password user = nil end end userend這段代碼還使用了一個ActiveRecord小花招：方法的第一行調(diào)用了find_by_name方法，但你哪兒都找不到這么一個代碼。不過別擔心，ActiveRecord會注意到我們調(diào)用了一個未經(jīng)定義的方法，并且該方法的名字以find_by開頭、以一個字段名結(jié)尾，所以它會自動幫我們創(chuàng)建一個查找方法，并將其添加到模型類上。在第306頁我們還會深入討論這類動態(tài)查找方法。User模型類的代碼確實不少，不過這也向我們展示了如何在模型類中包含業(yè)務邏輯。在回頭關(guān)注控制器之前，再來看看完整的模型類代碼吧depot_p/app/models/require 39。digest/sha139。class User ActiveRecord::Base validates_presence_of :name validates_uniqueness_of :name attr_accessor :password_confirmation validates_confirmation_of :password validate :password_non_blank def (name, password) user = (name) if user expected_password = encrypted_password(password, )