這是指網址列的參數未經處理直接丟回頁面造成的問題.

例如 a.aspx 中, 參數 R 會被丟回頁面, 則 <a href='http://yahoo.com/a.aspx?R=<script>...</script>'>Yahoo 大拍賣</a> 這種網址放在某人的 blog 中, 點選的人已登入 yahoo, 那就中奬了, script 中的程式可以把你的 cookie 丟到其它的網站去, 或是用你的身份做一些其它的事情..

自從 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點最高??

 

這是 Shopunt 安裝新機器時發生的問題，把他記一下

安裝 黑貓 EGS SERVICE，只要把另一台server C:\EGS 整個目錄 copy 過來
然後跑 C:\EGS\EGS_SETUP.exe  就會跳出 Ezcat Gateway System 視窗
然後只要 "啟動EGS系統" --> windows 服務 就會出現 Ezcat Gateway System Service

這個服務會建立 web service 並監聽 8800 port
http://localhost:8800/egs?cmd=......   就可以存取資料

但要注意的是，由於整個目錄複製過來，會將 sqllite 資料也一併複製過來，這樣會產生一個問題
就是黑貓的配送單號會重複產生，所以新server一定要做一件事

就是 停止EGS服務 -> (系統維護) -> 備份EGS資料 -> 存檔
然後再 還原EGS資料 -> 找出剛剛備份檔  -> (系統資訊) -> 啟動EGS服務
若是看到托運單號是 100 整數  應該就是 reset成功






 

有時候用 jQuery 使用 event 物件時，會發現有些特殊事件的 property 抓不到 (undefined)
例如
mousewheel --> event.wheelDelta 
drop --> event.dataTransfer
touchstart --> event.touches[0].pageX
原因是 jQuery 的 event 只會包裝一般的屬性，特別的屬性要使用 event.originalEvent 去抓
event.originalEvent 是瀏覽器原生的 event

It's also important to note that the event object contains a property called originalEvent, which is the event object that the browser itself created. jQuery wraps this native event object with some useful methods and properties, but in some instances, you'll need to access the original event via event.originalEvent for instance. This is especially useful for touch events on mobile devices and tablets.

所以開發時當有些特殊屬性抓不到時，可以考慮用 event.originalEvent 去抓看看

    // 這是用滾輪放大縮小圖片 (此範例firefox不支援)

    $("#imgProductBig").bind("mousewheel", function (ev) {

        var delta = ev.originalEvent.wheelDelta > 0 ? 1 : -1;

        if (delta > 0 && zoomValue < 150) {

            zoomValue += 10;

        }

        else if (delta < 0 && zoomValue > 50) {

            zoomValue -= 10;

        }

        $(this).css("zoom", zoomValue + '%');

        return false;

    });

 

對於PC版大尺吋的螢幕，當網站要 feed 資料到 facebook 時，可以使用 javascript SDK 的
FB.ui => method:'feed' 方式處理，參考位置。此方法會popup小視窗讓user可以分享資料出去。

但是遇到手機版網頁就有點麻煩，實測上手機版的 chrome 會出現轉不停的情況，無法分享；而iPhone則是另開新頁面處理，可以成功但是會多一個分頁。所以手機版網頁建議使用 redirect 方式處理分享機制，參考位置
​

    var fbUrl = "https://www.facebook.com/dialog/feed?" +

    "app_id=122465741241119&display=touch" +

    "&link=" + encodeURIComponent("http://www.shopunt.com/tch/FixPage.aspx?id=525") +

    "&picture=" + encodeURIComponent("http://www.shopunt.com/tch/event/2014-nail-enrollment/fb_200x200.jpg") +

    "&description=" + encodeURIComponent("市價不斐的光療DIY教學，UNT傾囊相授！10場巡迴免費教學，讓妳輕鬆掌握光療DIY訣竅，並搶先體驗秋冬最新流行色！現場打卡，再送時尚美甲工具組") +

    "&redirect_uri=" + encodeURIComponent("http://www.shopunt.com/tch/event/2014-nail-enrollment/Handler.ashx?fun=FBCallback");

​

當然以 redirect 處理與 javascript 方式處理是兩種不同的方式，redirect 方式的 callback 網址 (redirect_uri)要接收facebook 導回的 post_id , javascript 方式則是 callback function 處理 post_id

Convert.ToInt32 vs Int32.Parse
這兩者的差別在於 Convert 物件可傳入的值型別比較多，也可以傳入 null (Nothing) => 0
Int32.Parse只接受 string, 遇到 null (Nothing) 會引發 exception
轉換效能上 Int32.Parse 較佳，但除非是很大量的運算，兩者之間差別微乎其微

若擔心傳入的字串不是數值 會引發錯誤
除了可以使用 try catch 包起來 也可以用 Int32.TryParse 來處理

若是遇到 DB 的資料要轉換 記得要判別是不是 DBNull

Dim intCount As Integer = If(Convert.IsDBNull(row("count")), 0, Convert.ToInt32(row("count")))

// C#

int intCount = Convert.IsDBNull(row("count")) ? 0 : Convert.ToInt32(row("count"));

 

http://graph.facebook.com/?id=http%3A%2F%2Fwww.shopunt.com%2FShowPicture.aspx%3FPic%3D20140610133552854

小計：Format(Order_Main.Total_訂單層級的購物原始金額_包括產品單價的折價, "#,###,##0")
Order_Main.Total_訂單層級的購物原始金額_包括產品單價的折價 = Me.Total + Me.Deduct_Amt + Me.CouponAdd
Order_Main.Total = 當下所付的現金
Order_Main.Deduct_Amt = 當下U幣使用多少(已經除以30成為台幣了)
Order_Main.CouponAdd = 某些CouponCode會讓商品變貴，例如Global的自由選。

U幣折抵金額：Format(Order_Main.Deduct_Amt, "#,###,##0")
Order_Main.Deduct_Amt = 當下U幣使用多少(已經除以30成為台幣了)

GetE_coupon折抵金額：Format(Order_Main.CouponDiscount, "#,###,##0")
Order_Main.CouponDiscount是指訂單成立當下所有coupon加起來的金額～
如果想要知道細項，只能反查V_UsedCoupon，查看當下有哪些Couponcode有被使用。
也因為是後來才法查的，因此若是coupon設定與當下不符合，數字很可能就會對不起來了～
couponcode.IsExtraInput AndAlso oUC.CouponCode.Length > 0 
可用來判別是否需要手動輸入couponcode

折讓：Order_Main.Amount_Shortage - (Order_Main.TotalDiscount_訂單層級的折抵_不包括子訂單的折價 - Order_Main.Deduct_Amt - Order_Main.CouponDiscount)
Order_Main.TotalDiscount_訂單層級的折抵_不包括子訂單的折價 = Me.Discount + Me.Loyalty_Reward_Used + Me.Welcome_Reward_Used + Me.Deduct_Amt
折讓 = Order_Main.Amount_Shortage - (Me.Discount + Me.Loyalty_Reward_Used + Me.Welcome_Reward_Used + Me.Deduct_Amt + Me.CouponDiscount) + Order_Main.Deduct_Amt - Order_Main.CouponDiscount
折讓 = Order_Main.Amount_Shortage + Me.Discount + Me.Loyalty_Reward_Used + Me.Welcome_Reward_Used
有可能是正的～也可能是負的～
'訂單管管理頁面可以填寫 補差額 折讓 兩個欄位 http://zxp09.dev.shopunt.com.tw/Admin/Order/OrderEdit.aspx?page=1&Id=163761
'補差額是一個品項 想像成一個不會出的商品 用來讓整筆訂單變貴的方式～
 

Question :  update sql 若有簡體字. 會出現? 
Sol :   '  '   在加字串第一個的 ' (單引號)  前 加上 N  (大寫)
資料庫型態須定義為 ntext 或是 nchar , nvarchar
若定義成一般習慣前面未加 'N' 使用 Big-5 
 

此次電子發票因為配合財政部政冊,我們做了UNT前後台及Turnkey較體的修正,原定2013/12/31將前後台相關程式上線,
2014/1/2再將Turnkey切換成MIG 3.1版本,但是這次上線後發生了幾個狀況...這和上線前未測試完全有關
1.前台於95 84皆未測試到Repay,上線後才想到,還好在上線當天有完成修正
2.後台未測試發票列印,1/2出貨選擇紙本發票的訂單並未隨貨印出,1/3一早才發現程式並未上線至正式台,立即將他上線
即時的解決方法:
1.Repay因在上線當天就發現,所以在上線後一一測試排除了,但三聯式發票的Bug比較麻煩,無法立即處理
2.1/2未印出的發票,我們寄出了一封通知信給那374位未收到發票的顧客,發票依舊由雅卡西亞託管,並會在3/25為他們對獎,
  且讓無發票印列記錄的訂單皆可在前台點選得到"索取紙本發票",1/25之後由我們每天檢查是否有發票索取

必免未來發生相同的錯誤,以後應該:
1.程式未上線至正式台前,需將程式需求中的每一個項目皆測試到,最好可以做一個測試列表勾選
​ (是不是可以做一個程式有修改的清單,上線前可檢查是否有全數更新到?)
2.只要有關購物車中的購買相關程式,皆需測試到Repay
3.最好能想好程式如果無法如期上線的備案

不知還有麼要注意的,大家給點建議吧!