黑暗執行緒

多想兩分鐘，你可以不用 validateRequest="false"(WebForm版)

2012-02-01T14:14:03Z

接續前一篇不關閉validateRequest下允許傳送XML內容的議題，有人問起，我才想到該文只示範了AJAX做法，壓根忘了提WebForm環境下應如何處理。

以下是我會採用的處理方式。原理上還是透過encodeURIComponent()及HttpUtility.UrlDecode()分別在Client端與Server端加解碼，只是要額外動些手腳:

在網頁上放一個<asp:HiddenField>作為實際的傳值容器。
供使用者輸入的<textarea>或<input type="text">定義成純Client端元素，並記得只指定id，不要指定name屬性，不然它會一併被Postback引發檢核錯誤，徒增麻煩。
在表單的Client onsubmit事件中，取出textarea內容，經encodeURIComponent()後存入<asp:HiddenField>中，接著就可以放心送出表單囉!
Server端在IsPostBack時用HttpUtility.UrlDecode(theHiddenField.Value)就能輕鬆取值。

以下是程式範例:

<%@ Page Language="C#" %>

<!DOCTYPE>

<script runat="server">

    void Page_Load(object sender, EventArgs e)

        if (IsPostBack)

            Response.ContentType = "text/plain";

            Response.Write("Data=" + HttpUtility.UrlDecode(hdnXml.Value));

            Response.End();

</script>

<html>

<head runat="server">

    <title>MyLab</title>

    <style>

        body,input { font-size: 9pt; }

    </style>

    <script src='http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.js'></script>

    <script>

        $(function () {

            $("#txtXml").text("<data>Text</data>");

            //掛上onsubmit事件，表單送出前，將textarea的內容編碼後寫入hidden

            $("#form1").submit(function () {

                $("#hdnXml").val(encodeURIComponent($("#txtXml").text()));

});

});

    </script>

</head>

<body>

    <form id="form1" runat="server">

    <!--用純Client端的textarea或input讓使用者輸入XML，

        記得只設id，不要設name，以免PostBack時被一併送回-->

    <textarea id="txtXml" cols="20" rows="4">

    </textarea><br />

    <asp:HiddenField ID="hdnXml" runat="server" EnableViewState="false"/>

    <asp:Button ID="btnSubmit" runat="server" Text="Submit" />

    </form>

</body>

</html>

PS: 當然，你也可選擇不另增設HiddenField，直接在onsubmit時取出<textarea>內容，encodeURIComponent()後再寫回<textarea>。不過省下這點工，卻必須面對使用者回上頁時<textarea>變成編碼後內容的燙手山芋，個人認為並不划算，建議別自找麻煩。

多想兩分鐘，你可以不用 validateRequest="false"

2012-02-01T00:21:30Z

先來看以下的程式，網頁上放了一個<textarea>及<input type="button">，按鈕後以$.post()方式將<textarea>的內容送至ASP.NET Server端程式，在Page_Load中讀取Request["data"]並顯示出來，另外並透過$.ajaxSetup()指定error錯誤事件函數，捕捉並顯示伺服器端的錯誤資訊。

<%@ Page Language="C#" %>

<!DOCTYPE>

<script runat="server">

    void Page_Load(object sender, EventArgs e)

        if (Request["mode"] == "ajax")

            Response.ContentType = "text/plain";

            Response.Write("Data=" + Request["data"]);

            Response.End();

</script>

<html>

<head runat="server">

    <title>MyLab</title>

    <style>

        body,input { font-size: 9pt; }

    </style>

    <script src='http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.js'></script>

    <script>

        $(function () {

            $("#txtXml").text("<data>Text</data>");

            //發生錯誤時顯示錯誤訊息

            $.ajaxSetup({

                error: function (xhr, textStatus, err) {

                    alert("ERROR: " + err + "=>" + xhr.responseText);

});

            //以$.post方式將textarea的內容送至Server端

            $("#btnAjaxPost").click(function () {

                $.post("?mode=ajax", { data: $("#txtXml").text() },

                    function (r) { alert(r); }

);

});

});

    </script>

</head>

<body>

    <form id="form1" runat="server">

    <textarea id="txtXml" cols="20" rows="4">

    </textarea><br />

    <input type="button" id="btnAjaxPost" value="Ajax Post" />

    </form>

</body>

</html>

老鳥們應該已嗅出異常: 程式會出錯!!

由於我故意在<textarea>中塞入了XML內容，而ASP.NET 2.0起增加了Request Validation的機制，防範惡意人士在URL或PostBack內容中夾雜HTML標籤進行XSS攻擊。很多人遇到這個狀況，直覺反應就是毫不猶豫將@Page validateRequest設成false(甚至一不做二不休，在web.config設定把整個網站的requestValidate都關掉)，程式不再出錯，就開開心心快快樂樂繼續寫下去。

身為一個輕度資安偏執者，我反對這種處理方式!! 多想兩分鐘，你可以不要validateRequest="false"。

廚師帶著鍋杓要進總統府外燴，經過金屬探測門安檢時警報大作，解決之道是把金屬探測器拆掉??

不是吧? 針對鍋杓的特例另外處理才是王道，但在資訊系統中無法通過檢核就把防護關掉眼不見為淨的例子比比皆是... (檔案拒絕存取就一律開Everyone、程式在Windows 7跑不了就關UAC)

依我的看法:

應保留requestValidate="true"擋下大部分未知的可能攻擊，針對確實會包含XML/HTML資料且另有內容安全檢核程序的情境，再設法繞道而行

才是安全的策略!

要怎麼讓HTML/XML內容傳送時避免被Request Validation機制阻攔呢? 其實不難，Client端在送出資料前進行編碼，Server端在收到資料進行解碼還原即可。而借用encodeURIComponent()應是最簡單的寫法了，例如:

在$.post()時改成
$.post("?mode=ajax", { data: encodeURIComponent($("#txtXml").text()) }

在Page_Load()時改成
Response.Write("Data=" + HttpUtility.UrlDecode(Request["data"]));

前後端一搭一唱，就可以在不觸發警告的情況下完成XML或HTML資料傳送。但必須牢記，加上了這段設計，意味著駭客就能在Request["data"]中設法摻入HTML標籤，一定要加上邏輯杜絕Request["data"]夾帶HTML標籤引來XSS攻擊的風險。

encodeURIComponent()的做法有個小缺點，就是編碼後內容會膨脹。例如原本的<data>Text</data>會變成%253Cdata%253E%25E5%259C%258B%25E5%25AE%25B6%253C%252Fdata%253E。若要改善，需另覓其他的編碼規則，或在部分情境可考量將XML內容直接當成Post的內容主體(補充參考)。

簡單範例如下，Client端改用$.ajax()方式傳送，指定type="POST", contentType="text/xml"(或是text/plain亦可), 另外還要指定processData=false，即可將data內容當成POST本體，如此亦可避開Request Validation，達成相同目的。

<%@ Page Language="C#" %>

<!DOCTYPE>

<script runat="server">

    void Page_Load(object sender, EventArgs e)

        if (Request["mode"] == "ajax")

            Response.ContentType = "text/plain";

            //使用StreamReader讀入Request.InputStream的所有內容

            var sr = new System.IO.StreamReader(Request.InputStream);

            Response.Write("Data=" + sr.ReadToEnd());

            Response.End();

</script>

<html>

<head runat="server">

    <style>

        body,input { font-size: 9pt; }

    </style>

    <script src='http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.js'></script>

    <script>

        $(function () {

            $("#txtXml").text("<data>Text</data>");

            //以$.post方式將textarea的內容送至Server端

            $("#btnAjaxPost").click(function () {

                $.ajax({

                    url: "?mode=ajax",

                    type: "POST",

                    contentType: "text/xml", //指定格式為XML

                    data: $("#txtXml").text(),

                    processData: false, //指定直接傳送內容不做處理

                    success: function (r) { alert(r); }

});

});

});

    </script>

</head>

<body>

    <form id="form1" runat="server">

    <textarea id="txtXml" cols="20" rows="4">

    </textarea><br />

    <input type="button" id="btnAjaxPost" value="Ajax Post" />

    </form>

</body>

</html>

TIPS-在多執行緒環境更新共用資料物件

2012-01-31T14:47:00Z

有一段小時候寫的程式，運行多年無恙，卻在今天發生爆炸!

看似正常的更新Dictationary邏輯，卻在Dictoinary.Add時冒出"Index was outside the bounds of the array."錯誤:

if (Cache.ContainsKey(key)) Cache.Remove(key);
Cache.Add(key, someData);

Cache的型別為Dictionary<string, string>，程式先檢查該Key值是否存在，若存在先將該Key資料移除，接著存入新資料。由於是在網站環境，程式碼有可能被多個Request以多執行緒方式同時呼叫，而不知是年幼無知或一時糊塗，這段更新資料邏輯並沒有加上執行緒安全防護(Thread-Safe)，可能就是導致爆炸的原因。但直覺上會爆出的狀況是剛Remove()還來不及Add()前，另一個Request(另一條執行緒)插隊先Add()相同Key值的資料而導致"An item with the same key has already been added"錯誤，但冒出IndexOutOfRangeException就讓人有些不解，莫非這也是多執行緒寫入失控引發的現象之一?

設計了一個驗證測試，我使用以下做法在static Dictionary<string, string>新增相同Key值的資料，用Thread.Sleep()隨機時間的方式模擬實務上自然湧入的Request。

using System;

using System.Collections.Generic;

using System.Threading;

public class TestRunner1

    public static Dictionary<string, string> Cache =

        new Dictionary<string, string>();

    //警告: 以下為未考慮Thread-Safe的寫法

    static void UpdateCache(string key, string data)

        if (Cache.ContainsKey(key))

            Cache.Remove(key);

        Cache.Add(key, data);

    static Random rnd = new Random();

    //進行測試，更新Cache的同一項目

    public static void Test(int i)

        //產生隨機延遲，設法逼近一般實務情境

        Thread.Sleep(rnd.Next(5));

        UpdateCache("MyCache", rnd.Next().ToString());

        Console.WriteLine("Done-{0:0000}", i);

呼叫端以ThreadPool多執行方式呼叫TestRunner1.Test()，並捕捉IndexOutOfRangeException並設定Visual Studio偵錯中斷點，再使用浮動監看視窗觀察Dictionary遭多執行緒蹂躙後的樣子。多試幾次，果然看到許多奇異現象:

Index was outside of the bounds of the array!

Count變成負數! 酷吧?

雜湊表型別中出現Key值相同的奇景!! 沒見過吧?

啊哈!! 我抓到.NET Framework Dictionary物件的Bug嗎? 才不是哩!! ~~本草綱目~~MSDN文件有記載:

只要未修改集合，Dictionary<TKey, TValue>.KeyCollection 可同時支援多個讀取器 (Reader)。即便如此，透過集合的列舉基本上並非安全的執行緒程序。若要確保列舉期間的執行緒安全，您可以在整個列舉期間鎖定集合。若要允許多重執行緒存取集合以進行讀寫，您必須實作自己的同步處理。

A Dictionary<TKey, TValue>.KeyCollection can support multiple readers concurrently, as long as the collection is not modified. Even so, enumerating through a collection is intrinsically not a thread-safe procedure. To guarantee thread safety during enumeration, you can lock the collection during the entire enumeration. To allow the collection to be accessed by multiple threads for reading and writing, you must implement your own synchronization.

簡單來說，Dictionary<TKey, TValue>在多執行緒下讀取沒問題，但若打算在多個執行緒中同時更新或是跑foreach，就必須自行處理鎖定及同步議題。在這個測試案例中，最簡單的做法在UpdateCache()時加上一行lock:

    //簡易的單層鎖定機制

    static void UpdateCache(string key, string data)

        lock (Cache)

            if (Cache.ContainsKey(key))

                Cache.Remove(key);

            Cache.Add(key, data);

當所有執行緒以Cache為對象進行鎖定後，可迫使所有更新動作排隊依序執行，防止多個執行緒搶著更新同一個物件衍生的不可預期後果。(在使用複雜查詢產生快取資料的情境，若要避免鎖定及重複執行拖累效能，還要進一步考量使用雙重檢查鎖定之類的設計模式，這部分未來有機會再另文討論) 而同樣的原理也適用ASP.NET Cache物件的新增或更新操作上，一樣是全Process只有一份，一樣會有多個Request多執行緒同時執行，故最好也加上同步化或鎖定機制以防止多執行緒打架。

另外，如果你的專案使用的是.NET 4.0，則有個好消息: .NET 4.0新增了System.Collections.Concurrent命名空間中，多了ConcurrentDictionary, ConcurrentQueue, ConcurrentStack... 等等五個內建支援多緒存取的安全執行緒集合類別，省卻了自行處理lock的麻煩，可多加利用。

    public static ConcurrentDictionary<string, string> Cache =

        new ConcurrentDictionary<string, string>();

    //改用ConcurrentDictionary

    static void UpdateCache(string key, string data)

        //不存在就新增、否則用更新的

        Cache.AddOrUpdate(key, data,

          //第三個參數是當key值存在時，要更新的內容

            //本例中，則固定以data值覆寫之

            (k, v) => data);

【茶包射手日記】使用IE Dev Tools追查Javascript效能問題

2012-01-18T15:44:55Z

同事回報某個網頁出現"在IE8下，使用jquery.blockUI遮蔽某個div後，<input type="text">輸入時，每打一個字都要等1-2秒字元才會顯示"的問題。

開啟VM使用IE8可重現問題；而同樣網頁在IE9下則運作正常。針對此一IE下的JavaScript茶包，決定交由JavaScript效能茶包一哥--IE Dev Tools Profiler工具進行獵殺!

使用IE8開啟問題網頁，按下F12啟用IE Dev Tools，故意觸發blockUI遮蔽重現輸入回應緩慢問題，此時選取IE Dev Tools的Profiler頁籤，按下"Start profiling"，輸入幾個字元後，再停止側錄。

結果顯示，簡單幾個按鍵動作觸發了六千多次的sortOrder、siblingCheck以及高達17萬次的Array.unshift，頗為異常；而未使用blockUI遮蔽時則無此狀況。其中sortOrder耗用了數秒執行時間，疑似導致效能不彰的元兇。

使用IE9進行相同測試，得到相近結果: 一樣在幾秒內連續觸發成千上萬次的sortOrder、siblingCheck及Array.unshift，唯一不同的是IE9並未因此發生輸入回應遲緩的現象。我推估是同樣的指令在IE9環境中執行方式有異或是IE9大幅提升了JavaScript Engine的執行效能，因而執行次數相近，卻只耗用了386ms(如下圖)，未明顯影響效能。

為追查導致異常大量呼叫的來源，將Current view切換為Call tree(下圖藍框處)，可看出一連串的sortOrder呼叫源於jquery.blockUI.js第448行。

雙擊上圖橘框處，可直接帶至相對的程式碼位置，由邏輯推斷疑似呼叫$(e.target).parents("div." + opts.blockMsgClass)這段所引發。

懷疑是blockUI舊版Bug或blockUI與jQuery版本匹配問題，比對了jquery.js及jquery.blockUI.js版本，發現blockUI已是最新版，而jquery.js則還是1.4.4，版本偏舊。試著將jquery.js換成1.4.2或1.7都不會引發問題，因此推測屬版本匹配問題。決定將jquery.js換為1.7.1版並確認其他功能未受影響後，問題排除~

建立VS2010專案項目範本

2012-01-17T15:46:05Z

針對簡單的AJAX前後端整合程式範例，我很愛以下這種HTML + JavaScript + C#三合一寫法:

<%@ Page Language="C#" %>

<!DOCTYPE>

<script runat="server">

    void Page_Load(object sender, EventArgs e)

</script>

<html>

<head runat="server">

    <title>AJAX Example</title>

    <style>

        body,input { font-size: 9pt; }

    </style>

    <script src='http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.js'></script>

    <script>

    $(function() {

});

    </script>

</head>

<body>

    <form id="form1" runat="server">

    <div>

    </div>

    </form>

</body>

</html>

當Server端的程式邏輯不多時，我會選擇用Inline Code ASP.NET網頁，Server端程式不另拆成Blah.aspx.cs，而直接以<script runat="server">嵌在HTML中，如此HTML+JavaScript+C#集中在同一個程式，閱讀方便；而要測試時，因jQuery等引用自CDN，直接將範例程式碼存成Boo.aspx就可當場執行，馬上看結果，比拆成aspx, aspx.cs, js來得更加省事不沾手。

不過，每次建立範例時總有些固定程序:

建立一個新的Web Form項目，取消"Place code in separate file"(將程式碼置於個別檔案中)選項。
VS2010預設的Web Form樣版內含
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">及<html xmlns="http://www.w3.org/1999/xhtml">等XHTML宣告。
我習慣改成HTML5寫法: 簡化為<!DOCTYPE html>及<html>。
加上<script src="…">指向Microsoft CDN，載入jQuery。
加上void Page_Load(object sender, EventArgs e)的Server端C#程式片段
加上$(function() { });的Client端JavaScript程式片段

由於這幾個步驟每次寫範例都要重新玩一次，便興起弄成項目範本的念頭。原以為要花點功夫搞懂自訂範本的細節，找到91的一篇專案範本建立教學，才發現貼心的Visual Studio已內建"下一步下一步"匯出精靈，將現有專案或項目轉成範本的做法出奇簡單，真是佛心來著。91介紹的是專案範本，建立項目範本的範例就交給我囉!

首先，在專案裡先做好一個如前述程式的空白Inline Code ASPX，接著選"File->Export Template"(部分細節91的文章已有說明，此處不再贅述)，接著選擇要出Item Template(項目範本):

選取要匯出成範本的檔案項目:

中間還有一個指定參照程式庫項目的步驟，本案例不需要，故直接跳過。接著為範本指定名稱，加上說明，再配個Icon讓範本看起來更專業一點。

完成後，新增項目時就可以看到剛才做好的範本囉!

試用了一下，覺得這個精靈產生的陽春範本有兩個地方可以再強化: 1) 預設會使用範本名稱當作檔案名(如上圖的HTML5 ASP.NET Example.aspx)，而我想改成MyLab .aspx 2) <title>是固定的，想將其預設為新增aspx的檔案名

查了MSDN文件，找到客製這兩個需求的方法:

匯出的範本其實是一個ZIP檔案，其中包含了範本檔案來源、vstemplate設定檔、圖示檔等內容，被放在使用者文件資料夾的Visual Studio 2010\Templates\ItemTemplates目錄下。(如下圖)

*.vstemplate是一個XML設定檔案，透過修改<DefaultName>即可自訂預設檔名:
```
  <TemplateData>
```
```
    <DefaultName>MyLab.aspx</DefaultName>
```
```
    <Name>HTML5 ASP.NET Example</Name>
```
Visual Studio提供了一些預設範本參數，允許我們在範本中套用專案名稱、使用者名稱、機器名稱、項目名稱、根命名空間等資訊。因此只要在Lab1.aspx中將<title>內容換成$itemname$，在產生新檔案時，就會被自動換成檔案名稱。
```
<head runat="server">
```
```
    <title>$itemname$</title>
```
```
    <script type='text/javascript' 
```
```
            src='http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.js'></script>   
```
```
    <style>
```

解壓縮取出ZIP檔中的MyTemplate.vstemplate及Lab1.aspx，修改後再重新壓縮，能節省繁瑣手工的範本就完成囉! Visual Studio Rocks!!

筆記-IIS 7網站目錄的最小NTFS權限

2012-01-17T09:43:49Z

IIS 7新增了虛擬帳戶(Virtual Accounts)的概念，即每個應用程式集區(App Pool)都有一個專屬的IIS APPPOOL\AppPoolName虛擬帳號，便於更精準地控管網站相關檔案及其他資源的存取權限。(關於虛擬帳號概念，可參考保哥的詳細介紹: 介紹 IIS 7.5 的應用程式集區與新增的「虛擬帳戶」特性)

權限管控的最高指導原則在力求"在維持可運作的前題下，開放最少權限"，因此拔除網站目錄的預設NTFS權限理，只授權給最少的必要帳號，將能提高安全性。不過，IIS 7"最小權限"的範圍為何?

找了一些探討IIS權限文章，沒找到關於NTFS權限需求較直接明確的說明，最後只依理論跟實驗結果整理出一點心得。(如果有人看過明確的文件說明，歡迎分享)

我用以下程式偵測ASP.NET執行身分的相關資訊:

<%@ Page Language="C#" %>

<script runat="server">

    void Page_Load(object sender, EventArgs e)

        Response.Write("<li>Request.IsAuthenticated=" +

            Request.IsAuthenticated);

        Response.Write("<li>Request.LogonUserIdentity.Name=" +

            Request.LogonUserIdentity.Name);

        Response.Write("<li>WindowsIdentity.GetCurrent().Name=" +

            System.Security.Principal.WindowsIdentity.GetCurrent().Name);

</script>

在匿名存取時結果如下:

Request.IsAuthenticated=False

Request.LogonUserIdentity.Name=NT AUTHORITY\IUSR

WindowsIdentity.GetCurrent().Name=IIS APPPOOL\JEFFPool

啟用Windows Authentication時則為:

Request.IsAuthenticated=True

Request.LogonUserIdentity.Name=MyDoamin\MyAccount

WindowsIdentity.GetCurrent().Name=IIS APPPOOL\JEFFPool

要透過IIS執行程式，帳號必須對網站資料夾至少有讀取與執行(Read & execute)、列出資料夾內容(List folder contents)等權限。原本以為只需要開放給IIS APPPOOL\JEFFPool帳號就好，但實測發現在上述兩種情況下，還分別需要授與權限給NT AUTHORITY\IUSR及MyDoamin\MyAccount，不然就會產生拒絕存取錯誤。

透過Process Monitor我觀察到w3wp.exe確實是以IIS APPPOOL\JEFFPool身分執行，但在執行showid.aspx時偷偷調閱了aspx的檔案權限設定，推測(純屬推測)其目的是用來比對Request.LogonUserIdentity的使用者在showid.aspx的NTFS權限清單中是否具有讀取執行權。因此Request.LogonUserIdentity跟IIS APPPOOL\JEFFPool兩個帳號都要有權限才不會產生存取錯誤。

最後我整理的結論為:

匿名存取(或表單驗證, Form Authentcation)時，網站資料夾的最少授權對象為NT AUTHORITY\IUSR及IIS APPPOOL\YourPoolName；
Windows驗證時，除IIS APPPOOL\YourPoolName外，要再指定為Authenticated Users群組、Domain Users群組，或是可登入使用者所屬的特定群組三者之一。

PS: 當啟用ASP.NET模擬(Impersonation)時，會影響ASP.NET的執行身份(可由WindowsIdentity.GetCurrent()觀察)，授權對象需再自行調整。

【茶包射手日記】Word文件中的超連結變成{ HYPERLINK ... }

2012-01-13T04:40:04Z

接獲同事求助: Word 2010無法正確顯示內嵌超連結的文件。

文件的正常顯示應如下:

但同事使用Word 2010開啟同該文件時，超連結的部分會變成{ HYPERLINK "..." }。

過去小玩過Word VBA，憑印象中認出"功能變數"的標註格式，故懷疑是同事誤觸"直接顯示功能變數標記"之類的選項造成的。花了點功夫才找到設定位置(如下圖)，原來選項的正確名稱是"顯示功能變數代碼代替數值":

關閉上述選項後，文件的顯示便恢復正常，~~經偵訊同事也對亂調選項一事坦承不諱~~經訊問後確認同事曾試調過此部分的設定，可能當時動到而不自知。

本案順利終結!

【茶包射手日記】RDLC報表出現記憶體不足錯誤

2012-01-12T00:30:00Z

RDLC比Reporting Service靈活彈性，不需要依賴額外的伺服器，評估起來是很優秀的報表解決方案。

很放心地鼔吹將專案中的報表逐一汰換成RDLC，直到~~我膝蓋中了一箭~~最近踩到一顆地雷..

專案有個RDLC查詢報表，大約近萬筆資料，每筆約20個欄位，資料量稍多但還不致令人髮指，執行時卻常常發生記憶體不足(Out of Memory)錯誤! (有時是第一次執行OK，第二次就出現記憶體不足)

檢視報表設計，發現其中用了很多Expression寫法處理資料格式轉換，例如: [=Fields!ColumnA.Value & vbCrLf & Fields!ColumnB.Value]、[=Format(Fields!MyDate.Value, "MMMM")]…。直覺上這些額外運算遍佈在每一筆資料的各欄位中，一旦資料筆數眾多就會被反覆執行，預期會消耗大量記憶體及CPU，懷疑有可能就是導致記憶體不足的元凶。

查了資料，在Microsoft Connect找到兩篇相關回報，證實了此一假設:

其中網友MikeGCompass明確地重現了問題:

I have 2 very simple reports one with an expression and another almost identical but it doesn't contain any report expressions.
ReportBad.rdlc has 1 expression and everytime you generate the PDF it grows in memory, so after a few executes you can have my simple EXE holding on to 1GB or more of memory.
ReportGood.rdlc has 0 expressions and everytime you generate it does not grow in memory.
Thus I conclude using expression columns causes some resources never to be released, even when you dispose the report viewer control.

而在我們的案例中，問題報表在移除Expression後，記憶體不足的狀況確實也消失了。

依此看來，RDLC存在著因Expression導致Memory Leak的Bug，且到VS2010的版本為止尚未解決。目前較可行的解決之道，是在RDLC中避用Expression寫法，例如: 在SQL查詢語法中就預先做轉換，或是先將資料匯入DataTable再進行"後製"，會造成些許不便，但尚在可接受範圍之內，在Bug被修復前，就採取"RDLC中儘可能避免使用Expression運算式"的策略避避風頭吧!

AJAX式資料清單的新選擇-Kendo UI Grid

2011-12-31T10:23:00Z

這幾年在專案中，針對表格式資料的呈現，我多已摒棄PostBack寫法，改用AJAX動態提取方式處理換頁、排列、重新查詢等資料查詢需求，如此可避免傳統PostBack時畫面會閃一下的缺點，提供使用者較流暢的操作感受。

前陣子寫過一篇筆記: Telerik RadGrid AJAX更新範例，介紹的便是應用Telerik的RadControls for ASP.NET AJAX元件庫，實現純AJAX式資料來源的GridView。不過，該元件基於ASP.NET AJAX Client Library並非jQuery，加上元件為ASP.NET控制項，不能安插於純HTML網頁中，限制較多；之前還介紹過另一套Telerik Extensions for ASP.NET MVC，是以jQuery為基礎打造的Client-Side Library，但它主要設計在ASP.NET MVC cshtml中被呼叫，若要在非ASP.NET MVC環境中使用，需要花功夫自己包Plug-In。(是的，這事兒我也幹了...)

本月初(2011/12)，Telerik推出了Kendo UI Framework，一套以HTML5 + jQuery打造的精緻UI元件組，依循如Telerik RadControls for ASP.NET的傳統，照例網羅了日期選擇器、頁籤、選單、Grid、TreeView... 等網頁開發會用到的大小控制項，一方面善用HTML5 + CSS3的威力，另一方面繼續保持跨平台相容(跨IE, Firefox, Chrome, Safari, Opera等瀏覽器, 但HTML5支援度較差的IE7/IE8也OK，還支援WP7, iOS及Android等行動裝置)，看起來是純Client-Side元件的一項不錯選擇。

在授權上，Kendo UI跟Extensions for ASP.NET MVC一樣採雙授權方式: 商業版本可享有技術支援，每月更新，並可包在商品中發行販售；GPL授權則提供每季更新的開放源碼，若只應用在自己開發的網站中，不會再將網站程式本體作為商品販售散佈，理論上均可自由取得及修改，即使網路對外營運也在合法授權範圍內。(網站引用GPL元件授權議題可參見上回討論)

從此，要在網站專案中實現AJAX式的GridView，又多了一項選擇。這裡就依著上回Telerik RadGrid AJAX更新範例的規格，改用Kendo UI Grid來實做驗證一番! 如下圖，分頁、排序、關鍵字查詢功能都不是問題，看來足以滿足專案的基本需求。

Grid1.htm程式碼如下:

<!DOCTYPE html>

<html>

<head>

    <title>Grid Lab 1</title>

    <!--In the header of your page, paste the following for Kendo styles-->

    <link href="../styles/kendo.common.min.css" rel="stylesheet" type="text/css" />

    <link href="../styles/kendo.default.min.css" rel="stylesheet" type="text/css" />

    <!--Then paste the following for Kendo scripts-->

    <script src="../js/jquery.min.js" type="text/javascript"></script>

    <script src="../js/kendo.all.min.js" type="text/javascript"></script>

    <style>

        body { font-size: 9pt; }

        #dvGrid { width: 500px; }

        span.hi-lite { color: red; }

        #dvGrid th.k-header { text-align: center }

    </style>

    <script>

        $(function () {

            //建立資料來源物件

            var dataSrc = new kendo.data.DataSource({

                transport: {

                    read: {

                        //以下其實就是$.ajax的參數

                        type: "POST",

                        url: "JsonDataSrc.ashx",

                        dataType: "json",

                        data: {

                            //額外傳至後方的參數

                            keywd: function () {

                                return $("#tKeyword").val();

},

                schema: {

                    //取出資料陣列

                    data: function (d) { return d.Data; },

                    //取出資料總筆數(計算頁數用)

                    total: function (d) { return d.TotalCount; }

},

                pageSize: 10,

                serverPaging: true,

                serverSorting: true

});

            //JSON日期轉換

            var dateRegExp = /^\/Date\((.*?)\)\/$/;

            window.toDate = function (value) {

                var date = dateRegExp.exec(value);

                return new Date(parseInt(date[1]));

            $("#dvGrid").kendoGrid({

                dataSource: dataSrc,

                columns: [

                    { field: "UserNo", title: "會員編號" },

                    { field: "UserName", title: "會員名稱",

template: '#= "<span class=\\"u-name\\">" + UserName + "</span>" #'

},

                    { field: "RegDate", title: "加入日期",

template: '#= kendo.toString(toDate(RegDate), "yyyy/MM/dd")#'

},

                    { field: "Points", title: "累積點數" },

],

                sortable: true,

                pageable: true,

                dataBound: function () {

                    //AJAX資料Bind完成後觸發

                    var kw = $("#tKeyword").val();

                    //若有設關鍵字，做Highlight處理

                    if (kw.length > 0) {

                        var re = new RegExp(kw, "g");

                        $(".u-name").each(function () {

                            var $td = $(this);

                            $td.html($td.text()

                           .replace(re, "<span class='hi-lite'>$&</span>"));

});

});

            //按下查詢鈕

            $("#bQuery").click(function () {

                //要求資料來源重新讀取(並指定切至第一頁)

                dataSrc.read({ page: 1, skip: 0 });

                //Grid重新顯示資料

                $("#dvGrid").data("kendoGrid").refresh();

});

});

    </script>

</head>

<body>

<div style="padding: 10px;">

    關鍵字: <input id="tKeyword" /><input type="button" value="查詢" id="bQuery" />

</div>

<div id="dvGrid"></div>

</body>

</html>

後端我寫了一個JsonDataSrc.ashx來負責資料供給，其中程式邏輯與上回RadGrid版本幾乎完全相同。(只要能正確傳回JSON即可，要改寫成PHP、Ruby應該也不會是難事)

<%@ WebHandler Language="C#" Class="JsonDataSrc" %>

using System;

using System.Web;

using System.Web.Script.Serialization;

using System.Collections.Generic;

using System.Drawing;

using System.Reflection;

using System.Linq;

public class JsonDataSrc : IHttpHandler {

    //模擬資料物件

    public class SimMemberInfo

        public string UserNo; //會員編號

        public string UserName; //會員名稱

        public DateTime RegDate; //註冊日期

        public int Points; //累積點數

    static List<SimMemberInfo> _SimuDataStore = null;

    //結果物件

    public class ResultData

        public object Data;

        public int TotalCount;

    public void ProcessRequest (HttpContext context) {

        if (_SimuDataStore == null)

            Random rnd = new Random();

            //借用具名顏色名稱來產生隨機資料

            string[] colorNames = typeof(Color)

                .GetProperties(BindingFlags.Static | BindingFlags.Public)

                .Select(o => o.Name).ToArray();

            _SimuDataStore =

                colorNames

                .Select(cn => new SimMemberInfo()

                    UserNo = string.Format("C{0:00000}", rnd.Next(99999)),

                    UserName = cn,

                    RegDate = DateTime.Today.AddDays(-rnd.Next(1000)),

                    Points = rnd.Next(9999)

                }).ToList();

        string keywd = context.Request["keywd"];

        string sortField = context.Request["sort[0][field]"];

        string sortDir = context.Request["sort[0][dir]"];

        //指定關鍵字時，使用Contains()對UserName進行比對

        var res = _SimuDataStore.Where(o =>

            string.IsNullOrEmpty(keywd) || o.UserName.Contains(keywd));

        if (!string.IsNullOrEmpty(sortField))

            //宣告一個函數可傳回SimMemberInfo之指定屬性值用於依動態欄位排序

            Func<SimMemberInfo, string, string> GetColString =

                (o, c) =>

                    switch (c)

                        case "UserNo": return o.UserNo;

                        case "UserName": return o.UserName;

                        case "RegDate": return o.RegDate.ToString("yyyyMMdd");

                        case "Points": return o.Points.ToString();

                        default: throw new ArgumentException();

};

            if (sortDir == "asc")

                res = res.OrderBy(o => GetColString(o, sortField));

            else

                res = res.OrderByDescending(o => GetColString(o, sortField));

        JavaScriptSerializer jss = new JavaScriptSerializer();

        context.Response.ContentType = "text/plain";

        int pageSize = 10, take = 10, skip = 0;

        int.TryParse(context.Request["pageSize"], out pageSize);

        int.TryParse(context.Request["take"], out take);

        int.TryParse(context.Request["skip"], out skip);

        var paged = res.Skip(skip).Take(take);

        context.Response.Write(jss.Serialize(new ResultData()

            Data = paged.ToList(),

            TotalCount = res.Count()

        }));

    public bool IsReusable {

        get {

            return false;

想馬上實際動手玩的朋友可以試試上述範例程式的線上版。

寫完2011年最後一篇文囉! 準備迎接2012，祝大家新年快樂~~

Live SDK筆記5-SkyDrive Explorer, Windows Phone 7版

2011-12-25T01:36:13Z

一連寫了四篇筆記，介紹了Live SDK，也實際玩過取得使用者Live ID身分、連上SkyDrive等把戲:

埋了這些哽，其實背後我最想做的，是從WP7程式連上SkyDrive!

手機基於儲存空間的限制，以及跨裝置/平台共享的需求，非常需要結合網路儲存空間做為後盾，而WP7配上微軟體系的SkyDrive，感覺上是很棒的組合。

Live SDK有提供WP7專用的元件庫，下載安裝Live SDK後，可在WP7專案參照中找到Microsoft.Live及Microsoft.Live.Controls，學習中心有篇WP7整合Live SDK教學，是很好的入門。

Live SDK提供SignInButton控制項，表面上是顆登入登出鈕，背地則幫我們處理掉在App內嵌瀏覽器載入Live帳號登入網頁以及同意網頁等繁瑣細節，是整合Live SDK最簡便的做法。如果在Visual Studio工具箱沒看到它，可自行找到Microsoft.Live.Controls.dll加入工具箱(如下圖)。

不過，有一點要注意，由於在App運作時，不像在ASP.NET範例中會有Callback.aspx負責接入Authorization Code再呼叫API取得Access Token。請參考註冊App一文第3點提及的做法，申請Client ID時，Redirect Domain請留白，然後勾選"Mobile client app"為"Yes"，如此，此Client ID即可使用httqs://oauth.live.com/desktop做為Redirect Page，並直接取得Access Token，如此在行動裝置上即可獨立運作。

我想試做的玩具是一個SkyDrive簡易瀏覽器，功能跟上一篇的ASP.NET版差不多，取得使用者對wl.skydrive範圍的同意權後，列出使用者SkyDrive下的目錄，點選目錄可展開列出其下的子項目，若是檔案則可進行檢視，不過WP7能支援的檔案格式比PC少，我只先選擇對圖片(jpg, png)及影片(wmv, mp3, mp4)提供檢視功能。

MainPage.xaml放入一個SignInButton及ListBox:

    <Grid x:Name="LayoutRoot" Background="Transparent">

        <Grid.RowDefinitions>

            <RowDefinition Height="Auto"/>

            <RowDefinition Height="*"/>

        </Grid.RowDefinitions>

        <StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">

            <TextBlock x:Name="ApplicationTitle" Text="Mini SkyDrive Explorer"

                       Style="{StaticResource PhoneTextNormalStyle}"/>

            <my:SignInButton x:Name="btnSignIn" Branding="Skydrive"

             SessionChanged="btnSignIn_SessionChanged" CientId="0000000016888888"

             RedirectUri="https://oauth.live.com/desktop"

             Scopes="wl.signin wl.basic wl.skydrive"/>

        </StackPanel>

        <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">

            <ListBox x:Name="DirList" FontSize="36"

                     MouseLeftButtonUp="DirList_MouseLeftButtonUp">

            </ListBox>

        </Grid>

    </Grid>

MainPage.xaml.cs則加入程式邏輯，主要原理是在使用者完成登入及同意後(btnSignIn_SessionChanged事件)建立一個LiveConnectClient，即可使用它呼叫REST API執行各種操作。呼叫結果由client_GetCompleted事件解析，相關的註解說明我附加在程式裡，所以直接看Code:

using System;

using System.Collections.Generic;

using System.Windows.Input;

using Microsoft.Phone.Controls;

using Microsoft.Live;

using Microsoft.Live.Controls;

namespace MiniSkyDriveExplorer

    public partial class MainPage : PhoneApplicationPage

        // Constructor

        public MainPage()

            InitializeComponent();

        private LiveConnectClient client = null;

        private void btnSignIn_SessionChanged(object sender,

            LiveConnectSessionChangedEventArgs e)

            if (e.Status == LiveConnectSessionStatus.Connected)

                DirItem.LiveSession = e.Session;

                client = new LiveConnectClient(e.Session);

                client.GetCompleted +=

                    new EventHandler<LiveOperationCompletedEventArgs>(

                        client_GetCompleted);

                //呼叫me/skydrive，取得根目錄folderId

                client.GetAsync("me/skydrive",

                    new MyUserState(ApiMethod.SkyDriveProp));

        private const string goUpperSymbol = "\t";

        //所有的REST API呼叫動作完成後，都會觸發此段解析回傳結果

        //為降低範例程式複雜度，以下並未包含防呆容錯的邏輯，實際開發時應補上

        void client_GetCompleted(object

                                 sender, LiveOperationCompletedEventArgs e)

            MyUserState state = e.UserState as MyUserState;

            if (state == null) return;

            switch (state.Method)

                //取得SkyDrive主資料夾的folderId

                case ApiMethod.SkyDriveProp:

                    //取出id，列出根目錄下的項目

                    ListFiles(e.Result["id"].ToString());

                    break;

                //取得目錄清單

                case ApiMethod.SkyDriveDir:

                    //由data取得陣列

                    List<object> items =

                        e.Result["data"] as List<object>;

                    if (items != null)

                        DirList.Items.Clear();

                        DirList.DisplayMemberPath = "DisplayName";

                        //加入回上層的邏輯

                        if (folderIdStack.Count > 1)

                            DirItem di = new DirItem(goUpperSymbol, "[..]");

                            DirList.Items.Add(di);

                        foreach (Dictionary<string, object> item in items)

                            DirItem di  = new DirItem(

                                item["id"].ToString(),

                                item["name"].ToString()

);

                            //資料夾時額外取得子項目數

                            if (di.IsFolder)

                                di.Count = int.Parse(item["count"].ToString());

                            else //檔案則取得下載網址

                                di.SrcUrl = item["source"].ToString();

                            //加入清單

                            DirList.Items.Add(di);

                    break;

        //用以保存上層目錄的folderId

        private Stack<string> folderIdStack = new Stack<string>();

        private void ListFiles(string folderId)

            if (client == null) return;

            if (folderId == goUpperSymbol)

                folderIdStack.Pop();

                folderId = folderIdStack.Peek();

            else folderIdStack.Push(folderId);

            client.GetAsync(folderId + "/files",

                            new MyUserState(ApiMethod.SkyDriveDir));

        private void DirList_MouseLeftButtonUp(object sender,

                                               MouseButtonEventArgs e)

            DirItem di = DirList.SelectedItem as DirItem;

            //資料夾的話，繼續展開

            if (di.IsFolder || di.Id == goUpperSymbol) ListFiles(di.Id);

            //否則試著下載回來檢視

            else

                DirItem.Current = di; //將此DirItem設為Current

                NavigationService.Navigate(

                    new Uri("/Viewer.xaml", UriKind.Relative));

為了讓程式更結構化一點，我宣告了一個很簡單的SkyDrive項目物件模型: (即上面MainPage.xaml.cs中所出現DirItem、MyUserState物件的由來)

using System;

using System.Net;

using System.Windows;

using System.Windows.Controls;

using System.Windows.Documents;

using System.Windows.Ink;

using System.Windows.Input;

using System.Windows.Media;

using System.Windows.Media.Animation;

using System.Windows.Shapes;

using Microsoft.Live;

namespace MiniSkyDriveExplorer

    #region 用以記錄REST API呼叫資訊的狀態物件

    public enum ApiMethod

        SkyDriveProp, // me/skydrive

        SkyDriveDir,  // folderId/files

        SkyDriveGetImage,

        SkyDriveGetMedia

    public class MyUserState

        public ApiMethod Method;

        public string FileName;

        public MyUserState(ApiMethod method)

            Method = method;

    #endregion

    #region 簡單的目錄物件

    public class DirItem

        //是否為資料夾

        public bool IsFolder

            get { return Id.StartsWith("folder"); }

        //顯示名稱

        public string Name;

        //foderId或fileId

        public string Id;

        //上層資料夾的folderId

        public string ParentId;

        //若為資料夾時，標示其下項目數

        public int Count;

        //下載來源URL

        public string SrcUrl;

        //顯示名稱，資料夾為[folderName](count)，檔案則為fileName

        public string DisplayName

get

                return IsFolder && !Name.Equals("..") ?

                    string.Format("[{0}]({1})", Name, Count) : Name;

        public DirItem(string id, string name)

            Id = id;

            Name = name;

        //用此靜態屬性當作頁面間的傳遞媒介

        public static DirItem Current = null;

        //供跨頁面共用LiveConnectSession

        public static LiveConnectSession LiveSession = null;

    #endregion

除了SkyDrive清單展示，我另外做了一個Viewer.xaml，用來呈現SkyDrive中的圖片(png, jpg)及媒體檔(wmv, mp3, mp4)。
註: Windows Phone模擬器不支援部分媒體格式，測試前可先看一下MSDN文件，其中有些已註明This codec is unsupported in Windows Phone Emulator的格式，測試前請認清，以免在模擬器上猛試不成白花時間! (謎之聲: 這條註解怎麼隱含著強烈的怨念?)

要從SkyDrive下載檔案，可以透過LiveConnectClient.DownloadAsync輕鬆達成，在client_DownloadCompleted事件中可以直接取得byte[]，十分方便。媒體檔的部分，我還沒試出可以串流播放的做法，所以先採行的方式是先將下載結果存成IsolatedStorageFile，再叫出MediaPlayerLauncher進行播放。程式範例如下:

using System;

using System.Linq;

using System.Windows;

using System.Windows.Controls;

using Microsoft.Phone.Controls;

using Microsoft.Live;

using System.Windows.Media.Imaging;

using System.IO.IsolatedStorage;

using Microsoft.Phone.Tasks;

namespace MiniSkyDriveExplorer

    public partial class Viewer : PhoneApplicationPage

        public Viewer()

            InitializeComponent();

        private string[] imgExts = "png,jpg".Split(',');

        private string[] mediaExts = "wmv,mp3,mp4".Split(',');

        private LiveConnectClient client = null;

        private void PhoneApplicationPage_Loaded(object sender, RoutedEventArgs e)

            if (DirItem.LiveSession == null || DirItem.Current == null)

                return;

            //建立LiveConnectClient

            client = new LiveConnectClient(DirItem.LiveSession);

            client.DownloadCompleted +=

                new EventHandler<LiveDownloadCompletedEventArgs>(

                client_DownloadCompleted);

            //清空內容

            ContentPanel.Children.Clear();

            //取得要檢視的檔案

            DirItem di = DirItem.Current;

            ApplicationTitle.Text = di.Name;

            //由副檔名決定開啟方式

            string ext = System.IO.Path.GetExtension(di.Name).ToLower().TrimStart('.');

            if (imgExts.Contains(ext))

                client.DownloadAsync(di.SrcUrl, new MyUserState(ApiMethod.SkyDriveGetImage));

            else if (mediaExts.Contains(ext))

            //針對媒體檔，比較貼心的方式是透過Streaming方式播放

            //此處只簡單示範整個檔案下載完畢後才撥放

                client.DownloadAsync(di.SrcUrl,

                    new MyUserState(ApiMethod.SkyDriveGetMedia) { FileName = di.Name });

            else

                ContentPanel.Children.Add(new TextBox() { Text = "Unsupported File Type" });

        void client_DownloadCompleted(object sender, LiveDownloadCompletedEventArgs e)

            MyUserState state = e.UserState as MyUserState;

            if (state == null) return;

            switch (state.Method)

                case ApiMethod.SkyDriveGetImage:

                    BitmapImage bmp = new BitmapImage();

                    bmp.SetSource(e.Result);

                    Image img = new Image();

                    img.Source = bmp;

                    ContentPanel.Children.Add(img);

                    break;

                case ApiMethod.SkyDriveGetMedia:

                    //此處採用將檔案下載儲存後再播放的做法

                    IsolatedStorageFileStream fs =

                        IsolatedStorageFile.GetUserStoreForApplication()

                        .CreateFile(state.FileName);

                    e.Result.CopyTo(fs);

                    fs.Close();

                    MediaPlayerLauncher mpl = new MediaPlayerLauncher()

                        Location = MediaLocationType.Data,

                        Media = new Uri(state.FileName, UriKind.Relative)

};

                    mpl.Show();

                    break;

程式實際執行結果如下，按下SignInButton後，畫面會變成Windows Live的登入畫面，使用者輸入Windows Live帳號並同意授權後:

程式便可透過me/skydrive REST API取得使用者SkyDrive根目錄的Id，接著使用folderId/files就可取回該目錄下所有子項目的資訊，以ListBox的方式展示出來。

檢視圖片及影片的範例:

很簡單吧!? 大家一起為WP7 App加入SkyDrive支援吧!

資安新聞筆記-開發網站前該知道的二三事

2011-12-22T16:04:00Z

最近有兩則資安新聞引發我的注意:

資安這檔事是這樣的，平時只會覺得系統被設了一堆限制綁手綁腳，稽核單位訂下的規矩不勝其擾，防毒軟體防火牆是效能毒藥，這一切代價換來多少功效? 卻無人知曉，直到某天豬隊友忽然來報到，才後悔資安防範做得還是太少。

有鑑於對於資安重要性的體驗常來自"多麼痛的領悟"，多遇個幾次，還來不及大徹大悟前，往往命就先去了半條。(甚至歷史上也曾有因資安事件而死的悲慘案例: 因公司產品內含SQL Injection漏洞導致10萬個網站被摧毁，軟體公司LxLabs的老板承受不了壓力，選擇在家中懸樑自盡)

因此，由別人的血淚經驗記取教訓看起來是比較人性化的學習成長途徑，每每看到資安新聞，我都會默默整理分析，找出在這些個案中開發者犯了什麼錯? 尤其是"不管哪種語言、何種平台，一旦誤觸結局都一樣慘"的觀念性錯誤!

或許我們的資安工作未必做得比事件苦主好，但從案例中推敲別人可能犯下的疏失，絕對可以當成借鏡，從中吸取教訓藉以自省，而以這兩次事件為例:

後台與前台的存取管道應加以區隔
在戰場上曝露的面積愈大，中槍風險愈高! 而Internet，就是駭客及惡意者四伏的戰場。金流平台的後台查詢報表完整出現在Google可搜尋範圍，講起來也算一種裸奔行為。
若後台永遠只會由辦公室內存取，就沒有必要架構在Internet可以存取的網段。若後台需開放特定但固定的廠商、客戶存取，則採事先登記，限定來源IP也是能有效縮少曝露面的方法。而最重要的是，無論如何都不應開放匿名存取!
權限管控應落實於頁面層次，甚至功能層次
此點純屬猜測，因金流明細報表原本就設定可匿名存取的機率不高，推測最後曝露的原因來自權限管控設計不良。舉個例子來說，曾看過某個兩光的權限設計只做在選單層次，有權限的人才看得到選項，從URL導向特定網頁。設計者天真地以為: 會到這個網頁來的，一定是選單有出現選項，知道URL才會過來，所以網頁本身未再次檢查權限。假設，若某使用者權限被拔除，但仍可在瀏覽歷史記錄中找到該網址呢? 如果某個有權限使用者把URL記在Word裡，寄給別人參考或檔案被人偷走呢?
選單固然應依使用者權限決定是否顯示選項連結，但在頁面中應該再次檢查使用者身分與權限才是王道，甚至若頁面中各功能權限有別時，別只是把不能用的鈕隱藏起來就算了，應在執行該功能前再做一次檢查。
不要用明碼或加密形式儲存密碼，雜湊才是王道
CSDN密碼外洩的最大敗筆在於密碼是明碼!
如果你有幸被賦與設計密碼相關資料表Schema的重責大任，請切記! 若你設計用明碼方式儲存密碼，你是大豬頭；若你決定用加密方式儲存密碼，你還是豬頭!
較佳的做法是只保存密碼的雜湊值，而不保存密碼本身(明碼或加密後都算)，未來可供比對使用者輸入的密碼是否吻合，卻無法用以反推密碼為何。
如此，使用者不用擔心密碼外洩被第三者知道，系統也不必承擔密碼內容有可能外流的風險。
儲存加密後的密碼雖具初步防護力，一旦加密演算法及金鑰一併失守，照樣一次輸個精光。
那麼，系統不知道使用者密碼，使用者忘記密碼時怎麼辦? 重寄密碼給使用者做為提醒? 請不要再當豬頭了。忘記密碼時，請重設一組隨機密碼寄給使用者，允許其在一段時間內使用它登入系統重設新密碼，要把握"系統永遠不知道使用者的密碼為何，只有權重新指定 "的重要原則。
不要輕忽備份保存的安全性
有些線上系統戎備森嚴，受防火牆層層包圍，想存取需通過層層查驗。當線上資料備分出來後，縱然與線上資料價值相去不遠，但一被封裝在外表平凡的磁帶匣或肥大乏味的ZIP/BAK檔裡，就很容易讓人忽略其重要性與保密需求，於是存取管控嚴謹性一落千丈，甚至為了挪出空間，就隨著一群檔案被移置到某個公共空間，搞不好還被不知情第三者燒成光碟以清出HD空間，又在某天被丟進回收箱...

建議所有寫網站的朋友，不管你用的是什麼語言工具，什麼伺服器平台，都要勤於吸收資安相關知識，對於資安新聞(要用心找，像金流平台裸奔的消息就在一片前縣長夫人看丁字褲的新聞中被無視了)要保持敏銳度，很多的資安惡習或錯誤觀念，都是不受程式、平台疆界限制的，由別人的過失中吸收經驗，才能減少犯錯，降低當上豬隊友的機會!

最後，不能免俗地還是要政策宣導一下，雖然未在本次事件中露臉，但如果你還不認識足以奪走人命的資安事件一哥--SQL Injection，或者能用Parameter寫SQL指令時還是堅持一定自己組字串，請立即雙手打上石膏裝殘，先不要寫任何程式以免禍害千年，感謝您的配合~~

【延伸閱讀】

Live SDK筆記4-SkyDrive Explorer, ASP.NET版

2011-12-15T17:11:08Z

在試過ASP.NET整合Live ID登入後，只取回使用者姓名跟MSN大頭照感覺有點像辦家家酒不夠刺激，Live SDK應該拿來搞點實用的功能才過癮 -- 例如: 瀏覽SkyDrive文件與檔案。

Live Connect API提供了SkyDrive相關的REST API，只要取得Access Token，便可透過API瀏覽、讀取、變更、刪除SkyDrive下的文件、相片、影音等檔案，MSDN上有兩篇不錯的教學文章(入門概念、檔案存取API)可當成動手前的參考。

我的構想是在使用者以Live ID登入時，增加SkyDrive讀取的範圍請求，經同意後，程式先展開使用者SkyDrive的根目錄，列出資料夾與檔案；點選資料夾項目則可展開該資料夾，列出其下檔案與子資料夾；若為檔案，則點選可檢視或下載其內容。(瀏覽器依附檔名自行決定檢視或下載，例如: gif, png, jpg, txt, htm可直接開啟，zip, rar則是下載另存) 簡單來說，就是實現一個只能用來檢視的超陽春SkyDrive檔案總管!

整理需用到的SkyDrive REST API有:

httqs://apis.live.net/v5.0/me/skydrive?access_token=ACCESS_TOKEN
取得使用者SkyDrive主資料夾的folderId
httqs://apis.live.net/v5.0/folderId/files?access_token=ACCESS_TOKEN
列出指定資料夾下的資料夾及檔案項目清單
httqs://apis.live.net/v5.0/fileId/content?access_token=ACCESS_TOKEN
取得檔案屬性，其中location屬性會指向一個可直接下載檔案的URL(格式如: httq://storage.live.com/s1pZfcNs…很長，省略...SotQ/Seattle.JPG)，連向它就可直接下載檔案內容。值得注意的是，前述包含冗長編碼的URL是所謂的Preauthenticated URL，意思是只要得知此連結，將不再做任何權限檢查，任何人都可用它直接下載檔案內容，在開發應用時宜留意此特性，做適當管控及避免外流。

是的，要做到SkyDrive檔案檢視功能，就只需要上述三個API即可搞定。

至於JavaScript操作的部分，我結合了jQuery BBQ外掛的AJAX Hisotry功能，在檢視不同資料夾時指定不同的state，以做到按瀏覽器回上頁也可回上層目錄的效果。除此之外，就是蠻單純的jQuery技巧，補充說明我寫在註解中，程式碼如下:

<!DOCTYPE html>

<html>

<head>

    <title>SkyDrive Test</title>

    <script type='text/javascript'

     src='http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.js'></script>

    <script src="jquery.ba-bbq.js" type="text/javascript"></script>

    <script type="text/javascript">

        $(function () {

            //取得Access Token，未成功登入時傳回null

            function getAccessToken() {

                var session = WL.getSession();

                if (session != null && !session.error)

                    return session.access_token;

                return null;

            //AJAX History支援，state改變時顥示不同資料夾內容

            window.lastId = null;

            $(window).bind("hashchange", function (e) {

                var f = e.getState("f");

                if (f) listFiles(f);

});

            var goUpper = "回上層";

            var frmViewer = document.getElementById("frmViewer");

            //列出檔案

            function listFiles(folderId) {

                if (!getAccessToken()) return;

                //REST folderId/files可列出資料夾下的檔案清單

                WL.api({

                    path: folderId + "/files"

                }, function (res) {

                    var $ul = $("<ul class='f-item' />");

                    //folderId若以"."分成三段，代表非根目錄

                    //增加一個"回上層"連結

                    if (folderId.split('.').length > 2)

                        $ul.append(

                        "<li><img src='images/parent.png' class='icon' />" +

                            goUpper + "</li>");

                    //每個資料夾或檔案對應一個li

                    for (var i = 0; i < res.data.length; i++) {

                        var item = res.data[i];

                        var $li = $("<li />", {

                            "data-id": item.id,

                            "data-count": item.count,

                            "data-name": item.name,

                            "data-parent-id": item.parent_id,

                            "data-link": item.link

});

                        //id若為folder****，表示為資料夾

                        var isFolder = item.id.indexOf("folder") == 0;

                        $li.html(

                            "<img class='icon' src='images/" +

                        //資料夾與檔案Icon不同

                            (isFolder ? "folder" : "save") + ".png' />" +

                            "<span class='item-name'></span>")

                        .find(".item-name").text(

                             item.name +

                        //資料夾時，加顯示其下檔案數量

                            (isFolder ? "(" + item.count + ")" : "")

);

                        $ul.append($li);

                    $("#dFolder").empty().append($ul);

                    frmViewer.src = "";

});

            //下載檔案內容

            function downloadFile(id, name) {

                //REST fileId/content可取得下載檔案內容用的連結

                WL.api({

                    path: id + "/content"

                }, function (res) {

                    if (res.error)

                        alert(res.error.message);

                    else {

                        //res.location指向可直接下載檔案二進位內容的連結

                        //指定成為IFrame.src，

                        //可直接顯示或另存檔案(由瀏覽器依附檔名決定)

                        frmViewer.src = res.location;

});

            //點選檔案項目觸發事件

            $("#dFolder").on("click", "li", function () {

                var $li = $(this);

                //若為回上層，則透過記憶中的前一層目錄回去

                if ($li.text() == goUpper) {

                    $.bbq.pushState({ f: lastId });

                    return;

                var id = $li.data("id");

                if (id.indexOf("file") == 0)

                    downloadFile(id);

                else {

                    //保留目前的folderId供稍後回上層用

                    lastId = $.bbq.getState("f");

                    $.bbq.pushState({ f: id });

});

            $("#bList").click(function () {

                if (!getAccessToken()) return;

});

});

    </script>

    <style>

        table { width: 400px; }

        td { border: 1px solid gray; }

        div { margin: 2px; }

        #dFolder li { color: white; text-decoration: underline; cursor: pointer; }

        .bw-style { background-color: Black; color: White; }

        .bw-style .icon { width: 16px; height: 16px; vertical-align: middle; }

    </style>

</head>

<body>

<h1>SkyDrive Test</h1>

<table>

<tr><td style="width: 120px; vertical-align: top;">

<div id="signin"></div>

<div id="meName" class="Name"></div>

<div id="meImg"></div>

</td><td style="vertical-align: top;" class='bw-style'>

<div id="dFolder">

</div>

</td></tr>

<tr><td colspan="2">

<iframe style="width: 100%; height: 400px;" id="frmViewer"></iframe>

</td></tr>

</table>

<script src="wl.debug.js" type="text/javascript"></script>

<script type="text/javascript">

    $(function () {

        WL.Event.subscribe("auth.login", function () {

            var session = WL.getSession();

            if (session.error)

                alert("Error:" + session.error);

            else {

                var token = session != null ? session.access_token : null;

                if (token != null) {

                    var url = "https://apis.live.net/v5.0/me/picture?access_token="

                    + escape(token);

                    $("#meImg").html("<img src='" + url + "' />");

                    WL.api({ path: "me", method: "get" }, function (response) {

                        if (!response.error) {

                            $("#meName").html(response.name);

});

                    //取得SkyDrive Id，透過AJAX History方式觸發瀏覽

                    $.bbq.pushState({ f: "" });

                    WL.api({

                        path: "me/skydrive"

                    }, function (prop) {

                        $.bbq.pushState({ f: prop.id });

});

});

        WL.Event.subscribe("auth.logout", function () {

            $("#meImg,#meName").html("");

});

        WL.init({

            client_id: "0000000048076EE5",

            redirect_uri: "http://www.darkthread.net/LiveSDK/callback.aspx",

            scope: ["wl.signin", "wl.basic", "wl.offline_access", "wl.skydrive" ],

            response_type: "code"

});

        WL.ui({

            name: "signin",

            element: "signin"

});

});

</script>

</body>

</html>

程式執行起來的樣子如下圖，右方是檔案清單，下方放了一個IFrame。當點選資料夾(前方圖示為資料夾)時，清單會變成該資料夾展開後的項目；當點選檔案清單中檔案項目(前方Icon為小磁片)，IFrame.src將指向該檔案的下載網址，若是圖檔可直接顯示，其他如ZIP檔等，則可另存新檔。(但有個小缺點，另存新檔時，SkyDrive伺服器傳回內容未提供檔名，預設URL中又臭又長像亂數的編碼預設會被當成檔名，故需要人工另外命名再存檔，此點可透過另外寫個Download Proxy ASPX來解決，但為避免失焦，並未納入範例中）

還有一點值得注意，相較於前次整合Live ID登入範例，這回我們還增加了wl.skydrive讀取範圍(Scope，可參見前文)，因此同意頁面(Consent Page)可看到SkyDrive的提示(下圖紅框)。

另外，要弄出上圖中文版登入及同意網頁有個小訣竅: 依文件的說法，我們可由http://js.live.net/v5.0/zh-tw/wl.js取得正體中文版的JavaScript Library，但目前這個版本的最下方仍設定了wl_app._locale = "en";，其中的訊息也都還是英文。因此，呼叫Live帳號登入視窗時仍會顯示英文介面。暫時解法是將wl.js另存一份，並修改為wl_app._locale="zh-tw";，網頁改用此修改版就可以獲得中文版登入及同意畫面囉! 但有個缺點，未來若wl.js改版，修改版wl.js不會自動更新，我想不久後，等微軟RD真的落實wl.js多國語系化，就不用煩惱了。

程式執行後，我們點開ForApps資料夾，可以看到其下的資料夾結構，共有兩個圖檔，圖檔也可以點選檢視其內容:

跟SkyDrive網頁的瀏覽結果比對，我們查到的結果與ForApps目錄下的檔案項目與內容相符，一個陽春版SkyDrive檔案檢視工具就算大功告成囉!!

Live SDK筆記3-使用Live ID登入ASP.NET網站

2011-12-14T23:13:40Z

Live SDK提供了包含ASP.NET、PHP、WP7、Silverlight、Android、iOS等多個平台的範例程式。既然如此，光說不練未免暴殄天物，就選擇我最熟悉的ASP.NET來實際演練吧!

在github可以取得ASP.NET範例程式，其中OAuthSample只需要一個ASPX，一個HTML，配合Live Connect的現成Javascript Library，可快速實現由Client端取得使用者MSN Messenger姓名及個人大頭照，感覺蠻有趣的，我們就用它當敲門磚來練習。
在github可取得Callback.aspx, Callback.aspx.cs及default.html，其中Callback.aspx.cs需要修改，需填入Client ID、Reidrect Page網址以及Client Secret:

    public partial class Callback : System.Web.UI.Page

        private const string wlCookie = "wl_auth";

        private const string clientId = "0000000048076EE5";

        private const string callback =

        "http://www.darkthread.net/AspNet4/LiveSDK/callback.aspx";

        private const string clientSecret = "3n6YXboo5wnfooJwrbo0800092000dPd";

default.html的部分原本只需指定Client ID及Redirect Page網址，但我加入jQuery做了比較大幅度的改寫，讓程式簡潔一些: :P

<!DOCTYPE html>

<html>

<head>

    <title>Windows Live Test</title>

    <style>

        <!--

        .Name

            font-family: Segoe UI, Verdana, Tahoma, Helvetica, Arial, sans-serif;

            font-weight: bold;

-->

    </style>

    <script type='text/javascript'

     src='http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.js'></script>

</head>

<body>

<h1>Windows Live Test</h1>

<div>

<div id="signin"></div>

<div id="meName" class="Name"></div>

<div id="meImg"></div>

</div>

<script src="//js.live.net/v5.0/wl.js" type="text/javascript"></script>

<script type="text/javascript">

    $(function () {

        WL.Event.subscribe("auth.login", function () {

            var session = WL.getSession();

            if (session.error)

                alert("Error:" + session.error);

            else {

                var token = session != null ? session.access_token : null;

                if (token != null) {

                    var url =

        "https://apis.live.net/v5.0/me/picture?access_token=" + escape(token);

                    $("#meImg").html("<img src='" + url + "' />");

                    WL.api({ path: "me", method: "get" }, function (response) {

                        if (!response.error) {

                            $("#meName").html(

                                response.first_name + " " + response.last_name);

});

});

        WL.Event.subscribe("auth.logout", function () {

            $("#meImg,#meName").html("");

});

        WL.init({

            client_id: "0000000048076EE5",

            redirect_uri: "http://www.darkthread.net/AspNet4/LiveSDK/callback.aspx",

            scope: ["wl.signin", "wl.basic", "wl.offline_access"],

            response_type: "code"

});

        WL.ui({

            name: "signin",

            element: "signin"

});

});

</script>

</body>

</html>

網頁在一開始載入wl.js(如果要研究或偵錯，可改用wl.debug.js未壓縮版)，複雜工作都已被封裝在現成的Javascript函數中，我們只需要:
1) WL.Event.subscribe("auth.login", fn) 指定使用者已登入或登入完成時要執行的動作
2) WL.Event.subscribe("auth.logout", fn) 指定使用者登出時要執行的動作
3) WL.ui() 指定在<div id="signin">自動加上登入登出按鈕
4) WL.init() 指定Client ID, Redirect Page及存取資料範圍(Scope)
(範圍部分指定了三項: wl.signin是指當使用者已登入過其他Live Connect服務時在本網站可自動登入, wl.basic用來存取基本資料, wl.offline_access用來確保可在使用者未登入MSN時也能取得資訊，關於範圍的定義，前文有較多介紹)

WL.init()時指定response_type: "code"，因此將會依循Authorization Code Grant Flow 運作(可參考前文)，運作時會先跳出Live帳號的登入及同意授權畫面(Consent Page)，當若使用者同意後，網頁會被導向Redirect Page(Callback.aspx)以Query Sting帶入code=authorization_code參數。Callback.aspx.cs中有邏輯會將所傳入的authorizationcode配合Client ID、Client Secret送至httqs://oauth.live.com/token驗證，取得Access Token並寫入Cookie，前端即可應用它進行後續存取。
要測試偵錯時有個小技巧，因Live Connect API只接受當初註冊Domain的網頁作為Redirect URL，因此若要在本機執行偵錯，指向localhost是不可行的。較簡單的克服方法是修改system32/dirvers/etc/hosts，將註冊的Domain(我的例子中是www.darkthread.net)暫時指向127.0.0.1，如此httq://www.darkthread.net將被導向本機的IIS，導向Redirect Page時，實際上會在本機執行。
將程式部署到IIS網站上，開啟default.html即可看到如下畫面，wl.js依我們的指示在<div id="singin">裡放入了一顆Sign in鈕，按下後會彈出來自live.com，大家很熟悉的登入畫面。這代表在整個授權過程中，我們的程式完全不參與登入過程，不會接觸到帳號密碼，使用者也不必擔心自己的密碼透露給第三方網站知道，這是OAuth機制的重要精神所在。
登入完成後，使用者會進入授權同意畫面(Consent Page)，其中列舉的授權項目，一一對應到程式所要求的wl.sigin, wl.basic, wl.offline_access等範圍。
一旦使用者同意授權，WL.Event.subscribe("auth.login", fn) 的函數會被觸發，但此時Callback.aspx已先在背地裡完成一連串動作: (即前文所說的Authorization Code Grant Flow)
* Live Connect導向Callback.aspx?code=authorizationcode
* Callback.aspx接收authorizationcode，加上Client ID, Client Secrect當成參數呼叫httqs://oauth.live.com/token，取得Access Token
* 將Access Token以Cookie方式傳回
使用Visual Studio中斷點偵錯或用Fiddler可以觀察到這段過程:
由於Callback.aspx已透過Cookie傳遞了Access Token，使用JavaScript由WL.getSession().access_token可取得Access Token，呼叫httqs://apis.live.net/v5.0/me/picture?access_token=…可以顯示使用者的MSN大頭照，使用WL.api()呼叫"me"取回User Object(背後是呼叫httqs://apis.live.net/v5.0/me/ REST)，可得到first_name及last_name，呈現在網頁上，就完成了Live Connect API的"Hello World測試"囉!

我放了一個線上展示，有興趣的人可以玩看看。

Live SDK筆記2-註冊App與基本術語

2011-12-13T22:25:31Z

跟Google Map、Facebook、Plurk等API一樣，程式要引用Live Connect API前，必須先註冊以取得一組專屬Client ID與Client Secret(相當於密碼)作為識別。使用自己的Live帳號登入Live Connect Developer Center後即可免費申請(注意，Metro Style App的申請方式不同)。

使用Windows Live帳號(Live ID，即Hotmail/MSN Messenger用的帳號)登入Live Connect開發者中心，可在My Apps介面為App申請Client ID。申請時要填寫應用程式名稱以及使用語言:
完成後可取得一組Client ID及Client Secret，稍後在程式中會用到。
在程式型OAuth授證流程中，需要一支Callback網頁程式(稱之為Redirect Page)保存Client Secret，並與Live Connect API溝通以取得Access Token，基於安全管控理由，必須事先登錄Redirect Page所在網域。該組Client ID在使用時，將只會允許該網域下的網頁作為Redirect Page，在我的案例中，Redirect Page網頁未來會放在 www.darkthread.net 網站下，故填入http://www.darkthread.net 。(針對行動裝置或桌面程式的授權流程，因無Server端Redirect Page，可改用特殊 httqs://oauth.live.com/desktop替代之，此時Redirect domain留空，Mobile client app請選Yes。)
除了上述設定，還可另外自訂應用程式的名稱、Logo、服務條款、隱私權聲明等資訊，將來會出現在請使用者確認同意App要求權限範圍(Scope)的Consent Page(同意頁面)上，Live Connect開發者中心有篇文章提供了詳細的出現位置示意圖。

完成以上設定，理論上可以開始應用它連接Live Connect，但在此之前，先補充一些文件常出現的術語: 註: OAuth協定的技術細節蠻複雜的，在此只簡單列舉一些閱讀MSDN文件會用到的術語觀念。MVP小朱之前曾寫過一系列介紹文章(而且還實做了一套Open Source的OAuth .NET程式庫)，另外Level Up也有一篇簡介，有興趣的朋友可以參考。

【OAuth角色】

Resource Owner
有權授與受保護資源存取權限的個體，例如: 一般使用者
Resource Server
保存及管理受保護資源的伺服器，如保存信件、連絡人資料的Hotmail伺服器、保存文件、影音相片檔的SkyDrive伺服器
Client
代表Resource Owner要求存取受保護資源的應用程式
Authorization Server
負責驗證Resource Owner身分並獲得授權的伺服器
Resource Owner's Agent (User-Agent)
用以承載Client應用程式的平台，例如: 當Client以Javascript撰寫在瀏覽器中執行，瀏覽器即User Agent

【OAuth Flow】

依循OAuth驗證使用者身分並取得授權的流程，Live Connect支援三種不同流程(詳見MSDN文件):

Implicit Grant Flow
主要應用於網站程式或桌面程式，程式呼叫httqs://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&response_type=token&redirect_uri=REDIRECT_URL，Live Connect提供登入介面及授權同意網頁(Consent Page)，當取得授權後，Live Connect會導向REDIRECT_URL，並在後方加註Acess Token當成參數，程式取出Access Token後，即可用於向Resource Server存取相關資源。
Authorization Code Grant Flow
主要應用於伺服器對伺服器間的驗證流程，Client發出httqs://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&response_type=code&redirect_uri=REDIRECT_URI，接著Live Connect在識別使用者並取得同意後導向REDIRECT_URI並加上&code=[authorizationcode](不是直接給Access Token)，REDIRECT_URI必須是伺服器可執行網頁，將code所傳入的authorizationcode配合Client ID、Client Secret送至httqs://oauth.live.com/token驗證，可取得Access Token，如此可在Access Token完全不外洩的狀況下，在伺服器端使用它向Resource Server取用資源。
Sign-In Control Flow
透過Live Connect提供的登入控制項封裝Implicit Grant Flow流程，只需引用相關的Javascript程式庫或.NET元件，撰寫相關事件邏輯、呼叫適當方法，即可完成登入授權，可大幅簡化自行處理驗證授權流程的細節。

【Scope】

在取得授權時，必須聲明要存取的範圍(Scope)，同意網頁則會明列Client程式要求的授權範圍，使用者再決定是否同意。一般來說，最好以"足以運作的最小範圍"為原則，可減少使用者疑慮，獲得同意的機會較高，App的操作體驗也會較佳。以下是Live Connect目前定義的Scope範圍: (詳細說明可見MSDN文件)

wl.basic: 取得使用者個人檔案(Profile)基本資料及連絡人
wl.offline_access: 允許在使用者離線時繼續取得資料
wl.signin: 單一簽入功能(Single-Sign-On)，若使用者已登入Live Connect則可自動登入該App
wl.brithday: 取得生日
wl.calendars: 讀取行事曆
wl.calendars_update: 更新行事曆
wl.contacts_calendars: 讀取連絡人(含使用者本人)的行事曆
wl.contacts_birthday: 取得連絡人(含使用者本人)的生日
wl.contacts_create: 建立連絡人
wl.photos: 讀取使用者的相簿、照片、影音檔
wl.contacts_photos: 讀取連絡人(含使用者本人)的相簿、照片、影音檔，以其所屬標籤與留言
wl.emails: 讀取使用者私人、偏好及公司電子郵件地址
wl.events_create: 在使用者預設行事曆建立事件
wl.messenger: 允許登入Live Messenger服務
wl.phone_numbers: 讀取使用者私人、公司及行動電話號碼
wl.postal_addresses: 讀取使用者的郵寄地址
wl.share: 允許更新使用者的狀態
wl.skydrive: 讀取使用者的SkyDrive
wl.skydrive_update: 讀取及更新使用者的SkyDrive
wl.contacts_skydrive: 讀取連絡人(含使用者本人)的SkyDrive檔案
wl.work_profile: 取得使用者的僱主及工作位置資訊
wl.applications: 取得使用者的Client ID
wl.applications_create: 建立Client ID

【茶包射手日記】JavaScript Date.getYear()傳回111

2011-12-13T10:11:00Z

接獲使用者回報，某個透過JavaScript取日期的網頁在某些機器上產生的年份有誤，得到"111"的詭異結果!

追蹤程式，發現它是用new Date().getYear()方法取年，而不是大家慣用的getFullYear()。而我們也很幸運地在一台Windows 7 + IE9完成問題重現，getYear()得到111，getFullYear()得到2011:

有趣的是，此時找了另一台Win7 + IE9測試getYear()還真的傳回2011，順利地證實"有些IE9正常取得2011，有些IE9卻傳回111"的現象確實存在。

爬文找到MDN getYear()文件，才發現是自已孤陋寡聞:

getYear()原本用來傳回兩位數的年份，想當然爾肯定有Y2K問題，故早已不再建議使用。(是誰寫進程式裡的，踹供!)
為了向前相容，至今getYear()仍然繼續可用，針對超過2000的年份，會傳回getFullYear() - 1900，所以2011 - 1900 = 111，這就是111的由來。
如果是1900以前，則傳回負數，例如: 1895 - 1900 = -5。

換句話說，依此原則傳回111才是對的，傳回2011反而是錯的(跟原本認知相反)。而看完Mozilla官方文件，我心中對於"同是IE9，行為卻不同"也有了答案。推測是努力向HTML業界標準看齊的IE，終於從IE9起洗心革面改掉getYear()行為，以求與眾家瀏覽器一致!

把IE9的文件模式改成IE8再試一次，果然就傳回2011(如下圖)，證實我的推論: 之所以在不同IE9上得到不同結果，乃源於文件模式不同，在IE9+標準文件模式下，getYear()才會得到111；當IE9開啟相容模式(或使用IE7, IE8)時，則會得到2011。

最後補充MSDN文件作為呈堂證供: (很有趣的一點，遠古時代的IE3跟IE9的行為是一致的，都是getFullYear() - 1900；而IE4到IE8，則是1900至1999傳回兩位數，範圍之外傳回四位數)

In Internet Explorer 3.0, and then in Internet Explorer versions starting with Internet Explorer 9 standards mode, the value returned is the stored year minus 1900. For example, the year 1899 is returned as -1 and the year 2000 is returned as 100.

In Internet Explorer 4.0 through Internet Explorer 8 standards mode, the formula depends on the year. For the years 1900 through 1999, the value returned is a 2-digit value that is the stored year minus 1900. For dates outside that range, the 4-digit year is returned. For example, 1996 is returned as 96, but 1825 and 2025 are returned as is.

另外的結論是: 將來誰再敢寫.getYear()，一律阿魯巴伺侯!!