灰色後門

last update：2013/6 一般的網頁連線過程裡，server端與client端的互動就像丟球遊戲一般 由client端丟球(連線)到server端，server端再根據過來的資訊把球丟給(回傳資訊)client端 而每一次的連線行為都是獨立的 server端專注接球並把球傳回去，並不會注意是誰把球丟過來 如果過程中有需求要持續辨識使用者的身分，則會透過Cookie、Session兩種機制來辨識 Cookie是將資訊記錄在client端，並連線時將訊息一併傳遞給server端 用比喻來形容就是在球上面簽名，server端接到球後就會知道是誰把球丟過來 Session則是將資訊存放在server端的記憶體中，並依此辨識 比喻是接球的server端用大腦記著每一個丟球給他的人 當然以上比喻對於細節也許不是那麼符合 而當系統對連線的辨識需求較多，或是即時性的要求較高(例如：twitter、線上聊天等系統) 使用Cookie、Session機制就不是那麼有效率了 包含HTML5也提出WebSocket機制來處理這類需求，而過去也有幾種標準作法 介紹可以參考JosephJ大的文章 - Browser 與 Server 持續同步的作法介紹

對應過程來自我的經驗 orz 雖然離處理結束也過了一段時間，不過最近比較忙，沒什麼空寫技術文章，所以拿出來經驗分享 首先是發現遭詐騙後，得立刻報案，並檢舉該帳戶(如果是匯款) 報案時注意，如果縣市政府有網路報案的機制，建議最好透過網路報案處理 網路報案完後，他會通知你還是得到受理的警局完成手續 但網路報案最大的好處是讓警方無法吃案，畢竟這是不容易偵破，影響層面又不大的案子 而且警察杯杯的打字速度大多很慢，先打好一些資料也會加速處理速度 接著是資料的保存，包含購物平台的資料及匯款資料得盡量備份 以我的情況是在報案快一年後才有後續通知 也因為一開始沒想過會偵破，所以資料備份不齊在後續處理有點吃虧，詳細情形後述 很多網購平台開放公開查詢的資料只限半年內(露天購物是如此)，之後要再收集當時資料會很麻煩

Google Closure是滿常被使用的開源JavaScript壓縮器 GCL的GitHub page： https://github.com/google/closure-compiler GCL線上版本： http://closure-compiler.appspot.com/home 其餘主流的壓縮器介紹可以看 談以壓縮、cache機制加速網路應用 以壓縮比例來說，GCL會較YUI compressor略好一些 這是因為兩者的機制有所不同 兩種壓縮器都提供3種層級的壓縮 最簡單的壓縮就是移除JavaScript檔案中的空白、換行符號 接著是預設的基本壓縮 除了不會變動全域變數、函式外，區域變數會重新命名以進一步減少檔案大小，一部分的多餘程式也會被移除 進階壓縮才是兩者的差異，YUI compressor純粹解譯JavaScript的程式碼文字 而Google Closure是compiler，會重新編譯成新的JavaScript code 也因為如此，GCL對於程式碼的要求比較嚴格，也是有些人會反映編譯時容易報錯 就我個人來看， 設計師要求自己的code能通過JSHint、JSLint是基本條件 ，所以不覺得是問題

微軟從IE8開始，在IE裡實作了一個物件 document.documentMode 紀錄了IE的版號 例如在IE8裡為 8，IE9裡為 9，依此類推 如果使用開發者工具調整回IE7模式會取得7，當然如果是原生的IE7及以下會拿到undefined 另外注意如果觸發了舊IE的Quirks Mode(也就是IE10的IE5 Quirks)，則會取得5 以現在的IE版本分布來說，IE7已經占不到1%，是可以忽略的數字 而微軟也開始強制Win7從 IE9 升級到 IE10 剩下最麻煩的XP的IE8....，也因為如此document.documentMode現在是可以倚賴的判斷工具 判斷 document.documentMode <= 8 就可以區隔新舊IE了 另外在 user agent 中也有方式可以辨識 可以參考  從user agent辨識新版 IE (IE11)