Tag: object

Facebook 上貼的所有的連結都是公開的

tl;dr：Facebook 認為這個功能是 feature，不是 bug。

在「Why you shouldn’t share links on Facebook」這邊作者發現在 Facebook 上貼的「任何一個連結」都會產生 object id，而任何一個 object id 都可以直接取得 url，無論權限設定，像是這樣：

而 Facebook 認定這是 feature 而非 bug：

可以想像 NSA 之類的單位與地下組織開始狂掃...

Amazon S3 的改善

在「Amazon S3 Introduces New Usability Enhancements」這邊提到了 Amazon S3 的兩個改善。

第一個是業務面的改善，以前應該是開 support ticket 請人調整 S3 bucket 數量上限，現在則是可以直接透過界面申請？(沒有遇過瓶頸，不知道以前是不是在界面上看不到...)

第二個才是重頭戲：Read-after-write Consistency。

With this enhancement, Amazon S3 now supports read-after-write consistency in all regions for new objects added to Amazon S3.

也就是說，Amazon S3 現在保證「新增的 object」「可以在建立後馬上被讀取」。之前還沒修正前，這個問題有多嚴重呢？可以看 2014 年時「Netflix 對 S3 的 Eventually Consistency 的補強...」這邊 Netflix 在跑 Pig 與 Hive 遇到的問題。

Netflix 這邊舉的例子是兩個 Pig cluster 在跑，其中 Pig-2 需要 Pig-1 跑出來的資料，在這次公告前，如果 Pig-1 的資料寫回 Amazon S3 時不會馬上出現，那麼 Pig-2 就會拿不完整的資料執行：

Pig-2 is activated based on the completion of Pig-1 and immediately lists the output directories of the previous task. If the S3 listing is incomplete when the second job starts, it will proceed with incomplete data.

而現在總算是保證新的 object 可以馬上被讀取，所以 Netflix 可以利用一個檔案列出所有的 filename，確保知道所有的檔案名稱... (LIST 指令還是 eventually consistent，所以這部份還是要自己處理)

資料結構、RDBMS、ORM

欠了很久的雜記。既然是雜記，只是把一些事情記錄下來，許多句子的主題會跳來跳去，請多見諒。

先解釋標題的三個詞彙。這邊要講的是三種存取資料的方式：

  • 資料結構：直接操作最底層的資料結構。
  • RDBMS (Relational Database Management System，關聯式資料庫)：透過 RDBMS 存取資料的方式，在 open source 領域比較常遇到 MySQL 與 PostgreSQL。由於與下面的 ORM 比較，這一條指的是透過 SQL query 去存取資料。
  • ORM (Object-Relational Mapping)：透過程式語言的 object 以及 object 之間的關聯性存取資料。

彈性最高、效能也最好的是直接的資料存取，但寫起來也最複雜；而 ORM 大致上就是反過來。

現代的 RDBMS 大多都有實做 ACID，在自己操作資料結構時考慮這塊會比較辛苦。兩個層級之間有一些 library 試著解決這個問題 (像是 BerkeleyDB 或是 LevelDB)，不過這篇文章暫時跳過。

MySQL 與其他的 RDBMS 比較起來欠了許多東西，但 High Availability 的成熟度以及效能而成為 open source 的第一選項。而也因為許多人使用，大家都知道 MySQL 的先天限制，也有許多 workaround 出現，所以大多數的狀況下這不是問題。

MySQL 的 InnoDB 其實寫的相當不錯，但 MySQL 的 SQL parser 一直都是 MySQL 的痛處，所以許多人使用 MySQL 時會儘量使用 simple query，而 ORM 的特性剛好可以搭上風。

使用 ORM 時最常見要避免的是 N+1 的問題，其他常見到的問題大多都不是 ORM 專有的。

先整理到這邊。

在 HTML 內嵌 JSON object 時要注意的事情...

有時候我們會因為效能問題，在 HTML 內嵌入 JSON object，而不是再多一個 HTTP request 取得。

但「嵌入」的行為如果沒有處理好，就產生非常多 XSS attack vector 可以玩。

首先最常犯的錯誤是使用錯誤的 escape function：

<!DOCTYPE HTML>
<html>
<body>
<script>
var a = "<?= addslashes($str) ?>";
</script>
</body>
</html>

這樣可以用 </script><script>alert(1);// 攻擊 $str。因為 addslashes() 並不會過濾到這個字串，而產生這樣的 HTML：

<!DOCTYPE HTML>
<html>
<body>
<script>
var a = "</script><script>alert(1);//";
</script>
</body>
</html>

而這個字串會造成 DOM parser 解讀上產生不是我們預期的行為：

可以看到在字串裡面的 </script> 被拆開了。

這是因為瀏覽器會先拆解產生 DOM tree，再把 <script></script> 內的程式碼交給 JavaScript engine 處理。所以在一開始產生 DOM tree 的時候，是看不懂 JavaScript 程式邏輯的...

正確的方法是用 json_encode() 處理，因為 PHP 的 json_encode() 預設會把 / (slash) 變成 \/ (這是 JSON spec 裡合法的轉換)：

<!DOCTYPE HTML>
<html>
<body>
<script>
var a = <?= json_encode($str) ?>;
</script>
</body>
</html>

這會產生出：

<!DOCTYPE HTML>
<html>
<body>
<script>
var a = "<\/script><script>alert(1);//";
</script>
</body>
</html>

但上面這段 HTML 與 PHP code 仍然有問題，如果 $str 是 <!--<script 時，你會發現 DOM 又爛掉了：

<!DOCTYPE HTML>
<html>
<body>
<script>
var a = "<!--<script>";
</script>
</body>
</html>

而 escape.alf.nu 的 Level 15 就是利用這個問題，再加上其他的漏洞而完成 XSS 攻擊。

為了這個問題去 StackOverflow 上問：「Why does <!--<script> cause a DOM tree break on the browser?」，才又發現上面這段 code 並不是合法的 HTML5 (先不管 head & title 的部份，補上後仍然不是合法的 HTML5)。

原因在於 DOM parser 對 <script></script> 的特殊處理：「4.3.1.2 Restrictions for contents of script elements」。(話說這段 ABNF 差點讓我翻桌...)

解法是在 <script></script> 的開頭與結尾加上 HTML 註解：(這剛好是 HTML 4.01 建議的方法)

<!DOCTYPE HTML>
<html>
<body>
<script>
<!--
var a = "<!--<script>";
-->
</script>
</body>
</html>

那段 ABNF 的目的是希望可以盡可能往後找到 --> 與 </script> 結尾的地方。

當然你也可以用 json_encode() 的 JSON_HEX_TAG 把 < 與 > 硬轉成 \u003c 與 \u003e 避開這個問題，但這使得呼叫 json_encode() 時要多一個參數 (而非預設參數)，用起來比較卡...

這個問題會變得這麼討厭，是因為 DOM parser 與 JavaScript 語法之間有各自的處理方式，然後又有些 pattern 是之前的 spec 遺留下來的包袱 (像是 HTML 4.01 在「18.3.2 Hiding script data from user agents」裡有提到用 <!-- 與 --> 包裝 <script></script>)，變成在設計 HTML5 時都要考慮進去相容...

之前會習慣用 <!-- 與 //--> 包裝 <script></script> 倒不是這個原因，而是因為不這樣做的話，jQuery 在 IE 使用 html() 時遇到有 <script></script> 的字串會爛掉，所以後來寫的時候變成習慣了...

反而因為這個習慣而避開了這個問題...

超難搞啊...

Perl 的 Object::Destroyer

使用 HTML::Tree 時因為有 circular reference，會要求你要使用 ->delete() 告知 object 打斷 reference 以避免 memory leak。於是就得很小心寫，要注意每個步驟以免某些狀況下忘記 ->delete() 而造成 leak：

my $html = HTML::TreeBuilder->new_from_content($body);
foreach my $element ($html->look_down('a', qr{某個 RE 條件})) {
    if (符合某個條件) {
        # 做某些事情...

        $element->delete;
        $html->delete;
        return;
    }

    # 做某些事情...
    $element->delete;
}
$html->delete;

後來找到了 Object::Destroyer，利用另外一個 object 的存活幫忙回收，於是就可以簡化成：

my $html = HTML::TreeBuilder->new_from_content($body);
my $htmlD = Object::Destroyer->new($html, 'delete');
foreach my $element ($html->look_down('a', qr{某個 RE 條件})) {
    my $elementD = Object::Destroyer->new($element, 'delete');
    if (符合某個條件) {
        return;
    }
    # 做某些事情...
}

這樣就不會 leak 了...