有考量到資訊安全的程式設計專案，通常都會要求機敏資訊，例如：連線字串、API 金鑰等等，不得直接簽入版控當中，等到應用程式要部署的時候，另外在正式環境中進行設定，這篇文章就來介紹如何在 IIS 上透過環境變數來覆寫 ASP.NET Core 網頁應用程式的組態設定。
有一天客戶的 IT 人員從資料庫中發現，某些資料欄位被塞入不尋常的資料。
看到這些資料的當下，我第一個念頭是「會不會某支程式有 Bug 導致整批資料被更新了？」，在排除這個原因之後，調查方向轉往「可能被駭客入侵了？」的狀況前進。
關於如何發佈 ASP.NET Core 應用程式到 IIS 上，官網上的這兩篇文章說得很清楚。
照著官網的步驟弄，一切還算順利，但還是遇到了一個小亂流，在執行 WebDeploy 的命令時，出現了「error MSB6006: "msdeploy.exe" 以返回碼 -1 結束」的錯誤訊息。
這是個對 IIS 的誤會，這個跟各個瀏覽器如何處理 Cache-Control 有關，IIS 在靜態檔案上預設沒有回應 Cache-Control 這個標頭，我比較了三款瀏覽器 Chrome（70.0.3538.77）、Firefox（63.0）、Edge（44.17763.1.0）來看看它們各自如何處理這種情況？以及 IIS 該如何來調整？
之前有介紹過 SSL 憑證只要放在 Load Balancing 就可以了，不必在每台 Load Balancing 後面的機器都去放置 SSL 憑證，假設我們原有 http://xxx.yyy.com 的網址，在我們打通了 https 之後想要將 http 都強制重新導向到 https，很直覺地我們想到的解決方案就是檢查打進來的 Request URL 如果是 http:// 開頭的就回應重新導向到 https:// 開頭的就行了，但死亡導向之門也就此被打開了。
對於 Web Site 的橫向擴展，有時候我們既定的印象就是多開機器，如果原本的機器就夠 Powerful，而採用的 Load Balancing 又可以對應到後端多個 Port 的話，我們其實可以選擇再新增一個相同服務但不同 Port 的站台。
HTTPS 協定已普及化了，甚至我們的網站如果沒有支援 HTTPS 的話，在搜尋引擎的排名還可能會被調降，本篇文章就在 IIS 8.5 躲藏在 GCP Load Balancing 背後的環境下，一步步去打通 HTTPS。
相信很多朋友都有遇到過，我們用 ASP.NET MVC 或 ASP.NET WebApi 做好的標記有 HttpPut、HttpDelete 的 Action，部署到 IIS 伺服器之後，試著去發 Request 卻收到 404、405 的錯誤訊息，除非我們只寫 HttpGet、HttpPost 方法，不然有大於 87% 的機率會遇到，底下就來記錄一下解決的方式。
IIS Shared Configuration 是從 IIS 7.0 開始就有的東西，透過共享的機制，讓 IIS 的設定可以在一台調整，然後同時套用到其他台，對我們需要管理多台 IIS 伺服器的工作有相當大的幫助。
為了讓搜尋引擎多認識我們的網站、提昇搜尋結果的排名，大都會做 SEO（Search Engine Optimization），其中有一條規則是要讓網址保持一致性，避免相同的網頁內容使用不同的網址，導致網頁的瀏覽量被分散，因而讓搜尋引擎認為我們的網頁內容沒什麼人要瀏覽，使得該網頁的權重下降而影響排名，如果是全新的網站，我們大可配合 SEO 來調整設計，可是如果是已經被蹂躪過的已存在網站，又剛好是 Host 在 IIS 上，該怎麼辦？
Developer Technologies (2016-2024)
