想到的先列出來.

1. 幫 String 擴充屬性(javascript, .NET)
2. SQL Injection.
3. Cross Site Script Attack.
4. 避免排程未完全執行以及重覆執行.
5. 更新 Cache 與 Lock.
6. SQL Transaction.
 

lock 的 object 和 cachename 最好是相關的.

ex: lock (S3.LockObjs.GetLockerObject(CacheName))

內容後補..

目前習慣是把後台的認証是做在 Master Page 裡面,

另外發現一個可以做登入檢查的地方:

lobal.asax 裡的 "Application_AcquireRequestState" 這個會發生在 Page_PreInit 之前, 而且可以使用 Session 變數. 也可以抓到所有的 Cookie.

不過剛發現一個情況, / 的 request 會執行

Application_BeginRequest
Application_AuthenticateRequest
Application_AuthorizeRequest
Application_ResolveRequestCache
Application_AcquireRequestState
Application_PreRequestHandlerExecute

兩次,

而且第一次是沒有 Session 的.. 

還要再研究....
 

錯誤訊息如下, 完全沒有錯誤訊息, 以及沒有錯誤的程式碼位置

 <Item time="2016-01-11T05:39:01" page="/fr/iconic-bright-cushion-spf-50-pa-nude-perfection-compact-foundation/p/5490/c/30"

url="http://www.shopunt.com/fr/iconic-bright-cushion-spf-50-pa-nude-perfection-compact-foundation/p/5490/c/30?utm_source=edm&amp;utm_medium=email&amp;utm_content=20160107_cushion_4&amp;utm_campaign=makeup&amp;OutAD_Id=5825" username="Not Member" browserName="Chrome" browserVersion="34.0" userAgent="Mozilla/5.0 (Linux; Android 5.1.1; SAMSUNG SM-N915FY Build/LMY47X) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/2.1 Chrome/34.0.1847.76 Mobile Safari/537.36" RemoteIP="37.160.206.7" Ref="No Ref" RequestType="GET" Ver="3">

    <ErrMsg>

    </ErrMsg>

    <ErrStack> 於 System.Web.CachedPathData.ValidatePath(String physicalPath)

於 System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)</ErrStack>

    <Post>

    </Post>

    <Cookie>

    </Cookie>

</Item>

查了一下，原來網址後面多了空白 (%20) , 也就是 ? 前面多了空白
只是exception物件會自作聰明把他濾掉了，反而從 exception log 看不到資料
測試過，userd可以正常看網站，只是server會有不斷 excetion產生，有點煩
網路上雖有一些解法，但我想還是要求下廣告時，要注意網址問題


 

自從 8/1 起 shopunt 就呈現奇怪的現象



基本上是每日半夜12點流量暴增 (peak 到 80mb)，然後逐漸下降，到了 5~6點又慢慢爬升，直到 10 點以後就驟降

基本上，網站沒有掛掉，沒有太多Exception，LB兩台server的流量很平均，Server Diff 查也沒有過多的Session
可以排除被攻擊的可能性

為了找問題，只好從 IIS Log著手......
1. 首先，查詢12點有甚麼網頁或網址異常多點擊數，並且比較 11 點與 12點兩者差異，結果都沒有任何異常
    卻意外發現有家廣告合作廠商半夜會來抓產品圖，只是這個流量不大，發生點也不是在12點整，不是兇手
2. 起先因為 IIS log 沒有設定 sc-bytes 這個屬性，只有 time-taken 屬性，發現有些圖片 load 的特別久，但還是無法確定問題，所以想說把 sc-bytes 加到 IIS log 再來觀察
3. 加了 sc-bytes 之後的 IIS log，才發現驚人的事實，有幾張圖片竟然高達好幾MB，最大張是放在周年慶的 landing 圖片，竟高達 7.8MB



光1小時，一張圖片吃掉 8.6GB 的量，換算平均值約 13 mb/sec , OMG!
趕緊請設計把圖片換掉

只是這樣，還是有一個奇怪現象，為何半夜12點流量暴增，早上 10 點流量驟減?


這是禍首最大張圖片的點擊數統計(時間是GMT，16是半夜12點, 15是晚上11點)，
就跟流量圖一樣，00~10 點擊數很高，其他時間很低
下面是這張圖片所屬頁面的點擊數統計 (/tch/fixpage.aspx?id=689)



從圖片點擊數看來，我以為是 ISP 某種 transparent proxy cache 發揮作用 (半夜 00~10點關閉 所以流量增加)，
但是看到 fixpage.aspx 的點擊數也是一樣的狀況，我就不知道該怎麼解釋了??
ISP transparent proxy 也會處理 *.aspx ?? 

還是回歸到最基本的原因，網站的廣告曝光量是 00~10點最高??

 

http://lifeofageekadmin.com/fixing-windows-2008-r2-activation-errors/

​Location is at C:\windows\system32\Slmgr.vbs
/ckms = clear all KMS servers in cache and set to auto discover
/skms :  = Specify a KMS host server
/ipk  = Enter in a new license key
/ato = Activate the new key
/dlv = Display license information
First open a command prompt and try to register a license key. This example is for Windows 2008 R2 Enterprise Edition.
C:\> Cd c:\windows\system32
C:\Windows\system32>cscript slmgr.vbs /ipk
C:\Windows\system32>cscript slmgr.vbs /ato
If you receive activation successful you are complete. If you receive a 0xC004F074 error do the following.
C:\> Cd c:\windows\system32
C:\Windows\system32>cscript slmgr.vbs /ckms
C:\Windows\system32>cscript slmgr.vbs /ipk
C:\Windows\system32>cscript slmgr.vbs /ato
If you receive activation successful you are complete. If you receive a 0xC004F074 error again or another error do the following.
C:\> Cd c:\windows\system32
C:\Windows\system32>cscript slmgr.vbs /rilc
Reboot
C:\> Cd c:\windows\system32
C:\Windows\system32>cscript slmgr.vbs /ckms
C:\Windows\system32>cscript slmgr.vbs /ipk
C:\Windows\system32>cscript slmgr.vbs /ato
More information can be found at Configuring KMS Clients

網站開發，善用 Cached DataTable 可以使網站效能倍增，不必一直去資料庫抓資料。
但是使用 Cached DataTable 有一個地方要注意
就是他是 Shared 物件，表示同時有好幾個頁面都可以存取他

例如A網頁將資料抓出，然後變更裡面的DataRow資料，
另一個B網頁也會跟著變更

由於 Cached DataTable 在 Set DataRow Value 時
可能 Critical Section 沒有處理好，若真的同時多個thread 操作
會出現 Exception
(System.ArgumentOutOfRangeException: 索引超出範圍。必須為非負數且小於集合的大小。)

建議:

• Cached DataTable 最好是只能用來讀，不要Set Value
• 若需要Set Value，可以使用 DataTable Copy()功能，先複製出來再操作，就不會影響到原始資料

            '這是 UNT FixPage 物件抓取單一資料的範例

            Shared Function GetSpecialPage2FromCachedDT(ByVal Key As Int32) As DB.SpecialPage2

                Dim DT As DataTable = GetAllDataFromBaseTableWithCache()

                Dim Row As DataRow = DT.Rows.Find(Key)

                If Row IsNot Nothing Then

                    '避免每個thread都共用table 寫入資料會出現問題

                    Dim newDT As DataTable = DT.Clone()

                    newDT.ImportRow(Row)

                    Return New SpecialPage2(newDT.Rows(0))

                Else

                    Return Nothing

                End If

            End Function

當我們網站裡的某個網址要分享到 facebook 時，
facebook 會主動到我們網頁擷取內容，然後存在cache裡
facebook 給開發人員一個頁面可以測試看看結果
https://developers.facebook.com/tools/debug/og/object/ 
可以貼上自己網站的某個網址 ex.
http://www.shopunt.com/eng/unreal-touch-mineral-powder-blush/p/1129/c/34
就可以看到 facebook 爬到的結果，如果上次爬的是很久以前，這個地方也可以重新爬一次

----------------------------------------------------------------
經由測試結果，發現這功能出現的圖片，跟實際上在網站裡點fb分享出現的內容還是有差異
想出現的圖片還是不能控制，根據[此文章]說明
要把 og: 所有屬性都加上才行
header 圖片部分最好再加上

<link href="圖片連結網址" rel="image_src" type="image/jpeg">

應該就能保證分享圖片是自己想要的。 --> 這有空再來測試好了
 

今天在觀察 Chrome 怎麼處理網頁中的 <script type="text/javascript" src="/scripts/unt.14.04.10.19.05.42.js"></script>  時，終於明白何時才會 200 (From Cache) (unt.14.04.10.19.05.42.js 是假的，實際會被重導到 scripts.aspx 來處理。)

1. 在網址列，同網址再按一下  Enter 載入時，Chrome 會對相同的網址再次送出 request。

2. 若是點選頁面中的連結或是在網址列輸入其它網址，才有可能看到 200 (From Cache)

在情況 1 時，若是有使用 Response.Cache.SetLastModified(Now) 則會看到 304 ，否則會把 Script 重新載入一次。

所以在 Server 最佳的(我覺得)寫法是:

Response.Cache.SetCacheability(HttpCacheability.Private)

Response.Cache.SetExpires(Now.AddYears(1))  '一年後才會到期，沒有這個就不會有 200 (From Cache)

Response.Cache.SetLastModified(Now)  '若是 Browser 送出了一個新的 Request, 有可能會回 304

不過有趣的是，在 scripts.aspx 收到帶有 ​If-Modified-Since 的 Request 時，是怎麼判斷要回應 304 的，我在 .vb 裡面沒有加上這個處理吔。

SqlDependency 的原理是對某些目標 table 設定所謂的 ChangeId
資料存在 dob.[AspNet_SqlCacheTablesForChangeNotification]
當目標 Table 有 Insert, Update, Delete 時會 Trigger 把 ChangeId + 1
而前端網站就是不斷定時詢問此 [AspNet_SqlCacheTablesForChangeNotification] 的 ChangeId

-- 新增目標 Table 加入 SqlDependency (此範例 MenuFirst是 table name)

Exec dbo.AspNet_SqlCacheRegisterTableStoredProcedure N'MenuFirst'



-- 直接變更 ChangeId (效果等同於去變更該table資料)

-- 會去將 ChangeId + 1

EXEC dbo.AspNet_SqlCacheUpdateChangeIdStoredProcedure N'MenuFirst'

AspNet_SqlCacheUpdateChangeIdStoredProcedure 通常是不需要做的
因為目標table都有設定 Trigger
但是在某些狀況下 目標table資料沒有變更 但是也希望前端cache要更新
就可以用此 SP