Search
分析 npm 或 yarn lockfile 檢測安全問題
Lockfiles 被用作資源清單的受信任白名單，從中獲取套件。 然而追蹤到 lockfile 中的修改並不是一項簡單的任務，因為它們是為機器使用而設計的。
如果有人建立了一個 Pull Request 並且偷偷地使用一個惡意的資源套件來替換一個真正的程式庫，會發生什麼事呢？
檢查你的 lockfile ，以確保它們符合預先定義的安全策略，並減輕這種安全漏洞攻擊。
✍看更多開源資訊介紹，歡迎加入 Discord Github 俱樂部 https://discord.gg/DGR7uDqSSW
https://github.com/lirantal/lockfile-lint
這一系列文總共有三篇，這是最後一篇。
Funliday 重磅推出新的 prerender 套件 pppr！這是一個 zero config 的 express middleware，只要 npm install pppr，然後在 app.js 裡面加一行 app.use(pppr()) 就可以直接拿來用了。
---
原本在使用 prerender.io 這個套件有時候會出現 504 timeout 的問題，後來發現這個套件用的是比較底層的 API (Chrome DevTools Protocol, CDP)，研究它的原始碼後發現 render HTML 的 timeout 判斷上有些怪怪的，本來想試著去改這塊，但對 CDP 不熟，所以用 puppeteer 重寫一套 prerender service，pppr 也就應運而生。
簡單先解釋一下，puppeteer 是基於 CDP 封裝後成為比較容易使用的 API。因為 client side rendering (CSR) 的流行，所以現在要做網路爬蟲的話，愈來愈多會選擇用 puppeteer 來處理。這裡來分享一下在開發 pppr 的時候，有哪些東西要注意的。
1. 把 URL 放到像是 50 人的 LINE 熱門群組，prerender 會遭到大量的 request，因為每個使用者接收到這個訊息之後，因為要顯示 og data，所以就會去打一次 prerender。這裡姑且先稱之為 OG-DDoS 好了 XD，所以一定要做 cache，讓第一個 request 把 HTML 產生出來之後就放到 cache 裡面。然後可以用 LRU cache 來處理，因為這類 URL 都是短時間會被大量使用，之後就很少被用了，用 LRU cache 剛剛好。
1-1. 其實這一段實作還有一些問題，如果在第一個 request 還沒產生出 HTML 之前，第二個同樣 request 就進來了，這樣子 cache 可以說是根本沒作用，還要再找時間來處理 lock 機制才行。
2. 每一個 request 要新開一個 page 才行，如果沒有每個 request 都開新 page 的話，會造成 A request 還沒處理完，B request 就用同一個 page 做 render，這樣子 A request 就會 504 timeout 了。所以一定要記得每個 request 都要新開 page。
3. 因為 headless chrome 的 user agent 就叫做 HeadlessChrome，為了避免在 render 的時候會出現意料外的狀況，保險一點還是把 HeadlessChrome 改成 Chrome 會比較好。
4. 注意 redirect。因為 expressjs 跟 puppeter 是兩個不同的 context，對於 redirection 來說，expressjs 會回傳 3xx 系列的狀態碼，但 puppeteer 則會直接執行完成。所以把 puppeteer 放在 expressjs 裡面執行的話，必須要處理 redirect chain，讓 expressjs 能回給 client 正確的狀態碼才行。
5. pppr 因為是發想自 prerender.io，所以 interface 也一樣是 /render?url=https://example.com。 但有時候原始的 url 後面會包含 query string，所以 expressjs 要用 URLSearchParams 另外做些處理，才能取得完整的 url。
開發 pppr 基本要注意的事項大概就這樣，總之記得給星，有任何問題歡迎發 issue 跟 pr 喔！
#pppr #prerender #funliday
最近跟手機串接其中一支 API 的時候，小編在規格上設計了 request 必須帶一個 UUID 的值給 backend，以 Android 來說其實直接使用 UUID.randomUUID().toString() 就可以了，但 iOS 熱門的 FCUUID library 看起來好像給了一個錯誤的實作，而且大家好像常誤解了 UUID 的意思。為了這件事，昨天凌晨跟朋友弄了一個小時 Orz
---
一般大家常知道的 UUID 應該是像這樣 8909ea35-8b0e-4e1a-8ba3-9c0af47c77ca，由 8-4-4-4-12 及 16 進制的字元，共 36 個字元所組成的，Java 及一些 npm 的 library 也是如此實作。可是 iOS 的 FCUUID 卻是產生 8909ea358b0e4e1a8ba39c0af47c77ca，連續 32 個字元的字串
---
下面是對話內容，沒想到 UUID 的格式還有不一樣的 Orz
---
(I: ios, B: backend)
* I：你說的uuid有長度限制嗎？
* B：uuid 就是 36 chars
* I：format我不用管對吧，我只要送36個字元過去
* B：uuid 就 uuid
* I：你要well format的uuid，還是我給你一串36個字元的字串
* B：well format 的 uuid
* I：ok
* B：因為我就是講 uuid 啊 xddd
* I：這詞早就被亂用了
* B：怎說？
* I：很多人的uuid不是那個uuid阿，就一串unique的id，以前接過很多api，uuid就unique的id，他們就這樣叫，也沒人在管，uid??uuid??阿災，他們都這樣叫
* B：不夠嚴謹，這工程師不行吧
(半小時後)
* I：要不要dash呢？
* B：要，因為是 uuid
* I：我現在的uuid是用lib產生的
* B：昏
* I：uuidForSesion，這method聽起來是不是很完美，完全就是我們要的
* B：看起來是
* I：但他是32個char，沒4個dash
* B：心累 orz
---
雖然小編不會寫 Objective-C 但還是去 FCUUID 翻了一下程式碼 (https://github.com/fabiocaccamo/FCUUID/blob/master/FCUUID/FCUUID.m#L99)，發現作者拿到 UUID 之後把 - 取代為空字串，所以只剩下 32 個字元。看了 README 的所有內容也沒提到會改變 UUID 的格式，「This library provides the simplest API to obtain universally unique identifiers with different levels of persistence.」
最後看到更有趣的一個 method (https://github.com/fabiocaccamo/FCUUID/blob/master/FCUUID/FCUUID.m#L358)，uuidValueIsValid 會判斷所傳入的字串是否為 UUID 格式，結果不知道是不是為了相容於正確的 UUID 格式，裡面的 regex 寫成 ^[0-9a-f]{32}|[0-9a-f]{8}-([0-9a-f]{4}-){3}[0-9a-f]{12}$，讓小編啼笑皆非 囧
只不過在 GitHub 上都沒有討論到 32 個字元及 36 個字元的話題，不知道是不是使用 FCUUID 的 iOS 開發者都沒有這種需求呢？
#uuid #ios #fcuuid
Install it using npm (make sure that you have Node.js 8 or newer): ... Finds the validation errors in this request and wraps them in an object with handy ... ... <看更多>
npm request 在 Request - Simplified HTTP client - GitHub 的推薦與評價
For more information about why request is deprecated and possible alternatives refer to this issue. Request - Simplified HTTP client. npm package · Build status ... ... <看更多>