又LAG隨性筆記
  • 關於我
  • 作品集
  • 生活隨筆
  • 與我聯絡
  • 隨手扎

隨手扎

October 15, 2022

你可能不知道的Web API--Web Locks

前言

Web Locks相關的API目前還是實驗性質的,這意味著未來可能有所變動,會與本片內容提及用法、作用有差異。雖然是實驗性質,但目前主流瀏覽器都已經支援。

使用方式

最基本用法是透過navigator.locks.request()取得一把鎖,如果無法取得就必須等待直到能夠取得。如果取得了,就可以執行後續callback的動作。通常callback是一個異步函式,舉例來說寫法會如下:

navigator.locks.request('lock-1', async (lock) => {
  console.log('get lock-1');

  console.log('do something');

  console.log('release lock-1');
});

callback的執行區域,被稱作是 關鍵區域 (Critical section)。

如果設計的恰當,關鍵區域只會有一個在執行。把上面再改寫一下:

var lock_name = 'lock-1';

navigator.locks.request(lock_name, (lock) => {
    console.log(`A: get lock ${lock.name}`);
    return new Promise(res => {
        /// 10秒後釋放鎖
        setTimeout(() => {
            console.log(`A: release lock ${lock.name}`);
            res(); // release lock
        }, 10000 /*ms*/);
    })
})

navigator.locks.request(lock_name, (lock) => {
    console.log(`B: get lock ${lock.name}`);
    return new Promise(res => {
        /// 5秒後釋放鎖
        setTimeout(() => {
            console.log(`B: release lock ${lock.name}`);
            res(); // release lock
        }, 5000 /*ms*/);
    })
})

A: get lock lock-1 A: release lock lock-1 B: get lock lock-1 B: release lock lock-1

在上面範例,有兩個程式區塊A和B需要使用到lock-1這把鎖。A需要消耗10秒,並優先取得了鎖;B必須等待10秒後,才會開始執行。

可以透過將Promise的resolve()或reject()傳遞出來,來決定什麼時候要釋放鎖:

October 14, 2022

你可能不知道的(Web)API--FinalizationRegistry(GC)

你可能不知道的Web API–FinalizationRegistry(GC)

FinalizationRegistry是和WeakMap、WeakSet、WeakRef在ES12一同進入到語言規範裡的兩個API。其實後面幾個更容易使用到,但我今天偏偏就是要來聊聊前者–FinalizationRegistry。

在說說為什麼這個API有點雞肋可能沒什麼人知道之前,還是先介紹介紹這個API的用法。這個API的作用是在變數物件在被記憶體回收以前,可以註冊一些清理動作。比如可以建立物件:

var registry = new FinalizationRegistry((heldValue) => {
    console.log(`${heldValue} is cleaned`);
})

var obj1 = { toString() { return "<Object obj1>"} };

registry的callback function將快被記憶體回收的訊息打印出來。如果我們希望了解obj1和obj2何時被回收,可以用.register()註冊:

registry.register(obj1, obj1.toString());

那麼當obj1或obj2不再可以被存取的時候,就有可能被記憶體回收,進而列印出訊息出來:

obj1 = null;

至於為什麼obj1不能使用delete,可以參考「你可能都不瞭解的JS變數祕密 - 一文了解無宣告、var、let、const變數細節」
(突然發現這也是你可能不知道系列呢XD)

October 13, 2022

你可能不知道的Web API--postMessage

前言

postMessage()是少數可以讓兩個不同頁面交換訊息的方式。如其名,傳遞訊息,postMessage()接收一段文字訊息,將這個文字訊息傳遞給通知的對象。通知的對象可以監聽message事件獲取訊息。

關於postMessage()

實際上現在瀏覽器網頁API上,存在的postMessage()API不只一個。有window.postMessage()、Worker.postMessage()、BroadcastChannel.postMessage()和Client.postMessage(),它們有著類似的使用方式。除了不同頁面溝通外,對於建立的Web Worker執行緒也有相似方式傳遞訊息,除Worker.postMessage()外,在Web Worker環境下還可以建立BroadcastChannel物件,使用BroadcastChannel.postMessage()方法。至於Client.postMessage()是在Service Worker使用的,有在寫PWA(Progressive Web Application,漸進式網頁應用程式)才比較會用到。

本節主要討論的是最基本的window.postMessage()。

基本用法

基本上的用法可以傳遞一個字串作為訊息發送出去,像是window.postMessage("msg")。然後監聽message事件。所以我們可以做一個簡單的例子。

現在建立兩個頁面index.html作為主畫面,sub.html作為用iframe嵌入在主畫面的子畫面。

主畫面內容如下,除了一個發送訊息的文字話框外,還有一個接收訊息的文字畫框,以及一個發送訊息的按鈕。

<!------ index.html ------>
<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8"/>
    <title>[DEMO] postMessage (Main)</title>
  </head>
  <body>
    <form>
      <textarea cols="30" id="msg" name="" rows="10"></textarea>
      <br/>
      <textarea cols="30" id="rev" name="" rows="10" disabled></textarea>
      <br/>
      <button>send</button>
    </form>

    <hr/>

    <iframe frameborder="0" src="sub.html"></iframe>

    <script type="text/javascript" src="main.js"></script>
  </body>
</html>

相對來說子畫面就簡單一些,只有一個接受訊息的地方。它會將接受到的訊息原封不動的回傳回去。

October 12, 2022

你可能不知道的CSS Injection

前言

當你只是簡單地設置了一個CSP以後:

Content-Security-Policy: defalut-src 'self';

會發現誒~為什麼inline-script也不工作了?

<script type="text/javascript">console.log('Hello, World');</script>

要解決這個問題,同樣必須計算腳本雜湊值,然後設置新的內容安全政策:

Content-Security-Policy: defalut-src 'self';script-src 'sha256-2cq9aRSFdLqAC0FNx8cqcUjxA2Bmk5ZjlSvbIPQ1x/U=';

當然不止這種做法,還可以設置nonce等方式。

October 11, 2022

你可能不知道的內容安全策略(Content-Security-Policy, CSP)

前言

當我們知道了XSS,瞭解到對於外部資源的引用檢查是何等重要。那麼除了開發上需要注意意外,還可以怎麼做?

服務器設置CSP相關回應頭

CSP,全名Content Security Policy,也就是內容安全政策。這是為了告訴瀏覽器,這個頁面允許什麼行為,讓瀏覽器幫忙在檢查一次。與設個相關的主要有兩個Response Headers:Content-Security-Policy和Content-Security-Policy-Report-Only。

Content-Security-Policy可以設定一些政策,當瀏覽器發現也面內容行為不符合這些政策的時候,就會被阻擋下來。

如果在一開始調整,有大量不確定受到影響的頁面,並不希望行為直接被阻擋下來,可以改先使用Content-Security-Policy-Report-Only。當發現不符合政策的頁面內容時,先發送到後端的一個端點記錄下來。再所有被發現存在問題的頁面都已經修正後,再改成設置為Content-Security-Policy。

繼續以前一個例子來用:A網站 http://a.127.0.0.1.nip.io:8000/index 有以下內容:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8"/>
    <title>CSP</title>
    <link rel="stylesheet" href="http://b.127.0.0.1.nip.io:8000/xss.css" type="text/css" media="screen" />
  </head>
  <body>
    <h1>Hello, World</h1>
  </body>
  <script type="text/javascript" src="http://b.127.0.0.1.nip.io:8000/xss.js"></script>
</html>

這次也真夠糟糕的,引用到兩份B網站 http://b.127.0.0.1.nip.io:8000 存在問題的內容–/xss.css和/xss.css

在部署的時候可以在伺服器回應的HTTP Response加入Header:

Content-Security-Policy: defalut-src 'self';

這次這兩個不安全的內容就會被瀏覽器阻擋下來。

如果確定外部資源內容是需要的話該怎麼辦?

October 10, 2022

你可能不知道的跨站腳本攻擊(Cross-Site Scripting,XSS)

前言

跨站腳本攻擊,英文Cross-Site Scripting,縮寫原本應該是CSS,但與階層樣式表–Cascading Style Sheets的縮寫相同,所以通常已X當做「交叉」的Cross,就變成是XSS。

在今天算是一個很嚴重的漏洞攻擊,因為有可能做到身份偽造,然後去進行資料竊取或破壞。但防禦跨站腳本攻擊,不單單只是前端開發工程師的責任,很大程度上也與服務如何部署有關係。

什麼是跨站腳本攻擊

跨站腳本攻擊,是在頁面上存在從其他來源引入的腳本,而這些腳本帶有惡意行為。要注意的是,腳本並不只是指JavaScript,HTML、CSS或其他資料內容也有可能是惡意注入的對象。

The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash, or any other type of code that the browser may execute.

惡意的JavaScript

比如說在A網站 http://a.127.0.0.1.nip.io:8000/index.html 有以下內容:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8"/>
    <title>XSS</title>
  </head>
  <body>
    <h1>Hello, World</h1>
  </body>
  <script type="text/javascript" src="http://b.127.0.0.1.nip.io:8000/xss.js"></script>
</html>

在這個頁面中,使用了另一個網站B http://b.127.0.0.1.nip.io:8000 的JavaScript。但是其實xss.js的檔案並不是自己可以掌控的,它的內容可能是:

  • ««
  • «
  • 1
  • 2
  • 3
  •  … 
  • 34
  • »
  • »»
© 又LAG隨性筆記 2025