嗨！你好 👋
我是yishiashia，這邊會分享我在工作上的所遇到的問題與學習心得，請多多指教！
 on [Unsplash](https://unsplash.com/)](https://yishiashia.github.io/posts/webcomponent-introduction-3/photo-1507787090700-dea2089be848.webp)
Web Components 介紹與實作說明 (3) | 模組化開源與 CDN
前情 先前我們介紹了如何實作一個 Tooltips 的 WebComponenet 元件， 今天我們來說明如何將我們辛苦寫好的 UI 元件模組化並上傳到 NPM 套件庫， 方便之後可以重複使用。 模組化 在先前 CodePen 的範例中， 其實我們就使用了 立即調用函式 IIFE (Immediately Invoked Function Expression) 的方式來宣告我們的 Custom Element。 使用 IIFE 來執行模組化除了可以在網頁載入時執行我們定義的函式外，也可以透過局部作用域的創建來避免變數汙染與命名衝突等問題， 是前端模組化常常使用的模式，他的基本語法如下: 1 2 3 (function () { // 要執行的程式碼 })(); 而宣告與定義一個 WebComponent 主要是使用 window.customElements.define 來宣告我們自定義的 HTML 標籤，所以語法會像下面這樣: 1 2 3 4 5 6 7 8 9 // my-tag.js (function () { window.customElements.define( "my-tag", class extends HTMLElement { // 定義 Custom Element 參數、行為等 } ); })(); 完成上述的 IIFE 的程式碼後，我們可以將這段程式碼儲存在一個自訂的檔案，如: my-tag....
 on [Unsplash](https://unsplash.com/)](https://yishiashia.github.io/posts/webcomponent-introduction-2/photo-1530811761207-8d9d22f0a141.webp)
Web Components 介紹與實作說明 (2) | 實作一個 Tooltip 元件
先前我們介紹了關於 WebComponents 以及他的三大核心內容，這裡我們要透過一個實際的案例來建立一個 Tooltip UI 元件，來進一步熟悉 WebComponent 的實作方式。 在這篇文章中我們會先在頁面的 html 使用 template，然後定義一個 CustomElement 來簡單實作 WebComponent。 後續在另外的章節，我們會再介紹如何將我們實作的 WebComponent 模組化並上傳到 CDN 上供直接使用。 Tooltips 元件 Tooltips 元件是指當滑鼠移到特定網頁元件上，上方或指定方向會跳出一個泡泡提示窗並帶有提示內容文字或是 HTML 內容，可參考下圖: 圖片來源: 維基百科 元件設計 在實作一個 Tooltips，我們會希望: 可以在指定元件上方出現泡泡。 泡泡內可以帶入指定文字或 HTML。 泡泡提示窗可以帶一個箭頭指向指向目標內容元件。 當泡泡提示窗在網頁邊緣顯示時，可以自動往網頁中心內縮，避免超出網頁內容區。 那要使用 WebComponent Custom Elements 來實作 Tooltips 元件，我們先假定實作的 html tag 叫做 my-tooltip，如果要在一個圖片上加上提示窗，希望語法會是: 1 2 3 4 <my-tooltip alt="這是一張圖片"> <div n></div> <img src="a.jpg" /> </my-tooltip> 而希望畫面呈現出來會像這樣: 而如果要使用 HTML 當作提示窗的內容，則希望語法會是像這樣: 1 2 3 4 5 6 7 8 9 <my-tooltip> <!...
 on [Unsplash](https://unsplash.com/)](https://yishiashia.github.io/posts/my-webcomponents/maik-jonietz-_yMciiStJyY-unsplash.jpg)
Web Components 介紹與實作說明 | 我的開源 UI 元件庫
前言 在學會使用 WebComponent 的相關技巧後，陸陸續續也實作了不少的 UI 元件， 方便後續在進行前端專案的時候可以快速的重複使用。 而且不管您的專案是使用 VueJS、ReactJS 或者Angular， 都可以支援原生的 WebComponent，所以等於是一個通用的軍火庫， 寫一次就可以 Use everywhere，所以非常推薦將您常用的 UI 元件寫成 WebComponent 版本。 下面整理我目前有實作開源的 WebComponent 元件，後續如果有新做的 WebComponent 元件， 也會繼續更新上來，如果使用上有問題也歡迎發 issue 給我，謝謝 😊 小型輕量的 WebComponents 元件庫 項次 WebComponent 元件 安裝 / 原始碼 1 WebComponent Demo | swipe-to-refresh A WebComponent to pull the window down and refresh. 2 WebComponent Demo | mic-input Speech input WebComponent implemented with Web Speech API. 3 WebComponent Demo | star-input Star rating input implemented with WebComponent....
 on [Unsplash](https://unsplash.com/)](https://yishiashia.github.io/posts/webcomponent-introduction-1/photo-1508921340878-ba53e1f016ec.webp)
Web Components 介紹與實作說明 (1)
介紹 Angular Components、ReactJS Components、VueJS Components 通通都有，就是沒有屬於 VanillaJS 的 Components，所以今後只好自己創造 (大誤)。 其實早在 2011 年， Web Components 的概念就已經被提出，除了希望可以建立重複使用的 Web UI 元件外，也帶入了封裝的概念，如透過 Shadow DOM 的引入以封裝 Custom Element 的 CSS 樣式，避免互相污染，另外透過 Custom Element 中自定義的行為來達到功能上的封裝與重用性。 上面提到 Shadow DOM 、 Custom Elements，另外還有 HTML Template 為 Web Components 主要的三個核心內容，以下我們就分別介紹這三項核心內容。 Custom elements Custom elements 透過原生 JavaScript APIs 來自定義客製化 HTML 標籤，包含它的 attributes、properties與 events 等，方便依照網站設計的客製化需求來使用。 1 2 3 4 5 6 class MyCustomElement extends HTMLElement { ... } // 定義 Custom element window....
 on [Unsplash](https://unsplash.com/)](https://yishiashia.github.io/posts/dark-mode-and-css-color-scheme/photo-1552862750-746b8f6f7f25.webp)
網頁深色模式與 CSS 相關屬性
介紹 現代人由於工作、娛樂目的而長時間使用像是手機、電腦等 3C 產品，時間久了往往會造成眼睛疲勞不適，因此現在的網頁或 APP 介面往往會提供深色模式或是夜間模式，除了可以減少裝置電量的消耗，也可以減少光線對眼睛的刺激。 因此在前端網頁上實作亮色、深色模式也變成了提升使用者閱讀體驗所不可缺少的設計之一，因此，以下我們將說明如何透過 CSS 原生的 color-scheme 屬性來建置同時支援亮色 / 深色模式的網頁。 使用者代理樣式表 (User agent stylesheet) 使用者代理樣式表 (或有人翻譯作瀏覽器預設樣式表)，為瀏覽器針對原生 html 元件像是文字、輸入框或按鈕等預設的樣式。 以下我們撰寫了一個簡單 html 頁面，其中包含了一個 <h1> 元件: 1 2 3 4 5 <html lang="en"> <body> <h1>hello</h1> </body> </html> 在 Edge 瀏覽器中打開後，使用 devtool 觀察樣式可以看到下列的樣式，這個就是套用了瀏覽器預設的樣式表中關於 <h1> 元件的樣式。 1 2 3 4 5 6 7 8 9 h1 { display: block; font-size: 2em; margin-block-start: 0.67em; margin-block-end: 0.67em; margin-inline-start: 0px; margin-inline-end: 0px; font-weight: bold; } 除了對於各個 html 元件提供預設的樣式表之外，現在的主流瀏覽器也提供各元件在深色模式下的樣式表，而我們可以透過 color-scheme 來啟用它。...
 on [Unsplash](https://unsplash.com/)](https://yishiashia.github.io/posts/passkey-and-webauthn-passwordless-authentication/0_1zYBySFcoREDdevX.jpg)
使用 WebAuthn 實作無密碼驗證與 Passkey 介紹
Google、Apple、微軟及數百間科技公司或服務商在今年 (2022) 不約而同的表態支持 FIDO 聯盟與 W3C 所主推的通用無密碼登入標準 (common passwordless sign-in standard)，希望能透過例如指紋、Face ID等認證手段替代原本的密碼登入機制，提供用戶在網頁登入時一個更安全、防網路釣魚、即時交易驗證的登入方式。 Google 在今年10月上旬宣布在 Android 及 Chrome 導入 Passkey 無密碼認證機制，而 Apple 也將在 iOS 16 和 macOS Ventura 引入 Passkey ，透過掃描 QR Code 加上藍芽或其他裝置通訊技術，讓你可以透過手機的 Touch ID 或 Face ID 就可以登入你所有的電腦、平板等裝置。 下面我們會先說明需要使用密碼跟無密碼認證使用的場景，再深入介紹實務上使用 FIDO2 進行註冊與認證 (含範例程式)，最後再總結 FIDO2 / WebAuthn 與 Passkey 的關係 。 通常需要用到 ”密碼” 或 ”認證” 的場合，像是在電商網站買東西、下訂單最後要結帳的時候會請你輸入帳號、密碼做登入(不登入的話也可能會要求你透過手機簡訊驗證碼做實名制驗證)，可以用以確保您在真實世界的身分。 在資訊安全的領域中，不管是帳號密碼或是手機簡訊驗證碼的驗證，都是屬於 挑戰回應(Challenge/Response) 的方法。 挑戰回應 的方法具體來說，是指由正在溝通的兩方其中之一發起一個 挑戰 (Challenge)，而另一方提供一個正確可被驗證的合法答案 (Response)。 最常見的使用情境就是使用密碼驗證，比方說在電商網站購物前送出訂單之前請買家在網頁上再輸入一次密碼，如果密碼正確 (Valid response) ，則可以確認是由本人進行的操作。 但使用密碼作為驗證手段所衍生出的資安議題非常多，比方說網站管理者可能為了安全性而要求用戶使用的密碼複雜度必須足夠，但過於複雜的密碼常常會讓使用者記不起來，所以就寫在便條紙、記在手機備忘錄或存在檔案中，造成密碼洩漏的問題，而這也是 Apple, Google 及 Microsoft 三大廠商都主推無密碼認證的原因之一。...
 on [Unsplash](https://unsplash.com/)](https://yishiashia.github.io/posts/introduction-to-basic-cryptography/0_Li0quUCV8yxJl8dT.jpg)
簡易密碼學介紹
在早期，密碼學(Cryptography)是泛指隱藏訊息(hiding information)的方法，背後相關的知識包含數學、電腦科學(Computer science)及工程學等等，但時至今日，密碼學除了隱藏訊息之外，也同樣注重資訊安全屬性中的資訊完整性與不可抵賴性。 資訊完整性可透過驗算訊息驗證碼(如雜湊值或 checksum 等)來確認訊息沒有被人竄改過，而不可抵賴性則可以透過數位簽章的方式來驗證，下面來詳細說明。 加密演算法介紹 加密演算法是指訊息交換的雙方透過約定的密鑰(key)對訊息加密，原始的訊息(明文，plaintext)經過加密後會變成密文(cyphertext)，密文只有透過密鑰才可以還原回可閱讀的明文，因此可以放心透過網路或其他方式進行傳輸。 根據密鑰的特性一般可分作 對稱式加密演算法 及 非對稱式加密演算法，非對稱式加密演算法是指訊息傳遞者會產生一對 公鑰(public key) 及 私鑰(private key)。 1. 對稱式加密演算法 訊息交換雙方共享一組密鑰(key)，這密鑰就相當於兩人共享的秘密(shared secret)，沒有第三者知道。 當訊息要由A君傳送給B君時，A君會使用共享的密鑰對訊息進行加密，然後將加密後的密文傳遞給B君，B君再透過兩人共享的密鑰對密文進行解密，就可以取得明文的內容。 目前常見的對稱式加密演算法有一般網頁瀏覽時SSL/TLS加密使用的AES加密演算法，在 SSL/TLS handshake 時，瀏覽器跟網站伺服器間會協商出一個本次瀏覽期間使用的共享密鑰，在這次瀏覽期間使用的網頁封包都會透過這組密鑰進行加密。 2. 非對稱式加密演算法 明文透過公鑰加密變成密文後，需要透過對應的私鑰進行解密才能還原回明文；相反的，如果明文是透過私鑰進行加密變成密文，則需要透過對應的公鑰進行解密才能還原成明文。 圖片來源: 維基百科 而公私鑰的保存依照字面上的意思，私鑰需要由訊息傳遞者自己保存好，不能被別人知道(用以確保訊息是本人發送)，而公鑰顧名思義則是需要公開給所有人知道，一般的應用會透過可信任的第三方來保管所有訊息傳遞者的公鑰，比如政府的自然人憑證或健保卡憑證都是由政府建置所謂的公開金鑰基礎建設 (英語：Public Key Infrastructure，縮寫：PKI)，透過 PKI ，我們就可以取得使用者的的公鑰來解密訊息。 而上面我們提到非對稱式加密演算法的加解密特性與公私鑰的保管性質，就可以進行 數位簽章(確保是本人) 與 訊息保密 的動作。 數位簽章： 透過私鑰對訊息進行加密後傳送，所有人都可以透過在PKI取得訊息傳遞者的公鑰，如果解密可以成功就代表是本人傳送的(因為私鑰只有本人有)。 訊息保密： 如果我們今天要傳遞訊息給特定的使用者A君，然後希望其他人都無法知道訊息的內容，則可以透過 PKI 取得 A君的公鑰，對訊息加密後進行傳輸，儘管訊息傳遞過程中間的人(比方説郵差)有經手這則訊息，但因為對應的私鑰只有A君本人有，所以郵差先生就無法解密而得知訊息的內容。
 on [Unsplash](https://unsplash.com/)](https://yishiashia.github.io/posts/offline-image-storage-using-indexeddb/0_SE5YTSIGxPUrOgGS.jpg)
使用 indexedDB 離線儲存圖片
緣起 由於最近碰到要在負責的網頁式聊天機器人中，新增如同Line聊天室的貼圖功能，可想而知會有大量的貼圖圖片會需要在用戶裝置瀏覽器進行下載，不管是對圖片伺服器或是用戶等待的過程來說都是不小的負擔。 為了解決這個問題，透過使用了 PWA (Progressive Web App) 技術中常用的離線儲存方案 indexedDB 來快取貼圖圖片，不僅減少用戶端與網站伺服器端的連線流量，也提升的用戶體驗(UX: User Experience) 。 Service Worker Service Worker是一個事件驅動的網站 Worker，根據不同的來源 (origin) 與網址路徑 (path) 進行註冊後，之後再次訪問同一網站後即會在背景執行這個 Service Worker。 Service Worker 無法直接存取 DOM 物件，他負責監聽和處理像是 fetch, notification(推播), sync 還有 Service Worker 註冊、啟動 等相關事件。 透過處理上述事件，我們可以讓 web 網頁像一般的手機原生 App 一樣可以執行安裝、發送推播、離線瀏覽及連線後同步等等作業。 離線儲存 常見的 Ｗeb 儲存方案有下面幾種: Cookie LocalStorage Cache (precache) indexedDB 一般 SPA (Single Page Application) 中比較常用的是 Cookie 跟 LocalStorage 兩種儲存方法，不過在使用上都會有大小的限制（無法儲存較大的網站資源），像是 LocalStorage 的限制依照瀏覽器不同會落在大約 2MB ~ 10MB 左右，超過後就會發出Error。 而在 PWA 的離線儲存上通常會使用 Cache(precache) 或 indexedDB 來實作，它們的大小通常跟使用者裝置的 disk 空間有關係，以 Chrome 為例，所有網站可以用的共享儲存空間為硬碟可用空間的1/3, 每個網站 App 可以使用共享空間中的 20%。...
 on [Unsplash](https://unsplash.com/)](https://yishiashia.github.io/posts/self-hosted-dns-with-coredns/0_bBPydoEQM7H452gu.jpg)
使用 CoreDNS 自建 DNS Server
這陣子在研究自行建設 Postfix Mail Server，發現要架設一個 Mail Server 沒有想像中的容易，除了需要透過 DNS 記錄設定網域的 A 記錄、 MX 記錄之外，另外需要 DNS 設定 SPF, DKIM, DMARC 等安全性設定。 在設定的過程中很快的遇到了瓶頸，一般的網域服務諸如 HiDomain、GoDaddy 等平台都有代管 DNS 記錄的上限，像我使用的 HiDomain 就有最多設定 20 筆記錄的上限，因為在不同專案已經註冊了許多子網域，這次要架設一個 Mail Server 時我很快就碰到了 DNS 記錄的代管上限，後來決定使用在 Kubernetes (k8s) 中經常使用的輕量 DNS Server CoreDNS 來自建 DNS Server。 關於 CoreDNS CoreDNS 是雲原生運算基金會 (Cloud Native Computing Foundation, 簡稱 CNCF)的一項專案，並於 2019 年畢業。 CoreDNS 主要使用 Go 語言實做，所以可以安裝於不同平台並且相當輕量不會佔用太多系統的資源，同時在設定上非常簡單，透過使用 corefile ，可以很簡單的引入各種 plugin，很大程度地減少設定上的複雜度，接下來就實際進入安裝與使用的介紹。 安裝 CoreDNS 官網上提供了三種安裝方式， Binaries 、 Source 及 Docker。 Binaries 是已經預先編譯好的可執行檔，可以透過官方的連結去下載使用。...
 on [Unsplash](https://unsplash.com/)](https://yishiashia.github.io/posts/switch-themes-with-css-variable/joanna-kosinska-bF2vsubyHcQ-unsplash.jpg)
使用 CSS Variables 切換前端主題(Theme)
前端專案時常需要進行主題(Theme)切換，比方說現在最常見的 light/dark mode 主題切換。 本文將介紹如何透過 CSS Variables (或 CSS Custom Properties) 及 HTML root element 上的屬性控制前端網頁的主題切換。 CSS Variables (或 CSS Custom Properties)是 CSS3 的新功能，讓您可以不用透過SASS、SCSS等預處理語言即可在原生 CSS 語法中使用變數，讓 CSS 語法也可以達到 Clean Code。 1 2 3 4 5 6 7 8 9 10 11 :root { --primary-color: blue; } p { color: var(--primary-color); } h1 { color: var(--primary-color); } ▲範例：透過 CSS Variable 指定主題色彩的顏色 上面是一個簡單的範例，透過一個 –primary-color 的變數指定主題色彩，並套用到網頁中不同元的的樣式之中，未來要修改主題色時，只需要更新該變數，就可以一次性切換頁面中元件(如範例中的 與 標籤)的主題色，而不用一項一項的修改 CSS 樣式。 Theme 主題切換 從前面的說明中可以得知，宣告 Theme 相關的 CSS Variables 時通常會將變數的定義寫在 :root 的區塊中讓全域的 element 元件都可以取用，這意思就是說 CSS 變數需要定義在 document....