目前習慣是把後台的認証是做在 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產生，有點煩
網路上雖有一些解法，但我想還是要求下廣告時，要注意網址問題


 

對於網頁加速的問題，已經被廣泛的討論了
主要在於減少 request 數以及減低網路傳輸的時間
也因此發展出一些技巧或技術，例如 css sprite, 資料gzip 等
瀏覽器也把連線數限制從2條變成6條，以加快網頁顯示的速度
然而若要網頁能有本質上的提升，則是該把 HTTP 這個老通訊協定升級了
(目前是HTTP/1.1, 1999年)

由Google Chrome推廣的 SPDY 標準，已經改良並訂為 HTTP/2 的標準 (2015年初定案)
他的重點在於 (如果我理解得沒錯的話，歡迎指正)
1. http header 也可壓縮 (HTTP1.1 header 無法壓縮)
2. 一個 connection 可以傳輸多個Content (HTTP1.1 一個request 一個 content)
3. 可以 Server Push 資料
4. 可以向下相容 1.1
實測上，可以讓網頁載入速度提升約 30%

目前，大部分瀏覽器已經支援 HTTP/2 標準，然而 Server 端的步調就緩慢許多
微軟的 IIS 要到 10 才支援，目前只有 windows 10 才有
Windows Server則要明年 2016 才有支援
相反於微軟，其他非微軟的開發速度上就快多了 例如 Node.js

---------------------------------------------------------
測試上，可以用 Chrome 的開發模式 把 protocol 欄位勾選顯示



h2 就是 http/2

有個排程會超過 900 秒，結果發現每天跑 20 次

原因是 wget 預設超過 900秒無回應，會再發一次 request，預設會試 20次
所以遇到會跑超過15分鐘的排程，要加上以下參數
-t1  或是 --tries=1  讓排程只跑一次

昨晚突然出現大量的Exception，發現是某個IP攻擊網站，所以就直接使用IIS擋IP方式阻擋該IP的攻擊，但是設定之後，發現Exception還是一直出來。但是束手無策....直到一個多小時後才停止攻擊。

事後翻出IIS Log看結果



發現IIS擋IP有發揮作用(status:403) 但是會有漏網之魚(status:302-其實status是500)
檢查 "23:10:46" 一秒內受到 36 次攻擊 但是漏掉了 8 個 -> 失敗率約兩成

結論:
1. 對於阻斷攻擊，可能還需要程式上做處理，例如 begin_request 時檢查
2. Log Parser 真是看 log 最佳工具....

自從網站上了 net4.0 之後，網站會有為數不少的 "潛在危險" 的 exception
大都來自不友善的攻擊，想要測試網站的漏洞
網站做這層防護是好事，只是這個東西太敏感了，連簡單的冒號 & 符號都會跳 exception
更慘的是 Google Analytics 會在一些 user cookies 寫入xml文字 ( __utmz=... )
導致正常的 User 都不能正常瀏覽我們網站

解法有兩種:
1. 直接在 web.config 直接設定 不檢查

<system.web>

    <httpRuntime requestValidationMode="2.0" />

    <pages validateRequest="false" />

</system.web>

2. 自訂 RequestValidate (4.0以上才可以用)
請參考此文章 http://msdn.microsoft.com/en-us/library/system.web.util.requestvalidator(v=vs.100).aspx

後者比較算是正解 基本上處理掉 <script 我想 XSS 就解決一大半
 

今天設計反應新增電子報時發生問題
 
 解決方式
1. 先確認 aspx  => ValidateRequest="false
2. 上面如果設定對 

在Web.config中<system.web>中加入

這段 <httpRuntime requestValidationMode="2.0" />就ok了!!!

造成的原因
是.NET 4.0跟2.0版本在請求驗證的定義不同：

ASP.NET Request Validation 請求驗證是ASP.NET提供來保護XSS攻擊的一項功能

在2.0 僅針對.aspx及class進行驗證…

但到了4.0，請求驗認範圍擴大到所有的請求…

而不是只有.aspx，還包含WebService呼叫以及自訂的http Handlers，都會去驗證http請求的內容…

 

今天在觀察 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 裡面沒有加上這個處理吔。

假如你現在在ASP.NET 4.0 的環境下的話，就算進行上述的設定，可能仍會出現驗證失敗的訊息(潛在危險Request.QueryString的錯誤訊息)
因為ASP.NET4.0與2.0版本在請求驗證的定義上已經有所不同：

這時為了避免這樣的問題，一樣在Web.Config中 <system.web>下加入下列語句
<httpRuntime requestValidationMode="2.0" />

http://www.dotblogs.com.tw/pin0513/archive/2010/10/22/18522.aspx

D:\thelifeCSR.txt此檔案即為 CSR [憑證要求檔案]