FDB選擇browser的問題

最近恢復使用fdb來debug swf檔案。但在我的機器上遇到一個麻煩的問題，就是每次都用safari打開debug player，偏偏safari在我的機器上跑得並不順。經過了一些搜尋，找到這一篇：

http://www.jetbrains.net/jira/browse/IDEADEV-34701

處理了一下，很快就能用firefox。但是遇到了一些不明的問題，幾乎不能設定breakpoint。ie就沒有這個問題，我想，單純只是因為ActiveX的架構...

Set Nocount

好吧，我只能說我對adodb生疏太久了，這樣的一個bug居然要快一個星期才找到...

事情是這樣的，我要做一份report，根據年月分，所以我寫了一段這樣的SQL

create procedure get_message_count_by_user
@ctrlId nvarchar(32),
@sdate datetime,
@edate datetime
as

declare @sd datetime, @ed datetime
create table #temp (sd datetime, ed datetime , ctTotal int, ctR int, ctS int, ctnp int)
insert #temp select sdate, edate, 0, 0, 0, 0 from sep_month(@sdate, @edate)
update #temp set ctTotal=t1  
 from (select sd, count(sid) t1 from #temp as s, messageboard 
 where contentdate>=s.sd and s.ed>contentdate and groupno=@ctrlId and deleteUser is null and 
 (status='2' or isnull(returnUser,'')<>@ctrlId  ) 
 group by sd ) as a
 where #temp.sd=a.sd
update #temp set ctR=t1  
 from (select sd, count(sid) t1 from #temp as s, messageboard 
 where contentdate>=s.sd and contentdate<s.ed and groupno=@ctrlId and deleteUser is null and 
 status='2'
 group by sd ) as a
 where #temp.sd=a.sd
update #temp set ctS=t1  
 from (select sd, count(sid) t1 from #temp as s, messageboard 
 where contentdate>=s.sd and contentdate<s.ed and groupno=@ctrlId and deleteUser is null and 
 status='5'
 group by sd ) as a
 where #temp.sd=a.sd
update #temp set ctNP=ctTotal-ctR-ctS

select * from #temp

呼叫這個stored procedure，在asp.net一點問題也沒有，但是在asp中，我就是沒有辦法叫adodb取得#temp中的資料。測試了很久，甚至把stored procedure一行一行拆開來測試，結果發現：Insert #temp select 這一行一加入之後，後面的select敘述就沒有辦法傳回值了。這使得我想起很久很久以前（應該是七年前）我也遇過一個類似的問題，於是把資料庫一個一個找出來，在眾多的stored procedure中搜尋，終於看到一個熟悉的字眼：set nocount。於是在開頭(第六行）跟select * from #temp之前（第29行）分別加上：set nocount on, set nocount off，問題就解決了。

不過說到set nocount，這讓我想起許多陳年往事，還牽涉到一位如今是M$名嘴級的講師。這是個又臭又長的故事，有機會再說。

Safari的強勢推廣

Safari目前市占率約為5%，而蘋果公司3月開始透過iTunes的自動更新大力推廣Safari。這種強勢推廣已有一些效果，根據Net Applications統計，Safari在視窗電腦的市占率3月時成長200%。

這邊的關鍵字是：強勢推廣。嗯，強勢推廣...

DataBinding的問題

從昨天傍晚遇到這個問題，弄了一整夜找不出原因。先把問題記下來，將來再研究為何...

ArticleEntryEditor繼承了DataList，做了一點小修改。

ArticleEntryEditor的EditItemTemplate，用了一個UserControl：ArticleEditorItem

在ArticleEditorItem中，接受一個Item的欄位，型別為ContentItem。用DataBind的<%# Container.DataItem %>之後，ArticleEditorItem 中的 DropDownList 都不會抓到正確的值。應該說，在指定完畢之後，就立刻不見了（回復到選單的第一個值）。可是其他的WebControl不會受到影響。

如果是在OnItemDataBound中，去指定ArticleEditorItem.Item的值，就不會有這個問題。

這個問題應該不是第一次遇到，只是沒有像這次一樣繞路要花很多時間。記下來將來研究。

IPrincipal vs Session Identity Persistence 的思考

為了家總的案子，終於把這一段給弄清楚了...

簡單講IPrincipal的架構：HttpContext.User就是一個IPrincipal，IPrincipal負責標示Role（有個IsInRole的method要實現），也就是負責授權。IPrincipal下面有一個Identity，可以存真正獲得這個Principal的Identity(:IIdentity)。

每次的HttpRequest, Asp.Net都會自動幫我們把IPrincipal與IIdentity處理出來。標準狀況下（使用Forms Authentication，且使用FormsAuthentication.SetAuthCookie的情況下），每個Request獲得的User是一個GenericPrincipal，Identity則是一個FormsIdentity。這往往不是我們要的，所以，我們有兩種作法：

1. 在系統拿到IPrincipal與IIdentity的時候，自己根據取得的IIdentity.Name去把我們要的類別代換。比如我有CDLPrincipal:IPrincipal, CDLIdentity:IIdentity，在Authentication_End的時候，執行

string currentUserId=HttpContext.User.Identity.Name;
HttpContext.Current.User=new CDLPrincipal(currentUserId);

這裡的new CDLPrincipal，基本上就是從Identity Store裡，取出我們要的CDLPrincipal，以及附贈的CDLIdentity。也就是說，在這個過程裡面，HttpContext.Current.User發生了兩次指定的工作：一次是系統做的，一次是我們做的。

2. 如果要只想做一次這個動作，只能我們自己寫Authentication Module。在這種時候，我們要用authentication cookie把所有IPrincipal的內容Serialize（並Encrypt）成一個string，然後指定cookie name，傳給browser。這也是Msdn的標準作法，SetAuthCookie只是這個作法的一個簡易版。這種作法的問題很多，主要authentication cookie這下子可能變得很長，影響頻寬。

第一種作法，可以用HttpModule解決或是用Page_Init，第二種方式就一定是用HttpModule處理。

另外，這跟使用Session比起來有何好處？老實說，除了可以Impersonate之外，我看不出任何好處。但多了一個Auth. Cookie，在頻寬上是有影響的。session的偽冒問題，IPrincipal的作法同樣透過cookie，也不可避免。

這是個值得進一步思考的問題。

Page Inherited Abstract 不能在 VS 2003 中以Design View觀看

這句話的意思是：如果你自己定義了一個繼承自Page的Abstract class，那任何以這個Abstract class延伸的出來的頁面，就不能在Visual Studio 2003中以Design View檢視。

也就是說：

public abstract class BasePage : System.Web.UI.Page {
}

public class adm_user_list : BasePage{
}

其中 adm_user_list是 adm_user_list.aspx的code behind。在這種情況下，adm_user_list.aspx就無法在 Visual studio 2003 下以 Design view 觀看。嘗試這件事情的時候，會得到Type Abstract的錯誤訊息。

也許這本來就是應該的（沒有時間去查清楚Design time support的相關限制），但我還是覺得很奇怪。對所有其他有design time support的server control，當然不應該有abstract的可能，但Page是一個很奇怪的例外。就以上例來說，adm_user_list.aspx已經是BasePage的一個實作子類別，不是一個Abstract Type。而且，就算沒有code behind，所有的.aspx都會由掛在IIS的ISAPI（也就是ASP.NET_xxxxx.dll)先行產生一個class（這裡的例子，會產生ASP.adm_user_list_aspx這個class）。這樣還給我Type Abstract，就會讓人有點三條線的感覺....

巴哈姆特的DDoS攻擊觀後感

http://home.gamer.com.tw/blogDetail.php?owner=sega&sn=2512

這是一篇讓人看了生氣的文章，顯然巴哈姆特賺到了錢，卻不知道該有付出。看到了這一篇回應真是大爽，放在這邊紀念。

我說：站長，您別鬧了。從4/27日起到今天，如果您還用這些技術人員一看就穿幫的理由來說明你們無法阻斷DDoS攻擊，我覺得您只有兩個選擇：

1. 把你們的 CTO Fire掉
2. 把這個站關了

DDoS不是什麼了不起的攻擊，這種2000年就出現的攻擊方式，如果在2008年的今天大家還不知道怎麼處理，Yahoo、Google這些公司不就不用混了？

從IP下手？六百多個網段所以不能防阻？我的老天，什麼時代了還用IP在做事？現在的DDoS防制設備是怎麼操作的？可以有哪些設定進行有效防阻？攻擊到今天已經第三天了，如果對這個最基本的問題，您還不知道正確的答案，結論就是選擇一：Fire掉你的CTO，趕快到遊戲公司挖個網管的高手。

所以，您應該知道，解決方案早就在那邊，只是要不要用。這種花銀子就可以解決的事情，對以「開網站、賺銀子」的貴公司來說，不是該有最基本的自覺嗎？剛剛順便看了一下貴公司的里程碑，發現原來貴公司早就知道您已經是台灣「第三大站」。第三大站一個月會花掉多少頻寬費用呢？這些頻寬費用跟DDoS防制硬體的費用比起來，大概這些硬體看起來也就不貴了吧？第三大站的經營者對於「保護自己的網路財產與商譽」這件事情，怎麼還有學生的心態呢？一開始看到聯合報的報導，還覺得您有些值得同情。但是看到您的這篇聲明，我只能勸你做第二個選擇：

關站吧！沒有基本自覺的人，是不配經營網路的生意的！

一個2003年以前是個瘋狂Gamer留

然後我覺得應該要檢舉站長的違規行為，於是我寫了下面的東西

違規事由：散播病毒

信件內容

1. 一些傳統的防禦方式在這裏也派不上用場，比如說擋ip，因為以我們觀察到的ip就有數千個之多，而且來自於多達600多個的網段

2. 就算是加防火牆，也得是夠高級的防火牆，否則防火牆也是會不堪負荷而無法運作，結果是一樣的

3. 這種攻擊沒有根本的解決辦法，只能做消極性的防禦，包括增加伺服器數量、架設專用防火牆、以及降低伺服器負載等方向

違規理由

1. 傳遞對於阻擋DDoS攻擊之錯誤技術訊息（這年頭誰用IP阿，靠！）

2. 解決這種狀況的DDoS硬體，是跟防火牆分開賣的，而且，跟頻寬費用比起來，「高級」的產品也不貴

3. 沒有身為台灣「第三大網站」經營者之自覺，明明是不願意花錢購買正確的硬體，養正確的網管人員，卻教導其他不名就裡的遊戲玩家使用錯誤的思維解決問題

以上三點，罪無可赦！來人阿，拖出去斬了。

我只能說，我真是太無聊了....