請輸入你的公司信箱、員工編號與分機以確認身分。
此驗證僅比對公司內部人員資料,供內部同仁確認身分使用。勾選「記住本機這次輸入的資料」會把登入成功時的三項資料存在這台裝置的瀏覽器裡,下次開啟才能自動帶出;沒有勾選則不會保存,重新整理或關閉分頁都要重新輸入。
這裡有查詢工具與各月份原始資料,下載前需要密碼確認。
點下面任一個檔案即可下載,第一次使用請先下載「查詢工具」。
這一頁放的是未經彙整的每日明細(含總代/子代編號),比其他分頁更敏感,即使已經個人登入,還是要再輸入一組團隊共用密碼——跟以前下載查詢工具用的解壓縮密碼相同,沒有的話向提供帳號給你的人索取。
| 遊戲 | 市場・類型 | Grade | Status | Score | 稼動週數 | 近8週走勢 | 建議措施 | 下次複核 |
|---|
這一頁依照每個分頁的順序,逐一說明畫面上每個數字、標籤、顏色代表什麼意思——不需要懂遊戲產業或資料分析背景也能看懂。想知道完整計算公式的人,可以看最下方的「技術細節」。
這一頁的用途:幫每一款遊戲打一個綜合成績(S~E 六個等級),並標出它「最近的表現方向」是變好還是變差,不用逐一看數字就能快速抓出哪些遊戲該加碼、哪些該留意。
這張圖用兩個軸把所有遊戲排開來看:
看這張圖的重點:右上角(等級高、方向往上)最值得放大投入;左下角(等級低、方向往下)最需要處理。
先看每一週的分數:不是絕對分數(不是說 90 分就代表「很棒」),而是「這款遊戲那一週跟同期其他遊戲比起來排在前面還是後面」換算出來的相對名次分數,滿分 100,50 分(含)以上算「達標」。
再把每一週的分數累積起來算出評等分數——從正式上線那一週開始,每一週都要交代:
| 那一週的情況 | 怎麼計分 |
|---|---|
| 週分數 ≥ 50(達標) | 照實把分數計入 |
| 週分數 < 50(未達標) | 該週以 0 分計入(交白卷) |
| 完全沒有資料(代理還沒開通、系統問題等外在因素) | 整週跳過,不算分子也不算分母 |
評等分數 = 達標週的分數總和 ÷ 有效週數
所以評等同時反映「撐多久」和「撐得多強」:兩款都跑 10 週的遊戲,週週 90 分的評等會明顯高於週週壓線 55 分的。中間掉下來幾週的遊戲會按「沒達標的比例」被稀釋,但之後表現回升,分數也會慢慢爬回來。
| 等級 | 評等分數 | 意思 |
|---|---|---|
| S | 90 分以上,且四維度參考分數也要 ≥ 90 | 長期穩定維持在市場前段,而且四個面向全面表現優異——新舊兩套標準都達標才給 S |
| A | 80~89 分(或評等已達 90 但四維度未達標) | 表現優異且相當穩定 |
| B | 65~79 分 | 表現中上 |
| C | 50~64 分 | 表現中等,或高分但中間斷過幾週 |
| D | 30~49 分 | 表現偏弱,達標的週數不多 |
| E | 30 分以下 | 表現落後;分數為 0 代表上線以來從沒有任何一週達標 |
| 觀察期 | 不看分數 | 有效週數還不滿 5 週,樣本太少暫不給正式評等(上線 2 週都 80 分就變 A,跟穩跑 30 週的遊戲平起平坐並不合理) |
S 級為什麼要「新舊都達標」:只看評等分數的話,一款遊戲只要押注排名長期穩定就能拿到 S,但它可能只有「商業產出」這一個面向強、其他面向普通。所以 S 額外要求舊制的四維度參考分數也要 ≥ 90,確保是四個面向全面優異的遊戲。評等分數已達 90、但四維度沒過的,會降為 A 並標上 準S 標籤,代表「離 S 只差全面性」。
因為週分數是以「市場中位數」為 50 分的相對排名,任何市場在任何時候本來就約有一半遊戲在 50 分以下,所以 E 級遊戲佔比偏高是正常現象,不代表資料有問題。
評等和「稼動週數」是兩個不同的指標,用同一份週分數但彙總方式不同,數字對不上是設計如此:評等把破功變成扣分(之後回升還能爬回來),稼動週數則是「破功即永久凍結」。評等回答「這款遊戲在這個市場的整體定位」,稼動週數回答「連續維持了多久、何時破功」。
這四個面向目前只是參考資訊,不決定 Grade(評等只用上面的週分數累積計算)。保留下來是為了在判斷一款遊戲該往哪個方向改善時,能多看幾個面向。
| 面向 | 佔比 | 白話意思 |
|---|---|---|
| 商業產出 | 25% | 這週的押注量,在同期遊戲裡排第幾 |
| 玩家投入度 | 20% | 平均每個玩家玩了幾局,排第幾——局數多代表玩家比較投入 |
| 活躍度 | 30% | 老玩家在這週玩家裡佔的比例高不高(估算方式見下方提醒) |
| 生命週期走勢 | 25% | 最近幾週的表現是否穩定,不是只看單一週的好壞 |
「活躍度」用的是「這週玩家裡有多少比例是老玩家」來估算,不是追蹤同一批玩家隔天、3天、7天後有沒有回來玩的傳統留存率——因為目前拿到的資料沒有玩家帳號層級的追蹤,無法做這種逐人追蹤,只能用「老玩家佔比」概略估計老玩家活躍的相對高低,數字僅供參考方向用。這個提醒之後在「週期報告」分頁的活躍度欄位也適用。
Grade 回答「現在多強」,Status 回答「正往哪裡走」——同樣是 B 級,成長型代表正在變好、衰退型代表正在變差,接下來該做的事完全不一樣。判斷方式是看這款遊戲最近每一週有沒有「達標」(達標大約等於商業產出排到市場前半段),再看達標/不達標的連續狀況:
| Status | 白話說明 |
|---|---|
| 潛力型 | 才剛開始被追蹤(不到 2 週資料),還看不出明確方向,先觀察 |
| 成長型 | 目前是達標的,而且是最近才剛回穩、或持續達標還不滿 3 週——正在往上走的階段 |
| 穩定型 | 已經連續達標超過 3 週、中間沒中斷過,表現穩定 |
| 衰退型 | 目前未達標,但只是最近(4 週以內)才開始走下坡 |
| 弱勢型 | 目前未達標,而且已經連續 4 週以上沒達標,表現不好一段時間了 |
矩陣下方是完整清單,點欄位標題可以排序:
| 欄位 | 意思 |
|---|---|
| 市場・類型 | 屬於哪個國家/幣別市場,以及是老虎機(SLOT)、捕魚機(FISH)、棋牌類(CASINO)、街機(ARCADE)還是活動遊戲(EVENT) |
| Grade | 等級(見上方),旁邊的箭頭是跟上一週比較:紅色▲分數上升、綠色▼下降。標有準S的,代表評等分數已達 S 門檻、只差四維度不夠全面 |
| Status | 方向(見上方) |
| Score | 評等分數(達標週分數總和 ÷ 有效週數),也就是換算出等級的那個分數 |
| 稼動週數 | 官方認定的連續達標週數——這個數字有個容易誤判的特性,詳見「稼動指數」分頁說明 |
| 近8週走勢 | 最近 8 週分數變化的小圖表 |
| 建議措施 | 依等級給的建議方向(例如加大投入、觀察、下架評估) |
| 下次複核 | 建議下次重新檢視這款遊戲的時間 |
點任一列可以展開看更詳細的診斷內容跟走勢圖。
這一頁的用途:把「稼動週數」背後的完整歷史攤開來看,因為官方稼動週數的算法有一個容易誤判的盲點。
跟「遊戲等級」的關係:兩者用的是同一份每週分數,但彙總方式刻意不同,所以數字對不上是正常的,不是資料錯誤——
・遊戲等級:把破功那週變成 0 分計入平均,之後表現回升,分數會慢慢爬回來。回答「這款遊戲的整體定位如何」,給所有人快速判斷用。
・官方稼動週數(這一頁):破功就永久凍結,之後回穩也不再累加。回答「連續維持了多久、何時破功」,給產品製作人深入觀察用。
官方稼動週數的算法是:從第一週開始只要每週都達標,數字就一直往上加;但只要有一週沒達標,數字就會永久停在中斷前的位置,即使遊戲後來表現又回穩了,官方數字也不會再往上加。這代表兩種完全不同的情況,可能會顯示出同一個數字——「一路穩定達標 10 週後才中斷」跟「達標 3 週後中斷、但後來又回穩表現很好」,官方數字都定格在中斷前那個數字,看不出後面其實有回穩。這一頁就是為了讓你看到完整的真實歷史,不被這個「凍結」規則蓋住真相。
| 元素 | 意思 |
|---|---|
| 週次色塊 | 每個方塊代表一週,裡面數字是那一週的分數,顏色越深代表分數越高。排列方向是新→舊、左到右(最新一週在最左邊,不用捲動就看得到),色塊區下方有小字標註這個方向 |
| 卡片第一行、等級左邊的箭頭 | 跟上一週比較:紅色▲上升、綠色▼下降,旁邊數字是漲跌百分比 |
| 持續/中斷 色條 | 把整段歷史切成一段一段,標出每一段「持續達標幾週」或「中斷幾週」(這一條仍是舊→新排列,跟上面色塊的新→舊方向不同,是兩種獨立的呈現方式) |
| 上架至今總週數 | 累積的「有效週數」——有資料且日均人數達門檻、算得出週分數的週數,不會被中斷規則影響。完全沒有資料的週(代理未開通等外在因素)不列入計算,所以這個數字可能小於日曆上的週數 |
| 官方稼動週數 | 套用「一中斷就凍結」規則算出來的數字,跟上面那個數字差越多,代表中途中斷過越久 |
如果歷史超過 26 週,較早的部分會收合成一塊摘要方塊(顯示「+N週」,放在色塊區最右邊,因為那是最舊的一段),點開能看到那段期間達標/未達標各幾週,統計不會漏算,只是不佔畫面空間。
這一頁的用途:不看單一遊戲的「等級」,而是看「這一天/這一週,相對上一天/上一週,哪些遊戲漲最多、哪些跌最多」,並附上像產品經理一樣的判斷——哪些值得加碼、哪些要提高警覺,不是單純把數字複誦一次。
每日:跟前一天比較。每週:跟前一週比較(週一到週日算一週)。每月:跟上個月比較(自然月)。三種都只有「整個週期的資料收齊」才會產生一則,所以最新一則通常是「上一個」週期而不是「這一個」——目前這個週期還沒過完,資料還不完整。
| 元素 | 意思 |
|---|---|
| 今日評語/本週評語 | 整體大盤的判斷,不是把每個數字都列出來,而是挑出真正需要注意的重點——例如漲跌是否集中在特定市場、有沒有已經連續好幾期下滑的個案 |
| 各市場評語 | 針對馬來、越南、菲律賓(以及菲律賓合規 OKBET)各自的判斷,見下方「機會/風險」說明 |
| 幣種/遊戲類型篩選 | 可篩選只看特定市場或特定遊戲類型(老虎機/捕魚機/棋牌/街機/活動遊戲),下方數字跟表格會跟著篩選條件變化 |
| 總押注/總營收/總局數 | 目前篩選條件下的加總數字,附上跟上一期比較的漲跌幅 |
| 當日(日均)人數 | 不重複人數,不是把每款遊戲的人數加總——同一個玩家玩了三款遊戲不會被算成 3 個人。人均押注/人均局數的分母也跟著用這個數字,不是加總值 |
| 三張表格 | 「總押注前10名」是金額最大的遊戲;「前10名」是漲幅最大的;「後10名」是跌幅最大的——表頭可點擊排序,「名次」欄固定不變 |
不是單看押注金額漲跌,而是同時檢查押注、營收、人數、局數、活躍度這幾個面向是不是「同時」往同一個方向走——只有一個數字在動、其他都沒動,比較可能只是短期波動;多個面向同時往同一個方向走,才會被標記為真正的機會或風險,並附上關鍵數字:
名稱長得像「遊戲名 X 品牌名」的遊戲(例如某款遊戲搭配某代理的客製版本)不會被選為評語裡的舉例對象,因為這類版本是特定代理專屬的推廣商品,漲跌不代表遊戲本身的自然表現——但這些遊戲的押注金額仍會算進所有加總數字裡,不會漏算。
這一頁的用途:這個網站的資料是每天早上自動更新的,這一頁記錄「每一次自動更新有沒有成功」,方便確認今天看到的資料是不是最新的。
| 元素 | 意思 |
|---|---|
| 雲端月份zip同步 | 是否成功從雲端資料夾下載當月的整包資料(例如8月是202608.zip),並補齊本機還沒有的每日檔案(2026-08-19起改用這個方式,取代原本的 Telegram 收檔) |
| 雲端資料彙總 | 把雲端資料夾裡所有每日檔案彙總起來的結果,包含資料筆數、涵蓋天數 |
| 分級計算 | 重新計算所有遊戲 Grade/Status 的結果 |
| 每日/每週/每月漲跌記錄 | 是否成功產生「週期報告」分頁的最新內容(每週只有星期一、每月只有每月1號才會真的執行) |
| 打包上傳(2026-08-20起停用) | 把查詢工具打包上傳到雲端資料夾供人下載——自架伺服器上線後「遊戲資料」分頁改直接查詢,不再需要這一步,只留在舊紀錄裡 |
每一則記錄點開能看到詳細內容;哪個步驟失敗,會顯示紅色「失敗」標記跟錯誤原因。
這一頁的用途:如果需要查詢或匯出最原始、還沒經過任何計算的每日數據(例如要給別人做進一步分析),可以在這裡篩選日期、市場、遊戲後匯出成 CSV 檔案。透過自架伺服器(http://…:8080)瀏覽時,點這個分頁按鈕會先跳出密碼確認彈窗,輸入一組共用密碼(跟以前下載查詢工具用的解壓縮密碼相同)成功才會真的切換過去、直接向伺服器查詢,不用再安裝、執行任何本機工具;同一次登入只要解鎖過一次,之後再點就不會重複跳窗。透過分享出去的靜態連結(claude.ai)瀏覽時,因為那個版本沒有連接後端,仍會照舊顯示下載查詢工具的步驟。
以下是給想了解完整計算公式的人看的,一般使用不需要懂這些。
第一名不是滿分 100——遊戲數越多,最高分才越接近 100;最後一名恆為 0。比較範圍內遊戲數太少時 PR 值會失去意義,同一名次在不同週可能對到不同 PR 值。
原始資料只有「總代」「子代」兩層代理架構,把子代當成最細的排名單位,逐層「先排名、再加權」收斂上去:
| 步驟 | 在哪裡排名/怎麼加權 | 收斂到 |
|---|---|---|
| ① 子代內排名 | 該子代當週有資料的所有遊戲,依總投注排名 → PR 值 | 子代分數 |
| ② 依 SiteRatio 加權 | SiteRatio = 該子代整體押注 ÷ 該總代整體押注(不分遊戲) | 總代分數 |
| ③ 依 OwnerRatio 加權 | OwnerRatio = 該總代整體押注 ÷ 該幣別整體押注(不分遊戲,不再重新排名) | 市場分數 |
權重用的是子代/總代的整體押注佔比(不分是哪款遊戲),只有分子(要收斂的分數)才是這款遊戲的——只在單一小總代上架但表現優異的遊戲,市場分數依然可能很高,市場分數不反映鋪貨廣度。
| 第幾週 | 加權分數 | 稼動週數 |
|---|---|---|
| 1 | 65 ✓ | 1 |
| 2 | 70 ✓ | 2 |
| 3 | 45 ✗ 破功 | 2(凍結) |
| 4 | 80 ✓ | 2(仍凍結) |
| 5 | 85 ✓ | 2 |
PR 值以 50 分為門檻,代表在任何比較範圍內大約有一半的遊戲會被判定破功,無論這群遊戲整體表現是好是壞。新遊戲有另一道起算門檻:該幣別日均 DAU 合計超過 50 的那一週才開始列計,之前的週次完全不出現在報表上,不會顯示為 0。
架構異動:新增 Flask+waitress 後端(server/app.py),登入後資料改成前端打 API 即時拿,不再整包寫死在 HTML 原始碼裡;沒有有效登入 session 的請求,伺服器端直接回絕(403),不是畫面用 CSS 藏起來而已。
Session:改用伺服器簽章的 session cookie(HttpOnly、SameSite=Lax),狀態存在伺服器這邊,不是瀏覽器分頁的 JS 記憶體——重新整理頁面會維持登入,這是跟舊版刻意不同的行為(舊版重新整理必須重新登入),换來的是限流狀態不會再被重新整理繞過。
分頁權限:「排程記錄」改成伺服器依 session 裡的 is_admin 判斷要不要回傳資料,不是前端隱藏按鈕——實測非管理者帳號直接打 /api/schedule 一樣被拒絕。
遊戲資料分頁新增密碼閘門:這一頁放的是未經彙整的每日明細(含總代/子代編號),比其他分頁的彙整數字更敏感,即使已經個人登入,點分頁按鈕時會先跳出密碼確認彈窗,輸入這組團隊共用密碼(沿用原本下載查詢工具用的解壓縮密碼)成功才會真的切換過去,失敗或取消畫面都留在原本的分頁、不會露出任何內容;伺服器端只存密碼雜湊,這個密碼閘門本身也有獨立的依IP限流。同一 session 只要解鎖過一次,之後再點這個分頁就不會重複跳窗;也不用再安裝、執行 query_server.py 這個本機小工具了。
登入紀錄新增IP與國家:伺服器直接看得到每個請求的來源IP,登入紀錄改成伺服器端記錄「所有人」的登入(含來源IP、IP所在國家、裝置),取代舊版只能看到「這台裝置自己記錄過的登入」;因為集中了所有員工的真實IP,比排程記錄/資安檢測更敏感,這一頁也限定 admin 才能查。國家查詢用離線的 GeoIP 資料庫(geoip2fast),不會把任何人的IP送到外部服務;LAN 內網連線目前都正確顯示「區域網路」,不會硬湊一個沒有意義的國家。
已知限制:目前還是 LAN-only 的純 HTTP(還沒綁網域、還沒上 HTTPS),帳密在區網內傳輸沒有加密——如果之後要跨網段開放或 LAN 本身不算可信任,要先補 HTTPS 才能繼續往外開。限流/session 狀態存在伺服器記憶體裡,伺服器程式重啟後會全部歸零(不是漏洞,只是重啟後的正常行為,之前的鎖定會一起消失)。遊戲資料頁的密碼閘門是「團隊共用密碼」等級的保護、不是逐人身份驗證,拿到密碼的人都能查——這跟以前下載查詢工具用的保護等級一致,不是升級也不是降級。
| # | 測試項目 | 結果 | 測試方式 | 關鍵結果 |
|---|---|---|---|---|
| 1 | 未登入打 /api/games | PASS | Flask test client 直接呼叫,繞過畫面 | 403,不回傳任何資料 |
| 2 | 未登入打 /api/schedule | PASS | 同上 | 403 |
| 3 | 已登入非管理者打 /api/schedule | PASS | 手動設定 session(is_admin=False)後呼叫 | 403——伺服器端真的擋下來,不是畫面隱藏按鈕而已 |
| 4 | 已登入管理者打 /api/schedule | PASS | 同上(is_admin=True) | 200,正常回傳 |
| 5 | 已登入但未解遊戲資料密碼,打 /api/facets、/api/query、/api/export | PASS | 三個端點各自呼叫 | 皆回 423(已定義的「鎖定中」狀態) |
| 6 | 點「遊戲資料」分頁按鈕(尚未解鎖) | PASS | 瀏覽器實測點擊分頁按鈕,直接讀取 DOM 狀態確認 | 立即跳出密碼彈窗;分頁本身仍是 hidden、分頁按鈕仍停在原本分頁的 active 狀態——分頁沒有真的打開 |
| 7 | 彈窗輸入錯誤密碼 | PASS | 瀏覽器實測輸入錯誤密碼 | 彈窗顯示「密碼錯誤」且不關閉,遊戲資料分頁依然是 hidden,沒有打開 |
| 8 | 彈窗輸入正確密碼 | PASS | 瀏覽器實測輸入正確密碼 | 彈窗關閉、分頁才真的切換過去並顯示查詢介面(880萬列、日期範圍 2026-01-01~08-18),不用再安裝本機工具 |
| 9 | 解鎖後重新整理頁面再點分頁 | PASS | 瀏覽器實測重新整理後再點「遊戲資料」 | 不會再跳密碼彈窗,直接開啟查詢介面(同一登入 session 內解鎖狀態延續) |
| 10 | 登出後遊戲資料解鎖狀態 | PASS | 呼叫 /api/logout 後再打 /api/facets | 變回 403(整個 session 一起清空,不會殘留解鎖狀態) |
| 11 | 遊戲資料密碼連續錯誤 25 次 | PASS | 同一 IP 連續呼叫 /api/rawdata_unlock | 觸發 429,獨立於登入限流,不互相污染 |
| 12 | 安全性標頭 | PASS | curl 檢查真實回應標頭 | CSP/X-Frame-Options: DENY/X-Content-Type-Options: nosniff 都存在 |
| 13 | 機密檔案/原始碼路徑直接存取 | PASS | curl 打 /server/roster_secrets.json、/server/app.py 等路徑 | 皆 404(static_folder 關閉,只有手動定義的路由會回應) |
| 14 | 超大請求本體 | PASS | 送出超過 64KB 的登入請求 | 413,被直接拒絕 |
| 15 | 惡意正規表示式查詢字串 | PASS | /api/query 的 game 欄位帶入 ReDoS 樣式字串 | 當純文字比對處理(regex=False),查詢在 1 秒內正常回應,不會卡住伺服器 |
| 16 | 非管理者打 /api/loginlog | PASS | 手動設定 session(is_admin=False)後呼叫 | 403——登入紀錄新增IP後屬於較敏感資料,限定 admin 才能查 |
| 17 | 管理者打 /api/loginlog | PASS | 同上(is_admin=True)+瀏覽器實測登入紀錄分頁畫面 | 200,正確回傳姓名/時間/來源IP/IP所在國家/裝置,私有IP正確標示「區域網路」 |
驗證方式:PBKDF2-HMAC-SHA256,每位員工各自一組隨機 salt(16 bytes),迭代次數 210,000 次(原目標 600,000,實測 51 筆名單全比對耗時 3.3~4.0 秒太慢,降到使用者指定的安全下限後約 1.4~1.5 秒)。三項資料合成一組字串時採「長度前綴」固定格式,逐筆比對到底、不提早判斷單一欄位是否存在,比對用固定時間比較函式。
登入狀態:只存在瀏覽器記憶體裡,不寫 localStorage/sessionStorage;重新整理或關閉分頁一律要求重新登入;登出即整頁重新整理,清空所有暫存畫面狀態。
限流:連續失敗 5 次鎖定 30 秒,之後每次再失敗等待時間倍增;鎖定中即使輸入正確資料也會被擋,且不會透露鎖定原因或帳號是否存在。
原始碼防護:登入驗證邏輯包在獨立作用域(IIFE)裡,不會外洩到全域可被主控台直接呼叫;正式版本經過 minify+適度 obfuscate。
選取/複製阻擋(2026-08-20 新增):右鍵選單、複製、剪下、拖曳選取都擋掉(登入表單輸入框排除,不影響打字/貼上)。這只防得住隨手複製,擋不住開發者工具、檢視原始碼、下載整個網頁檔案、螢幕截圖——這些都是瀏覽器本來就給使用者的能力,前端程式碼無法真的關掉,是「防隨手」不是資安防護。
已知限制:本頁是純前端頁面、沒有後端伺服器,拿到原始碼的人仍可離線、不受這裡任何限流限制地反覆嘗試——PBKDF2 只能拉高每次嘗試的成本,無法讓離線暴力嘗試變成不可能;儀表板本身的遊戲/營運數據一樣以 JS 常數形式寫在原始碼裡,登入畫面只能隱藏介面,無法保護已寫入原始碼的資料。
分頁權限限制(本表 20 項測試之後才加上,2026-08-20 補充說明):「排程記錄」「資安檢測」這兩個分頁只有登入名稱顯示為 Lucas 才看得到按鈕,其他帳號登入後直接隱藏。這只是畫面顯示範圍的整理,不是額外一層登入驗證——判斷依據是登入晶片上已顯示的姓名,懂得用瀏覽器開發者工具的人可以直接修改頁面元素繞過(例如把分頁的隱藏屬性改掉),效果跟「儀表板本身的遊戲/營運數據本來就是全域 JS 變數、登入畫面只能隱藏介面」是同一個道理。這兩個分頁本身也沒有比其他分頁存放更敏感的資料(都是營運數據與流程紀錄,不含員工個資),所以這個限制的目的是避免無關人員誤觸、不是保護機密。
| # | 測試項目 | 結果 | 測試方式 | 關鍵結果 |
|---|---|---|---|---|
| 1 | 正確三項資料可登入 | PASS | 瀏覽器實測輸入正確帳密 | 成功登入並顯示正確姓名 |
| 2 | 信箱錯誤不能登入 | PASS | 實測,其餘兩項正確 | 顯示統一錯誤訊息 |
| 3 | 分機錯誤不能登入 | PASS | 實測,其餘兩項正確 | 顯示統一錯誤訊息 |
| 4 | 員工編號錯誤不能登入 | PASS | 實測,其餘兩項正確 | 顯示統一錯誤訊息 |
| 5 | 跨員工資料組合不能登入 | PASS | 臨時測試帳號交叉測試(測完已移除,未使用真實員工資料) | 正確拒絕 |
| 6 | 所有錯誤訊息一致 | PASS | 比對上述各次錯誤文字 | 皆為「登入資料不正確」 |
| 7 | 原始碼無明文信箱 | PASS | 全文檢索 | 無命中 |
| 8 | 原始碼無明文分機 | PASS | 全文檢索 | 無命中 |
| 9 | 原始碼無明文員工編號 | PASS | 全文檢索並逐一核對命中內容 | 命中皆為業務數據或隨機 salt 的巧合數字,非真實洩漏 |
| 10 | 原始碼無三項資料明文組合 | PASS | 全文檢索 | 無命中 |
| 11 | localStorage 無登入憑證 | PASS | 瀏覽器實測讀取 | 只有登入紀錄與主題偏好,無憑證(另有「記住本機輸入」為使用者自選功能,見下方說明) |
| 12 | sessionStorage 無登入資料 | PASS | 瀏覽器實測讀取 | 空 |
| 13 | console 無登入資料 | PASS | 檢查瀏覽器主控台輸出 | 無憑證輸出 |
| 14 | URL 無登入資料 | PASS | 檢查登入前後網址 | 無 query string/hash |
| 15 | 重新整理要求重新登入 | PASS | 登入後重新整理頁面 | 回到登入畫面 |
| 16 | 登出後受保護畫面消失 | PASS | 實測點擊登出 | 畫面回到登入頁 |
| 17 | 5 次失敗後觸發等待時間 | PASS | 連續 5 次錯誤後,第 6 次改用正確帳密再試 | 顯示「請稍候 30 秒」,正確帳密也一併被擋 |
| 18 | Minify/Obfuscate 後登入仍正常 | PASS | 建置後重跑成功/失敗/鎖定/登出測試 | 全部正常 |
| 19 | 異常輸入不會讓程式當機 | PASS | 超長字串、emoji、script 標籤、SQL injection 字樣等 | 皆正常拒絕,無例外拋出 |
| 20 | 無登入名單顯示/修改畫面 | PASS | 全文檢索+檢查內部變數是否外洩到全域 | 無此類介面或函式,AUTH_RECORDS 等不可從主控台直接存取 |
這個分頁需要連線到本機的查詢伺服器才能運作。你現在看到的是分享出去的靜態版本,沒有連接後端資料庫。 照下面步驟在自己電腦上跑起來,就能查詢完整的每日原始資料。
資料現在按月拆成一包一包,不用每次都整包重下載——查詢工具跟每個月的資料是分開的檔案, 需要哪個月的資料就下載那個月,已經下載過、沒更新的月份不用再下。
如果雙擊解壓縮時 Windows 沒有跳出密碼輸入框、或提示「壓縮的資料夾無效」,代表這台電腦不支援這種加密方式,改用免費的 7-Zip 解壓縮即可。想拿到最新一天的資料,回到上面的清單重新下載「當月」那個月份的 ZIP 就好,不用整包重下載。