demoshop

上一篇講了在.NET Core使用資料保護API的方式，這一篇就要來說點實務上會遇到的問題，因為是非對稱加密，所以需要有相同的公鑰和私鑰才能解密，但私鑰已經由API自行處理，開發人員甚至不用知道它的存在，可是這樣子在現在很基本的Web farm架構，或是單純的兩個自有服務交換資訊的情境下卻無法使用了，好在.NET Core已經很不一樣了，很多地方都留了設定讓開發人員可以調整

在 .NET Core後微軟為了讓開發人員更輕鬆簡單的使用資料保護API，並且作為ASP.NET 1.x - 4.x 中 <machineKey> 元素的長期替代品。 解決舊密碼編譯堆疊的許多缺點，同時為現代應用程式可能遇到的大部分使用案例提供現成的解決方案。

使用者於網頁中輸入資料時如果在 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 可以驗證字串長度，不巧的是我想不出其他範例....所以只好上網搜尋範例