hbdoy's blog

前言瀏覽器能夠儲存使用者經常填入的各種資訊，舉凡帳號、密碼、Email、姓名、電話、地址、信用卡資訊…等等。 帳號密碼可能不一定會儲存，但 Email、姓名、電話之類的個資，應該很多人會選擇讓瀏覽器記憶，避免每次填寫樸實又枯燥乏味的表單要一直重複輸入。 但是在理解瀏覽器 autocomplete 觸發機制後，你還敢直接填入你的資訊嗎? 以一個只有 Email 的表單為例，你以為只有填入 Email，實際上所有紀錄的個資，都可以被心懷不軌的網站拿到。 不囉嗦，直接弄個 Demo 網站看效果: https://ryanlee.tw/security-risk-of-autofill-demo 本文開始瀏覽器儲存的資訊看起來很多，但其實就是三個種類，以 Chrome 為例 密碼: 會綁定網站 Domain，只能夠自動填入相同網址下紀錄的帳密，所以不會發生 A 網站登入，卻填入 B 網站的帳密。 付款方式: 儲存信用卡資訊(卡號、到期日、持卡人姓名)，要在 https 的網站下才會觸發自動填入。 (本文主要討論)地址和其他資訊: 國家、郵遞區號、地址、姓名、電話、Email。 ...

前言ASP.NET Core 的 Model Binding 基本上和 ASP.NET Framework 差不多，但實際接觸後，一開始用起來卻卡卡的XD 本文將紀錄一些當初以為理所當然，結果卻不是這麼一回事的狀況。 Model Binding先來科普一下~ 最基本的有三個傳入來源 Form Route Query 可以三個都傳入，但是有其優先序Form > Route > Query 可以看到結果： 透過 Form 傳入 MyId1 = 1透過 Query 參數傳入 MyId1 = 3, MyId2 = 4 因為優先序的關係，MyId1 為 Form 傳入的 1，而 MyId2 因為 Form 沒有傳入，所以是吃到 Query 的 4。 Binding Attributes除了預設的三個來源，其餘皆需設定 Attribute 來指定接收來源。 但要注意，一經指定，資料就只能透過指定的方式傳入。也就是說，如果指定的 Attribute 本來就屬於預設的來源，那傳入 Attribute 指定的來源以外，也無法自動 Binding 上去。 [FromHeader ...

前言View Engine使用 ASP NET Core MVC 開發時，遇到 HTML 裡的中文被進行編碼，無法正常顯示。 在找問題成因的時候，出於好奇研究了一下 ASP NET 歷史版本的更新與 View HtmlEncode 的淵源，讓我們把時間倒回 2010 年吧XD 在 ASP.NET 3.5（MVC 2） 以前，WebForm View Engine 若想要編碼 HTML 中的內容以避免 XSS 問題，需要自己呼叫編碼的方法，但是每個內容都要呼叫實在很麻煩，而且開發者也常常會忘記。 所幸 2011 年，ASP.NET 4（MVC 3）發佈以後，新增 <%: %> 語法來自動對內容進行 HTML 編碼，減輕了開發者的負擔與降低系統安全風險。 ASP.NET 4（MVC 3）版本中，也 Release 了 Razor View Engine，因為容易學習、寫法更為簡潔方便的特性，使得它逐漸成為開發 ASP.NET MVC 網站的主流（兩者具體比較可以參考）。 本文開始Net Framework使用 Razor 在渲染畫面時，會自動進行編碼，防止 XSS。 開發 ...

前言當你需要一個安全的機制來保護你的資料時，不妨可以使用 Net Core 的資料保護（Data Protection）。 他有以下特點： 容易使用、擴展性高 基於非對稱的加密機制 正常情況下，不需要去設定與管理任何密鑰的儲存位置與生命週期 簡單來說你想加解密資料時，可以直接使用 Data Protection 的 API： Protect Unprotect 傻瓜式(?)的使用方式，也避免開發者： 搞不清楚「對稱、非對稱加密、Hash、編碼」的差異下，選擇了錯誤的方式來保護敏感資料。 自己造輪子實作加解密… 了解更多 ASP.NET Core 資料保護、ASP.NET Core 中的資料保護 Api 入門 本文開始在 Net Framework 時代，透過 MachineKey 來處理 Forms Authentication 的 Cookie 加解密（當然正常情況下也不會去動到 MachineKey，都交由系統處理）。 而 Net Core 雖沒有 Forms Authentication，但卻有差不多的 Cookie-based Authentication，他的 ...

前言對於待辦事項，之前一直沒有好的方式來管理，最早是嘗試使用行事曆，也就是把待辦事項都當成行程放在裡面，但這會有三個問題: 有些任務是沒有時間概念、或是急迫性的，也就是什麼時候做都可以 任務之間會有不同的大分類，Ex: 個人、工作，沒辦法很好的分開他們 行事曆沒辦法一目瞭然的看到所有 ToDoList，所有任務都和日期格子混在一起，導致時間久了，非常懶得開 後來有嘗試 Google Keep + Google Calandar，這個其實很接近我想要的管理方式了 任務都放在 Google Keep 上，很簡單就能夠管理 有需要時間概念的，就把任務壓上提醒時間 但這還是有四個問題 行事曆仍然與待辦事項分開，要用兩個 App 待辦事項用 Google Keep 有時過於陽春，缺乏良好的管理與搜尋方式 Google Keep 在 IOS 上的體驗非常不好 (截至 2020/12/06)，每次開啟 App 都會停頓個幾秒，好像是在同步，然後便籤很容易誤觸打開或關閉，拖動 Task 也常常卡頓 缺乏 Kanban 概念，沒辦法像 Trello 那樣把較複雜的任務，視覺化的拖動來控制任務狀 ...

前言原本以為用 Hexo、挑個 Theme，之後把 Blog 建起來應該不會遇到什麼問題，也不用特別記錄下來，但…事與願違XD 本文開始我用的主題是 butterfly，理論上只要把裡面文檔都看過就能解決 90% 的問題，也不太需要看官方文檔，弄好之後放在 Github Page，然後前面掛個 Cloudflare。 Hexo 大致設定 Disqus / Facebook Comments PWA Custom Pagination、Footer Edit Scaffolds Cloudflare 大致設定 SSL、Always Use HTTPS、Automatic HTTPS Rewrites Auto Minify、Cache、Always Online SEO 大致處理 Sitemap、Robots.txt Nofollow Submit to Google Search Console 科普知識就不提了，網路上已經很多詳細的文章 What ‘s Hexo and Why What’s Markdown How to deploy to Github Page H ...