demoshop

使用者於網頁中輸入資料時如果在 http 下是使用明碼傳送，這是不安全的！但對於一般使用者來說根本不會察覺自己處於 http 還是 https 下，而且因為 https 有成本所以不一定每個業主都願意花這個錢。

日前身為網路服務霸主的 Google 調整了搜尋引擎的演算法，讓使用 http 的網站排名降低，後來更狠的在 Chrome 瀏覽器中主動標示沒有 https 的網站為「不安全」。這兩個產品都是超過95%的市佔，終於是喚醒了一般使用者對於資訊安全的重視。

但前文提過 https 是有成本的，一個最便宜的憑證一年也要三五千，不是每個業者都願意或有能力負擔的，後來 Let's Encrypt 這項免費憑證服務出現了，申請過程不麻煩，但 Let's Encrypt 免費憑證的有效期為三個月，要如何三個月都記得去 Renew 就是一件麻煩事了。

好在，微軟的雲端服務 Azure 有提供一條龍的使用者體驗，申請、自動 Renew 一次完成，省去各位開發者的時間與心力，但過程動用到許多 Azure 服務，所以特別寫這篇文章以圖文的方式介紹整個申請流程，讓所有把網站架設在 Azure 的同好可以簡單提昇自己網站的安全性。

今天聽完 Jason 在 SkillTree 開的「Web駭客攻擊手法及防護實戰」後，就立刻把日常使用的登入帳號改為從「系統管理員」改為「標準」因為 Windows 10 的步驟流程有些改變，所以寫個筆記來記錄一下。

流程是

1. 建立本機帳戶 A
2. 將 A 帳戶提升到系統管理員
3. 將原帳戶降級到標準使用者

Windows Live ID 其實就是讀者之前申請的 MSN 帳號，也同時是你的 Hot Mail 和 Outlook.com 帳號，因為現在微軟的許多服務也漸漸的走向 SaaS 的概念（軟體即服務）所以 Windows Live ID 的安全就開始重要的起來，終於就在今天微軟開始支援了所謂的「兩步驟驗證」。

兩步驟驗證這在許多雲端服務中都可以見到，如Gmail、Dropbox、GW2 等，兩步驟驗證的好處是系統不單單只認帳號密碼，還會綁一個其他的服務或實體裝置，讓駭客偷到帳號密碼時，因為沒有同時偷到你另一個服務的帳號密碼，或是沒有你指定的實體裝置而導致登入失敗，利用虛擬綁實體的方式達到更高等級的資安，本篇文章就是介紹如何開啟 Windows Live ID 兩步驟驗證的教學文。

MVC的內建驗證中有一個非常好用的 Remote ，如果各位開發人員有用過 jQuery.validate 應該對於 Remote 驗證不會陌生，簡單一點的解釋就是它可以將「後端驗證」做的很像「前端驗證」利用這種方式，開發人員不再受限於前端驗證可以判斷的資訊太少，讓驗證寫的不夠精準的問題，雖然 Remote 驗證相當好用但是有一點小地雷還是要知道的。

Uploadift 是一套基於 jQuery 和 Flash 的檔案上傳工具，提供了上傳進度以及多檔上傳的功能，畫面簡單大方是一個相當不錯的上傳套件。

demo 自從開始玩 ASP.NET MVC 以後已經很久沒有寫那麼新的 web form 專案了（能用 4.0 的我都叫他用MVC）這次一寫當然就很自然的會遇到頁面要傳 HTML 到程式的案例，也很合理的會先遇到一下 validateRequest=false 沒有效果的問題，上網搜尋了解法赫然發現有90%的網友都用了很可怕的解決方案，原本只是發在 G+ 和 FB 但是覺得好像是有義務提醒大家，所以刻意又發了一篇文章。

這裡說的無法正常登出指的是使用了FormsAuthentication 類別 來實作的登入登出機制，並不是使用 Session 來實作的登入登出，當你在 ASP.NET MVC 使用來做登入你會發現，熟悉的 FormsAuthentication.SignOut(); 竟然會無法登出，這方面應該是屬於 ASP.NET MVC 的 Bug ，既然官方沒改那我們就繞路自己解決吧。

ASP.NET MVC3 內建的錯誤訊息都十分的詳細，但我們自己擴充的都只會顯示【欄位 XX 無效。】這種沒啥用的錯誤訊息，因此本文會說明利用一些技巧來改變錯誤訊息的內容。

此篇文系列文的第四篇，接者介紹自訂驗證規則的方法，這次介紹的是屬於「範圍驗證」範圍驗證是一個很常使用到的驗證規則，比如數值的最大值最小值或是字串的最短長度和最長長度但很巧的這些都內建了...使用 Range 可以驗證數值範圍，使用 StringLength 可以驗證字串長度，不巧的是我想不出其他範例....所以只好上網搜尋範例

這次來到第二種自訂驗證的方法 SingleVal，其實這裡說的這些都是屬於前端驗證的方法，後端是很隨意的 讓我們來假設一下，今天 demo小鋪開放註冊會員，但是不希望有任何人註冊有關於 demo 這個名字，如果使用上一篇文章介紹的 AddBool 方式來寫，當哪一天要改成 「demoshop」 或是 「demo小鋪」的時候就會有很多地方要改，但是明明驗證邏輯是一樣的只是驗證的比對值不同，所以可以利用所謂的 AddSingleVal 方法來擴充驗證，要比對的值使用參數傳入，驗證的邏輯則是固定，這樣子就可以運用到多個情境，以下就是介紹

在上一篇系列文中介紹了 ASP.NET MVC3 原生的驗證使用方法，是很好用但是稍嫌不足，如果今天我們要驗證欄位的值是否為 Email 的格式，不可能每次都組出 Regex 來驗證，這是會累死人的，而且也不能保證每次寫出來的 Regex 都一樣，所以自訂驗證規則就是很重要的了，在 ASP.NET MVC3 中可以輕鬆自在的實作 ValidationAttribute 和 IClientValidatable 來擴充需要的驗證邏輯，此篇文章就先來介紹最簡單的 是否驗證。