上篇(
專案經驗分享(上))總結了一些瑣碎的小經驗，這篇來講一講在專案中如何解決乙個問題，說它是問題，只是針對我個人來講，因為以前沒有處理過類似的問題，主要是分享下我處理這個問題的過程及方法。
專案技術背景：
1:asp.net mvc 3 專案
2:登入機制是採用membership
3:認證採用forms驗證
4:entityframwork做為資料訪問
問題描述：
當我們的專案部署到租用的美國伺服器上後 (據說是乙個雲服務，說的通俗點可能就是在虛似機上的乙個iis站點)出現了使用者需要頻繁登入的現象，具體來講大約在10分鐘之內就會要求使用者重新登入。
階段一：
問題是客戶發現的，他們在uat時，提到了使用者需要頻繁登入的問題。
我的反應：
由於我提供給大家uat的是乙個公共帳號，大家均使用同一帳號登入，可能會發生不同的人登出同一帳號的現象，可能存在相互的影響，故建議使用者重新啟用乙個全新的帳號。
問題：上面的專案技術背景提到了是採用forms驗證，而我們是採用預設的forms驗證機制，即將資料儲存在客戶端，以cookie的形式，故即使多人使用同一帳號，發生不同使用者登出同一帳戶的現象，也不會影響到其它的使用者的登入狀態。這也是當時沒太注意的地方,沒找出問題本質的情況下，憑經驗下結論。
階段二：
客戶再次反應此問題，而且他們明確了自己使用的帳戶是私人的。
我的反應：
意識到事情的嚴重性，馬上組織測試人員做了仔細的測試，發現問題確實存在，當時就開始著手解決這個問題，畢竟這屬於乙個優先順序最高的問題。
經過和同事討論以及網上搜尋後得到如下方案：
1：在web.config中設定forms的乙個time out
我們原來的配置如下： "
account/logon
" defaulturl=
"account/racetemplate
">
但發現這個值即使不設定，預設時間也有30分鐘，遠大於我們出現問題的10分鐘，但抱著試試看的心情，將之調大到300分鐘，問題依舊。
2：也許和session的設定有關係
我也忘記當時為什麼聯想到session了，也許是我原來的專案都是基於sessio機制的驗證原因吧，但同樣的問題是，session的預設機制也是儲存在程序中,且超時時間為20分鐘，我同樣抱著試試的心情，將這個數值調整到300分鐘，問題依舊。
3：考慮是否和membersip的設定有關係
因為我們登入是採用membership，是否是它有相應的設定，於是開始諮詢同事，結果是，我們的專案是第乙個基於membership的專案，網上搜尋無果。
問題：這是沒有搞清楚forms驗證的機制，錯誤的想法，誤認為和mebership本身有關係。
4：懷疑伺服器提供商的產品會定期**我們站點的應用程式池
這是有依據的，因為我們在自己的本地測試機器上做測試，一點問題都沒有，從不出現頻繁登入的現象。於時讓相關同事發郵件諮詢伺服器提供商，以等待結果。
5：做好伺服器提供商無法給出滿意答案的準備。
如果應用程式池會被定期**，而伺服器提供商無法即時解決被**的問題時，那麼我們嘗試將session存入在資料庫中。畢竟我們不能一直等別人的反饋。
問題：這也是沒有搞清楚forms驗證的機制，錯誤的想法，誤認為和session有關係，好的是，我們當時只有這個想法 ，並沒有著手去做，因為它有如下問題：
1):這是一種逃避問題的方式。
即使儲存在程序中有問題，那麼我們需要找出其中的原因，而不能因為它有問題就想其它的方法，沒有治本。
2):session儲存中資料庫中需要部署很多的資料庫指令碼。
這樣一來是工作量增大，二來對現在的系統會有一定影響。
3):我們租用的資料庫空間很少，只有幾十m，怕影響業務資料的使用。
從技術手段下手
由於伺服器提供商未在短時間內給出正確答案，我開始從技術手段下手，從根本上排查原因。
此次對forms驗證做了比較詳細的了解，排除了session和membership的干擾,講的簡單點forms驗證原理是這樣的：
首先建立乙個使用者的票據，經過相應演算法的加密，最後將票據儲存在cookie中，驗證的過程是首先讀取使用者cookie，如果存在的話，再將票據解密，如果沒有問題即驗證通過。
於時，開始手動編寫登入邏輯，原來是直接呼叫授權**：
formsauthentication.setauthcookie(model.username,
true);
formsauthenticationticket authticket =
new formsauthenticationticket(
1, username, datetime.now, datetime.now.addhours(
20),
true, userrole); //
user data
string encryptedticket = formsauthentication.encrypt(authticket); //
加密//
存入cookie httpcookie authcookie = new httpcookie(formsauthentication.formscookiename, encryptedticket);
authcookie.expires = authticket.expiration;
response.cookies.add(authcookie);
興奮的部署上去之後，仍然是失望而歸。
再次嘗試對讀取cookie做手動編碼：
還是失敗則歸。
最後在網上檢視到，如果應用程式池被**,它會重新分配乙個machinekey,而這個machinekey會影響到cookie票據，它有兩個重要的屬性：
validationkey，
decryptionkey
它和上面說到的對票據資料的加密，解密,驗證問題有直接關係，這裡我就不多講了。如果應用程式池被**，那麼對應的validationkey就會不相同，即與之前的cookie就無法匹配上，這樣就造成了我們需要頻繁登入。
微軟也非常建議在web專案中配置明確的machinekey,理由如下：
1:可以解決站點重啟，或者是應用程式池**造成使用者驗證失敗的現象。
2:如果是負載均衡的站點，那麼他們之間最好也共用同一明確的machinekey。
問題總算找到了，問題也解決了，現在的問題就是應用程式池為什麼會被定期**，這個問題的解釋就不是我們開發組能回答的問題了，我們完成解決了對他們的依賴，即使他們不做解釋不做處理，我們的問題同樣也得到了解決，從而不會影響到使用者體驗以及最終專案上線。
總結：
之所以這樣乙個問題困擾我們這麼些天(大約一周時間)，首要原因是沒有詳細了解forms驗證的機制，這是我做的第乙個forms驗證專案，所以走了些彎路,容易憑經驗被一些其它資訊所干擾。其次是租用伺服器問題，我們對於他的定期**原因，還在排查中，如果不定期**，此問題也不會出現。所以當出現修改預設值不起作用時，請轉換你的思維方式去嘗試從不同角度分析問題。
專案經驗分享
這是我經歷的第二個專案，這個專案相對於第乙個專案dzpay相對較簡單，介紹 第乙個專案名稱 dzpay。大宗商品交易，類似某寶 這次主要總結我測試billbank的一些個人經歷 測試第一要義就是要詳讀產品需求，產品需求中有哪些模組，每個模組中又有哪些子模組，每個模組以及子模組對應的需求點都要搞清楚。...
專案經驗分享
color cyan dh師兄的經驗分享 color color olive 就在公司工作的經驗，針對shopxx專案的交流。color color darkblue 1.乙個專案，要先分出模組來。不要把所有功能都寫在乙個模組裡。如果這樣的話，專案會變得非常臃腫，模組間的耦合性太強，維護起來很困難。...
專案經驗分享
最近一直在想自己在專案中的一些得失，在每乙個專案結束都要問自己一下 這個專案中自己獲得哪些成長，下次是不是可以做到更好。長期的專案過程往往會讓人陷入一種思維的定式 好像每個專案的工作都一樣，這樣很容易進入一種比較消極的狀態，會忘記自己曾經給自己設定的目標。以前看過這樣乙個問題 什麼才算得上有效經驗？...