跳到主要內容

發表文章

目前顯示的是 6月, 2013的文章

JavaEE Session、Cookie處理

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檔案

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是基本條件 ,所以不覺得是問題

判斷IE版本的簡單方法

微軟從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)