#cofacts
2024-11-02
https://cofacts.tw/article/QOSe6JIBd8PNbJEMfa84
冒用名義貸款廣告，繼郵局跟財政部後，這次換勞動部被冒用，還跟上颱風時事
冒用名義貸款廣告，繼郵局跟財政部後，這次換勞動部被冒用，還跟上颱風時事
好新喔
但它錯字好明顯 XDDD
但它錯字好明顯 XDDD
看起來使用者沒有傳送搭配的轉傳訊息
直接靜態圖做成影片嗎
是不是覺得 TikTok 使用者比較容易上當 （咦
https://cofacts.tw/article/QOSe6JIBd8PNbJEMfa84
冒用名義貸款廣告，繼郵局跟財政部後，這次換勞動部被冒用，還跟上颱風時事
冒用名義貸款廣告，繼郵局跟財政部後，這次換勞動部被冒用，還跟上颱風時事
- 👀1
好新喔
但它錯字好明顯 XDDD
但它錯字好明顯 XDDD
看起來使用者沒有傳送搭配的轉傳訊息
直接靜態圖做成影片嗎
是不是覺得 TikTok 使用者比較容易上當 （咦
@idforbin has joined the channel
2024-11-03
好新喔
但它錯字好明顯 XDDD
但它錯字好明顯 XDDD
看起來使用者沒有傳送搭配的轉傳訊息
2024-11-04
直接靜態圖做成影片嗎
是不是覺得 TikTok 使用者比較容易上當 （咦
Matterbridge
Today was the first day of `Hack the Disinfo 2024`, a hackathon hosted by Code for Japan. @りょーま（Yuki Kawabe） san presented `BirdXplorer` at the hackathon. Here is an [NHK](https://www3.nhk.or.jp/news/html/20241103/k10014628211000.html) report about the event :slightly_smiling_face:
Today was the first day of `Hack the Disinfo 2024`, a hackathon hosted by Code for Japan. @りょーま（Yuki Kawabe） san presented `BirdXplorer` at the hackathon. Here is an [NHK](https://www3.nhk.or.jp/news/html/20241103/k10014628211000.html) report about the event :slightly_smiling_face:
HackMD
# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2024 -
Follow-up on migrating to GCE: 我發現 Container-Optimized OS 沒有 package manager、不能執行非 dockerized 的 script，也沒有內建的 dcoker-compose 感覺用起來很 hardcore
我還是用普通的 debian 好了……XD
我還是用普通的 debian 好了……XD
Follow-up on migrating to GCE: 我發現 Container-Optimized OS 沒有 package manager、不能執行非 dockerized 的 script，也沒有內建的 dcoker-compose 感覺用起來很 hardcore
我還是用普通的 debian 好了……XD
我還是用普通的 debian 好了……XD
Follow-up on migrating to GCE: 我發現 Container-Optimized OS 沒有 package manager、不能執行非 dockerized 的 script，也沒有內建的 dcoker-compose 感覺用起來很 hardcore
我還是用普通的 debian 好了……XD
我還是用普通的 debian 好了……XD
2024-11-06
https://cofacts.tw/article/_-QE95IBd8PNbJEMM8U7 路倒假車禍告肇事逃逸這個好多人問
搭配的訊息是「警察局告知的」
Whisper 辨識得不錯耶，感謝 murmur 幫修逐字稿
先寫了一版
https://cofacts.tw/reply/HuR6AZMBd8PNbJEMQdnB
寫的時候想到的點
• 抵銷「最新詐騙」的錯誤認知：提供過往查核與案例這根本是老手法
• 肯定「報案」作為行動：提供警方建議作為依歸
• 提供「製造假車禍的人被法辦」的新聞，讓讀者知道社會還是有正義在 (?)
https://cofacts.tw/reply/HuR6AZMBd8PNbJEMQdnB
寫的時候想到的點
• 抵銷「最新詐騙」的錯誤認知：提供過往查核與案例這根本是老手法
• 肯定「報案」作為行動：提供警方建議作為依歸
• 提供「製造假車禍的人被法辦」的新聞，讓讀者知道社會還是有正義在 (?)
這要感謝 MyGoPen 過往對類似案例的查核報告，替這個回應提供了非常強健的基礎 m(_ _)m
讚讚，感謝
https://cofacts.tw/article/_-QE95IBd8PNbJEMM8U7 路倒假車禍告肇事逃逸這個好多人問
搭配的訊息是「警察局告知的」
Whisper 辨識得不錯耶，感謝 murmur 幫修逐字稿
先寫了一版
https://cofacts.tw/reply/HuR6AZMBd8PNbJEMQdnB
寫的時候想到的點
• 抵銷「最新詐騙」的錯誤認知：提供過往查核與案例這根本是老手法
• 肯定「報案」作為行動：提供警方建議作為依歸
• 提供「製造假車禍的人被法辦」的新聞，讓讀者知道社會還是有正義在 (?)
https://cofacts.tw/reply/HuR6AZMBd8PNbJEMQdnB
寫的時候想到的點
• 抵銷「最新詐騙」的錯誤認知：提供過往查核與案例這根本是老手法
• 肯定「報案」作為行動：提供警方建議作為依歸
• 提供「製造假車禍的人被法辦」的新聞，讓讀者知道社會還是有正義在 (?)
這要感謝 MyGoPen 過往對類似案例的查核報告，替這個回應提供了非常強健的基礎 m(_ _)m
讚讚，感謝
搭配的訊息是「警察局告知的」
Whisper 辨識得不錯耶，感謝 murmur 幫修逐字稿
先寫了一版
https://cofacts.tw/reply/HuR6AZMBd8PNbJEMQdnB
寫的時候想到的點
• 抵銷「最新詐騙」的錯誤認知：提供過往查核與案例這根本是老手法
• 肯定「報案」作為行動：提供警方建議作為依歸
• 提供「製造假車禍的人被法辦」的新聞，讓讀者知道社會還是有正義在 (?)
https://cofacts.tw/reply/HuR6AZMBd8PNbJEMQdnB
寫的時候想到的點
• 抵銷「最新詐騙」的錯誤認知：提供過往查核與案例這根本是老手法
• 肯定「報案」作為行動：提供警方建議作為依歸
• 提供「製造假車禍的人被法辦」的新聞，讓讀者知道社會還是有正義在 (?)
這要感謝 MyGoPen 過往對類似案例的查核報告，替這個回應提供了非常強健的基礎 m(_ _)m
為什麼可疑訊息那邊用日期篩選器篩選今天的，最早只能看到早上八點後的？
https://cofacts.tw/articles?start=2024-11-06&end=&filters=&orderBy=lastRequestedAt
https://cofacts.tw/articles?start=2024-11-06&end=&filters=&orderBy=lastRequestedAt
因為主機是 UTC+0 XD
不知道 elasticsearch 那裡是否有啥設定可以指定時區
為什麼可疑訊息那邊用日期篩選器篩選今天的，最早只能看到早上八點後的？
https://cofacts.tw/articles?start=2024-11-06&end=&filters=&orderBy=lastRequestedAt
https://cofacts.tw/articles?start=2024-11-06&end=&filters=&orderBy=lastRequestedAt
因為主機是 UTC+0 XD
不知道 elasticsearch 那裡是否有啥設定可以指定時區
2024-11-07
因為主機是 UTC+0 XD
不知道 elasticsearch 那裡是否有啥設定可以指定時區
Wayback Machine 存檔功能在 11/4 的時候修好了，但我們所使用的 Save Page Now API 似乎還沒有
昨天寫的回應裡的網址，今天還沒存起來，看打 API 後留存的 log，也顯示 Save Page Now API 沒有正常運作 QQ
昨天寫的回應裡的網址，今天還沒存起來，看打 API 後留存的 log，也顯示 Save Page Now API 沒有正常運作 QQ
Wayback Machine 存檔功能在 11/4 的時候修好了，但我們所使用的 Save Page Now API 似乎還沒有
昨天寫的回應裡的網址，今天還沒存起來，看打 API 後留存的 log，也顯示 Save Page Now API 沒有正常運作 QQ
昨天寫的回應裡的網址，今天還沒存起來，看打 API 後留存的 log，也顯示 Save Page Now API 沒有正常運作 QQ
2024-11-08
@belongbelong223 has joined the channel
最近 Cofacts 有兩個與外部整合的功能：自動 spam 移除 以及 Badge 發送功能，會需要「只有特定人能存取」的 API 需求
本來自動 spam 移除的「封鎖某使用者」功能，是打算用 Google Pub/Sub 來避免開外部 API，使用 Google 帳號來管理誰能下該指令，但實作的過程覺得
• 開個 API 要要蓋 topic + subscription 感覺很囉唆
• 自動 spam 移除這個 use case 更像是 RPC 而非 message queue
所以想要 propose 一個新方式：
• 自動 spam 移除的「封鎖使用者」與發送 badge 的 API，都做成 GraphQL mutation 或 Open API (feTS)
• 這些 API 直接用 Cloudflare Zero Trust 保護起來，必須持有 Cofacts 這裡另外交給呼叫者的 service token 才能存取（之前對 Cloudflare Zero Trust 的研究：https://g0v.hackmd.io/51wwLHgvSUqtBDaP-yAVnA#Alternative-Implement-using-Cloudflare-Zero-Trust）
由於 Cofacts 這裡本來就有打算在 GraphQL API 這裡也用 api key 之類的機制保護起來的想法，想說先做在新的 endpoint 上試點，等較為熟練 + 時機成熟後再擴到大主要的 `/graphql` endpoint，好像也是個不錯的路徑。
這裡想聽聽 @acerxp511 @jhk482001 的意見～
本來自動 spam 移除的「封鎖某使用者」功能，是打算用 Google Pub/Sub 來避免開外部 API，使用 Google 帳號來管理誰能下該指令，但實作的過程覺得
• 開個 API 要要蓋 topic + subscription 感覺很囉唆
• 自動 spam 移除這個 use case 更像是 RPC 而非 message queue
所以想要 propose 一個新方式：
• 自動 spam 移除的「封鎖使用者」與發送 badge 的 API，都做成 GraphQL mutation 或 Open API (feTS)
• 這些 API 直接用 Cloudflare Zero Trust 保護起來，必須持有 Cofacts 這裡另外交給呼叫者的 service token 才能存取（之前對 Cloudflare Zero Trust 的研究：https://g0v.hackmd.io/51wwLHgvSUqtBDaP-yAVnA#Alternative-Implement-using-Cloudflare-Zero-Trust）
由於 Cofacts 這裡本來就有打算在 GraphQL API 這裡也用 api key 之類的機制保護起來的想法，想說先做在新的 endpoint 上試點，等較為熟練 + 時機成熟後再擴到大主要的 `/graphql` endpoint，好像也是個不錯的路徑。
這裡想聽聽 @acerxp511 @jhk482001 的意見～
# Cofacts reasearch & design docs :::info - Design docs: Implementation documents with requiremen
FETS
Build and consume REST APIs with ease. No more compromises on type safety in client-server communication. All thanks to TypeScript and OpenAPI.
- 👀1
1
也好奇 @alex2002 有沒有使用 Cloudflare Zero Trust 的經驗
有喔 我公司的staging和develop 放公網 但藏在我們Workspace的SSO後面(Saml)
我好像有看到會議記錄你想要用zero trust的ServiceKey？
badge 部分 可以來pilot這個沒問題 🙏
對呀想用的是 service token
我會偏好OpenAPI 這樣在ZeroTrust設特定endpoint需要service token會比較簡潔
Okok
我這裡應該會直接讓 rumors-api 的 pm2 起另一台 nodejs http server 跑 OpenAPI
然後直接用獨立的 admin-api.cofacts.tw 與 admin-dev-api.cofacts.tw 這兩個網域分別指到 production 與 staging 的 OpenAPI
這樣要上 ZeroTrust 也不會影響現在的 api
我這裡應該會直接讓 rumors-api 的 pm2 起另一台 nodejs http server 跑 OpenAPI
然後直接用獨立的 admin-api.cofacts.tw 與 admin-dev-api.cofacts.tw 這兩個網域分別指到 production 與 staging 的 OpenAPI
這樣要上 ZeroTrust 也不會影響現在的 api
> 在ZeroTrust設特定endpoint需要service token會比較簡潔
我覺得 admin endpoint 大概會有
• Badge 相關 API：新 badge 與把 badge 加到人身上
• 管版相關 API:
我看了一下
• Zero Trust / Application 是個可以指定 policy 的單位。但 Application
我覺得 admin endpoint 大概會有
• Badge 相關 API：新 badge 與把 badge 加到人身上
• 管版相關 API:
我看了一下
• Zero Trust / Application 是個可以指定 policy 的單位。但 Application
但因為也不是正規的api shield (要enterprise) 所以權限管理上可能要用比較奇怪的方法 把application當成access group概念 有token就可以過
是ㄉ
@jhk482001 增加 Admin API 的架構 PR 已發：
https://github.com/cofacts/rumors-api/pull/337
加一支 API 的 PR 大概會像這樣：
https://github.com/cofacts/rumors-api/pull/352
今晚開會的時候我也會講一次
晚上見~~
https://github.com/cofacts/rumors-api/pull/337
加一支 API 的 PR 大概會像這樣：
https://github.com/cofacts/rumors-api/pull/352
今晚開會的時候我也會講一次
晚上見~~
感謝! 🙏
今天開會時間是？
8pm 唷
歡迎來參加
歡迎來參加
最近 Cofacts 有兩個與外部整合的功能：自動 spam 移除 以及 Badge 發送功能，會需要「只有特定人能存取」的 API 需求
本來自動 spam 移除的「封鎖某使用者」功能，是打算用 Google Pub/Sub 來避免開外部 API，使用 Google 帳號來管理誰能下該指令，但實作的過程覺得
• 開個 API 要要蓋 topic + subscription 感覺很囉唆
• 自動 spam 移除這個 use case 更像是 RPC 而非 message queue
所以想要 propose 一個新方式：
• 自動 spam 移除的「封鎖使用者」與發送 badge 的 API，都做成 GraphQL mutation 或 Open API (feTS)
• 這些 API 直接用 Cloudflare Zero Trust 保護起來，必須持有 Cofacts 這裡另外交給呼叫者的 service token 才能存取（之前對 Cloudflare Zero Trust 的研究：https://g0v.hackmd.io/51wwLHgvSUqtBDaP-yAVnA#Alternative-Implement-using-Cloudflare-Zero-Trust）
由於 Cofacts 這裡本來就有打算在 GraphQL API 這裡也用 api key 之類的機制保護起來的想法，想說先做在新的 endpoint 上試點，等較為熟練 + 時機成熟後再擴到大主要的 `/graphql` endpoint，好像也是個不錯的路徑。
這裡想聽聽 @acerxp511 @jhk482001 的意見～
本來自動 spam 移除的「封鎖某使用者」功能，是打算用 Google Pub/Sub 來避免開外部 API，使用 Google 帳號來管理誰能下該指令，但實作的過程覺得
• 開個 API 要要蓋 topic + subscription 感覺很囉唆
• 自動 spam 移除這個 use case 更像是 RPC 而非 message queue
所以想要 propose 一個新方式：
• 自動 spam 移除的「封鎖使用者」與發送 badge 的 API，都做成 GraphQL mutation 或 Open API (feTS)
• 這些 API 直接用 Cloudflare Zero Trust 保護起來，必須持有 Cofacts 這裡另外交給呼叫者的 service token 才能存取（之前對 Cloudflare Zero Trust 的研究：https://g0v.hackmd.io/51wwLHgvSUqtBDaP-yAVnA#Alternative-Implement-using-Cloudflare-Zero-Trust）
由於 Cofacts 這裡本來就有打算在 GraphQL API 這裡也用 api key 之類的機制保護起來的想法，想說先做在新的 endpoint 上試點，等較為熟練 + 時機成熟後再擴到大主要的 `/graphql` endpoint，好像也是個不錯的路徑。
這裡想聽聽 @acerxp511 @jhk482001 的意見～
也好奇 @alex2002 有沒有使用 Cloudflare Zero Trust 的經驗
有喔 我公司的staging和develop 放公網 但藏在我們Workspace的SSO後面(Saml)
我好像有看到會議記錄你想要用zero trust的ServiceKey？
badge 部分 可以來pilot這個沒問題 🙏
對呀想用的是 service token
我會偏好OpenAPI 這樣在ZeroTrust設特定endpoint需要service token會比較簡潔
Okok
我這裡應該會直接讓 rumors-api 的 pm2 起另一台 nodejs http server 跑 OpenAPI
然後直接用獨立的 admin-api.cofacts.tw 與 admin-dev-api.cofacts.tw 這兩個網域分別指到 production 與 staging 的 OpenAPI
這樣要上 ZeroTrust 也不會影響現在的 api
我這裡應該會直接讓 rumors-api 的 pm2 起另一台 nodejs http server 跑 OpenAPI
然後直接用獨立的 admin-api.cofacts.tw 與 admin-dev-api.cofacts.tw 這兩個網域分別指到 production 與 staging 的 OpenAPI
這樣要上 ZeroTrust 也不會影響現在的 api
> 在ZeroTrust設特定endpoint需要service token會比較簡潔
我覺得 admin endpoint 大概會有
• Badge 相關 API：新 badge 與把 badge 加到人身上
• 管版相關 API:
我看了一下
• Zero Trust / Application 是個可以指定 policy 的單位。但 Application
我覺得 admin endpoint 大概會有
• Badge 相關 API：新 badge 與把 badge 加到人身上
• 管版相關 API:
我看了一下
• Zero Trust / Application 是個可以指定 policy 的單位。但 Application
但因為也不是正規的api shield (要enterprise) 所以權限管理上可能要用比較奇怪的方法 把application當成access group概念 有token就可以過
是ㄉ
@jhk482001 增加 Admin API 的架構 PR 已發：
https://github.com/cofacts/rumors-api/pull/337
加一支 API 的 PR 大概會像這樣：
https://github.com/cofacts/rumors-api/pull/352
今晚開會的時候我也會講一次
晚上見~~
https://github.com/cofacts/rumors-api/pull/337
加一支 API 的 PR 大概會像這樣：
https://github.com/cofacts/rumors-api/pull/352
今晚開會的時候我也會講一次
晚上見~~
感謝! 🙏
今天開會時間是？
8pm 唷
歡迎來參加
歡迎來參加
也好奇 @alex2002 有沒有使用 Cloudflare Zero Trust 的經驗
有喔 我公司的staging和develop 放公網 但藏在我們Workspace的SSO後面(Saml)
我好像有看到會議記錄你想要用zero trust的ServiceKey？
badge 部分 可以來pilot這個沒問題 🙏
對呀想用的是 service token
我會偏好OpenAPI 這樣在ZeroTrust設特定endpoint需要service token會比較簡潔
行人優先區有幾篇誇大的影片，真的有縣市已經開始實行了嗎？
https://cofacts.tw/article/h7ccs5IBDfH0hhhZlGkQ
https://cofacts.tw/article/I-TX25IBd8PNbJEM1Ja4
https://cofacts.tw/article/peQTB5MBd8PNbJEMHuSL
https://cofacts.tw/article/A7fpwJIBDfH0hhhZpoXc
https://cofacts.tw/article/_7aVa5IBDfH0hhhZaO16
https://cofacts.tw/article/ULeljZIBDfH0hhhZmCYv
https://cofacts.tw/article/Q7d9uJIBDfH0hhhZJHXi
https://cofacts.tw/article/h7ccs5IBDfH0hhhZlGkQ
https://cofacts.tw/article/I-TX25IBd8PNbJEM1Ja4
https://cofacts.tw/article/peQTB5MBd8PNbJEMHuSL
https://cofacts.tw/article/A7fpwJIBDfH0hhhZpoXc
https://cofacts.tw/article/_7aVa5IBDfH0hhhZaO16
https://cofacts.tw/article/ULeljZIBDfH0hhhZmCYv
https://cofacts.tw/article/Q7d9uJIBDfH0hhhZJHXi
10/22 高雄這篇寫還沒，要等明年
https://news.ltn.com.tw/news/life/breakingnews/4838925
11/7 新竹縣這篇官員受訪說「應該還沒有縣市政府完成設置」，新竹縣也要明年中以前才會有
https://news.ltn.com.tw/news/life/breakingnews/4855593
https://news.ltn.com.tw/news/life/breakingnews/4838925
11/7 新竹縣這篇官員受訪說「應該還沒有縣市政府完成設置」，新竹縣也要明年中以前才會有
https://news.ltn.com.tw/news/life/breakingnews/4855593
滿奇妙的，這種影片都是在抖音
> 行人優先區，以行人步行為優先，*行人可於道路全寬通行*，於區內之車輛及行人應遵守道路交通安全規則之規定
所以這個地方根本就是步行區呀，像西門町那種吧
所以這個地方根本就是步行區呀，像西門町那種吧
都已經是步行區了還超速
根本想殺人吧
根本想殺人吧
之前在 Cofacts 也看到滿多反路權影片都是做這種形式
啊，寫還回應忘記引 @iacmai 的高雄的例子
但好懶惰
是不是該寫個修改回應之後一鍵刪除重貼的功能
但好懶惰
是不是該寫個修改回應之後一鍵刪除重貼的功能
想 propose 一個網站上「修改重發」回應的功能。
過去針對「編輯回應」有這些討論：https://g0v.hackmd.io/OC7BneJ3TEGJHge1hWV-0w#%E8%A8%8E%E8%AB%96%EF%BC%9A%E8%AE%93%E4%BD%9C%E8%80%85%E8%83%BD%E7%B7%A8%E8%BC%AF%E5%9B%9E%E6%87%89 （天啊 2020 年）
還開了一張票想要改 API，不外乎就是要解決
• 回應會被自己、被別人加到不同訊息下，此狀況下什麼樣的編輯算合理？
• 編輯後，針對舊文字的 feedback 怎麼辦？
因此，現在的 status quo 就是請使用者刪掉重發，這樣最單純。
我覺得比起「編輯」，其實更容易做的是把「修改重發」自動化，也就是針對現有回應做出「更動」後，系統其實不會動原有的回應，而是
• 新增新的回應
• 把新的回應加到原有回應連結的訊息上（僅限作者自己加的）
• 把原有回應刪除（僅限作者自己加的）
也就是現在查核協作者可以自行操作的動作，改成一鍵完成這樣。UX 細節如下：
• 回應作者在任何自己撰寫的回應上點擊「修改重發」，會被導向到該 reply 的 detail 頁面。
• reply detail 新增編輯模式，可修改「我認為」分類、內文與出處。
• 送出按鈕上面的用語為「修改重發」，前面說明文字簡述說，修改後的文案會同時套用到自己所連結的可疑訊息，也就是下方「此查核回應尚被用於以下的可疑訊息」列出的訊息中，由自己加的那些。
• 按下「修改重發」後，跳出彈窗列出那些會被套用的網傳訊息，以及確認按鈕。
• 按下確認後，彈窗顯示套用的進度，以及往新回應 detail 頁面的連結。
以上功能都可以用現有 API 做到，不用開新的欄位，只要改 rumors-site。
過去針對「編輯回應」有這些討論：https://g0v.hackmd.io/OC7BneJ3TEGJHge1hWV-0w#%E8%A8%8E%E8%AB%96%EF%BC%9A%E8%AE%93%E4%BD%9C%E8%80%85%E8%83%BD%E7%B7%A8%E8%BC%AF%E5%9B%9E%E6%87%89 （天啊 2020 年）
還開了一張票想要改 API，不外乎就是要解決
• 回應會被自己、被別人加到不同訊息下，此狀況下什麼樣的編輯算合理？
• 編輯後，針對舊文字的 feedback 怎麼辦？
因此，現在的 status quo 就是請使用者刪掉重發，這樣最單純。
我覺得比起「編輯」，其實更容易做的是把「修改重發」自動化，也就是針對現有回應做出「更動」後，系統其實不會動原有的回應，而是
• 新增新的回應
• 把新的回應加到原有回應連結的訊息上（僅限作者自己加的）
• 把原有回應刪除（僅限作者自己加的）
也就是現在查核協作者可以自行操作的動作，改成一鍵完成這樣。UX 細節如下：
• 回應作者在任何自己撰寫的回應上點擊「修改重發」，會被導向到該 reply 的 detail 頁面。
• reply detail 新增編輯模式，可修改「我認為」分類、內文與出處。
• 送出按鈕上面的用語為「修改重發」，前面說明文字簡述說，修改後的文案會同時套用到自己所連結的可疑訊息，也就是下方「此查核回應尚被用於以下的可疑訊息」列出的訊息中，由自己加的那些。
• 按下「修改重發」後，跳出彈窗列出那些會被套用的網傳訊息，以及確認按鈕。
• 按下確認後，彈窗顯示套用的進度，以及往新回應 detail 頁面的連結。
以上功能都可以用現有 API 做到，不用開新的欄位，只要改 rumors-site。
行人優先區有幾篇誇大的影片，真的有縣市已經開始實行了嗎？
https://cofacts.tw/article/h7ccs5IBDfH0hhhZlGkQ
https://cofacts.tw/article/I-TX25IBd8PNbJEM1Ja4
https://cofacts.tw/article/peQTB5MBd8PNbJEMHuSL
https://cofacts.tw/article/A7fpwJIBDfH0hhhZpoXc
https://cofacts.tw/article/_7aVa5IBDfH0hhhZaO16
https://cofacts.tw/article/ULeljZIBDfH0hhhZmCYv
https://cofacts.tw/article/Q7d9uJIBDfH0hhhZJHXi
https://cofacts.tw/article/h7ccs5IBDfH0hhhZlGkQ
https://cofacts.tw/article/I-TX25IBd8PNbJEM1Ja4
https://cofacts.tw/article/peQTB5MBd8PNbJEMHuSL
https://cofacts.tw/article/A7fpwJIBDfH0hhhZpoXc
https://cofacts.tw/article/_7aVa5IBDfH0hhhZaO16
https://cofacts.tw/article/ULeljZIBDfH0hhhZmCYv
https://cofacts.tw/article/Q7d9uJIBDfH0hhhZJHXi
10/22 高雄這篇寫還沒，要等明年
https://news.ltn.com.tw/news/life/breakingnews/4838925
11/7 新竹縣這篇官員受訪說「應該還沒有縣市政府完成設置」，新竹縣也要明年中以前才會有
https://news.ltn.com.tw/news/life/breakingnews/4855593
https://news.ltn.com.tw/news/life/breakingnews/4838925
11/7 新竹縣這篇官員受訪說「應該還沒有縣市政府完成設置」，新竹縣也要明年中以前才會有
https://news.ltn.com.tw/news/life/breakingnews/4855593
滿奇妙的，這種影片都是在抖音
> 行人優先區，以行人步行為優先，*行人可於道路全寬通行*，於區內之車輛及行人應遵守道路交通安全規則之規定
所以這個地方根本就是步行區呀，像西門町那種吧
所以這個地方根本就是步行區呀，像西門町那種吧
都已經是步行區了還超速
根本想殺人吧
根本想殺人吧
之前在 Cofacts 也看到滿多反路權影片都是做這種形式
啊，寫還回應忘記引 @iacmai 的高雄的例子
但好懶惰
是不是該寫個修改回應之後一鍵刪除重貼的功能
但好懶惰
是不是該寫個修改回應之後一鍵刪除重貼的功能
想 propose 一個網站上「修改重發」回應的功能。
過去針對「編輯回應」有這些討論：https://g0v.hackmd.io/OC7BneJ3TEGJHge1hWV-0w#%E8%A8%8E%E8%AB%96%EF%BC%9A%E8%AE%93%E4%BD%9C%E8%80%85%E8%83%BD%E7%B7%A8%E8%BC%AF%E5%9B%9E%E6%87%89 （天啊 2020 年）
還開了一張票想要改 API，不外乎就是要解決
• 回應會被自己、被別人加到不同訊息下，此狀況下什麼樣的編輯算合理？
• 編輯後，針對舊文字的 feedback 怎麼辦？
因此，現在的 status quo 就是請使用者刪掉重發，這樣最單純。
我覺得比起「編輯」，其實更容易做的是把「修改重發」自動化，也就是針對現有回應做出「更動」後，系統其實不會動原有的回應，而是
• 新增新的回應
• 把新的回應加到原有回應連結的訊息上（僅限作者自己加的）
• 把原有回應刪除（僅限作者自己加的）
也就是現在查核協作者可以自行操作的動作，改成一鍵完成這樣。UX 細節如下：
• 回應作者在任何自己撰寫的回應上點擊「修改重發」，會被導向到該 reply 的 detail 頁面。
• reply detail 新增編輯模式，可修改「我認為」分類、內文與出處。
• 送出按鈕上面的用語為「修改重發」，前面說明文字簡述說，修改後的文案會同時套用到自己所連結的可疑訊息，也就是下方「此查核回應尚被用於以下的可疑訊息」列出的訊息中，由自己加的那些。
• 按下「修改重發」後，跳出彈窗列出那些會被套用的網傳訊息，以及確認按鈕。
• 按下確認後，彈窗顯示套用的進度，以及往新回應 detail 頁面的連結。
以上功能都可以用現有 API 做到，不用開新的欄位，只要改 rumors-site。
過去針對「編輯回應」有這些討論：https://g0v.hackmd.io/OC7BneJ3TEGJHge1hWV-0w#%E8%A8%8E%E8%AB%96%EF%BC%9A%E8%AE%93%E4%BD%9C%E8%80%85%E8%83%BD%E7%B7%A8%E8%BC%AF%E5%9B%9E%E6%87%89 （天啊 2020 年）
還開了一張票想要改 API，不外乎就是要解決
• 回應會被自己、被別人加到不同訊息下，此狀況下什麼樣的編輯算合理？
• 編輯後，針對舊文字的 feedback 怎麼辦？
因此，現在的 status quo 就是請使用者刪掉重發，這樣最單純。
我覺得比起「編輯」，其實更容易做的是把「修改重發」自動化，也就是針對現有回應做出「更動」後，系統其實不會動原有的回應，而是
• 新增新的回應
• 把新的回應加到原有回應連結的訊息上（僅限作者自己加的）
• 把原有回應刪除（僅限作者自己加的）
也就是現在查核協作者可以自行操作的動作，改成一鍵完成這樣。UX 細節如下：
• 回應作者在任何自己撰寫的回應上點擊「修改重發」，會被導向到該 reply 的 detail 頁面。
• reply detail 新增編輯模式，可修改「我認為」分類、內文與出處。
• 送出按鈕上面的用語為「修改重發」，前面說明文字簡述說，修改後的文案會同時套用到自己所連結的可疑訊息，也就是下方「此查核回應尚被用於以下的可疑訊息」列出的訊息中，由自己加的那些。
• 按下「修改重發」後，跳出彈窗列出那些會被套用的網傳訊息，以及確認按鈕。
• 按下確認後，彈窗顯示套用的進度，以及往新回應 detail 頁面的連結。
以上功能都可以用現有 API 做到，不用開新的欄位，只要改 rumors-site。
10/22 高雄這篇寫還沒，要等明年
https://news.ltn.com.tw/news/life/breakingnews/4838925
11/7 新竹縣這篇官員受訪說「應該還沒有縣市政府完成設置」，新竹縣也要明年中以前才會有
https://news.ltn.com.tw/news/life/breakingnews/4855593
https://news.ltn.com.tw/news/life/breakingnews/4838925
11/7 新竹縣這篇官員受訪說「應該還沒有縣市政府完成設置」，新竹縣也要明年中以前才會有
https://news.ltn.com.tw/news/life/breakingnews/4855593
Okok
我這裡應該會直接讓 rumors-api 的 pm2 起另一台 nodejs http server 跑 OpenAPI
然後直接用獨立的 admin-api.cofacts.tw 與 admin-dev-api.cofacts.tw 這兩個網域分別指到 production 與 staging 的 OpenAPI
這樣要上 ZeroTrust 也不會影響現在的 api
我這裡應該會直接讓 rumors-api 的 pm2 起另一台 nodejs http server 跑 OpenAPI
然後直接用獨立的 admin-api.cofacts.tw 與 admin-dev-api.cofacts.tw 這兩個網域分別指到 production 與 staging 的 OpenAPI
這樣要上 ZeroTrust 也不會影響現在的 api
2024-11-09
滿奇妙的，這種影片都是在抖音
> 行人優先區，以行人步行為優先，*行人可於道路全寬通行*，於區內之車輛及行人應遵守道路交通安全規則之規定
所以這個地方根本就是步行區呀，像西門町那種吧
所以這個地方根本就是步行區呀，像西門町那種吧
都已經是步行區了還超速
根本想殺人吧
根本想殺人吧
之前在 Cofacts 也看到滿多反路權影片都是做這種形式
啊，寫還回應忘記引 @iacmai 的高雄的例子
但好懶惰
是不是該寫個修改回應之後一鍵刪除重貼的功能
但好懶惰
是不是該寫個修改回應之後一鍵刪除重貼的功能
Cofacts 上新聞 (?
https://today.line.me/tw/v2/article/kE3EWPZ
https://today.line.me/tw/v2/article/kE3EWPZ
LINE TODAY
一名曾在美國犯下未成年猥褻罪的43歲美籍男子，上月2日入境來台後行蹤不明，經美國在台協會通報後，移民署列管並不予許可居留，並發出公文提醒教育部等單位，協尋行蹤。 男子名叫Levi Forrest Wallace，23年前在俄勒岡州犯下對未成年性猥褻案，被判處有期徒刑90天、緩刑2年，並未遭到通緝，但他10月2日清晨入境來台後，卻未按照登記地址居住，行蹤不明。 為避免他停留間害台灣利益，或妨害善良風俗，美國在台協會進行通報，移民署得知後，即將Wallace列管，並不予許可居留。 移民署也在10月11日向警政署、外交部、勞動部及教育部發出密件公文，請各單位協尋男子行蹤，若有查獲或知悉立即通報。 由
- 📰2
Replied to a thread: 2024-11-08 20:10:13
想 propose 一個網站上「修改重發」回應的功能。
過去針對「編輯回應」有這些討論：https://g0v.hackmd.io/OC7BneJ3TEGJHge1hWV-0w#%E8%A8%8E%E8%AB%96%EF%BC%9A%E8%AE%93%E4%BD%9C%E8%80%85%E8%83%BD%E7%B7%A8%E8%BC%AF%E5%9B%9E%E6%87%89 （天啊 2020 年）
還開了一張票想要改 API，不外乎就是要解決
• 回應會被自己、被別人加到不同訊息下，此狀況下什麼樣的編輯算合理？
• 編輯後，針對舊文字的 feedback 怎麼辦？
因此，現在的 status quo 就是請使用者刪掉重發，這樣最單純。
我覺得比起「編輯」，其實更容易做的是把「修改重發」自動化，也就是針對現有回應做出「更動」後，系統其實不會動原有的回應，而是
• 新增新的回應
• 把新的回應加到原有回應連結的訊息上（僅限作者自己加的）
• 把原有回應刪除（僅限作者自己加的）
也就是現在查核協作者可以自行操作的動作，改成一鍵完成這樣。UX 細節如下：
• 回應作者在任何自己撰寫的回應上點擊「修改重發」，會被導向到該 reply 的 detail 頁面。
• reply detail 新增編輯模式，可修改「我認為」分類、內文與出處。
• 送出按鈕上面的用語為「修改重發」，前面說明文字簡述說，修改後的文案會同時套用到自己所連結的可疑訊息，也就是下方「此查核回應尚被用於以下的可疑訊息」列出的訊息中，由自己加的那些。
• 按下「修改重發」後，跳出彈窗列出那些會被套用的網傳訊息，以及確認按鈕。
• 按下確認後，彈窗顯示套用的進度，以及往新回應 detail 頁面的連結。
以上功能都可以用現有 API 做到，不用開新的欄位，只要改 rumors-site。
過去針對「編輯回應」有這些討論：https://g0v.hackmd.io/OC7BneJ3TEGJHge1hWV-0w#%E8%A8%8E%E8%AB%96%EF%BC%9A%E8%AE%93%E4%BD%9C%E8%80%85%E8%83%BD%E7%B7%A8%E8%BC%AF%E5%9B%9E%E6%87%89 （天啊 2020 年）
還開了一張票想要改 API，不外乎就是要解決
• 回應會被自己、被別人加到不同訊息下，此狀況下什麼樣的編輯算合理？
• 編輯後，針對舊文字的 feedback 怎麼辦？
因此，現在的 status quo 就是請使用者刪掉重發，這樣最單純。
我覺得比起「編輯」，其實更容易做的是把「修改重發」自動化，也就是針對現有回應做出「更動」後，系統其實不會動原有的回應，而是
• 新增新的回應
• 把新的回應加到原有回應連結的訊息上（僅限作者自己加的）
• 把原有回應刪除（僅限作者自己加的）
也就是現在查核協作者可以自行操作的動作，改成一鍵完成這樣。UX 細節如下：
• 回應作者在任何自己撰寫的回應上點擊「修改重發」，會被導向到該 reply 的 detail 頁面。
• reply detail 新增編輯模式，可修改「我認為」分類、內文與出處。
• 送出按鈕上面的用語為「修改重發」，前面說明文字簡述說，修改後的文案會同時套用到自己所連結的可疑訊息，也就是下方「此查核回應尚被用於以下的可疑訊息」列出的訊息中，由自己加的那些。
• 按下「修改重發」後，跳出彈窗列出那些會被套用的網傳訊息，以及確認按鈕。
• 按下確認後，彈窗顯示套用的進度，以及往新回應 detail 頁面的連結。
以上功能都可以用現有 API 做到，不用開新的欄位，只要改 rumors-site。
As discussed in <https://g0v.hackmd.io/@mrorz/cofacts-meeting-notes/%2F%40mrorz%2Fr1dQQZbmU|20200212 meeting>, we want to allow editor to edit their reply when • The reply is only used by the editor itself (the author should know the impact of the edit) • The reply has not yet received any feedback (the edit should now invalidate user's feedbacks) We plan to add 1 mutation API, and one new field to `Reply` type for this: """ The reason why the editor cannot edit """ enum ReplyUpdateBlocker { NOT_AUTHORIZED # Not logged in or not the author of reply HAS_FEEDBACK USED_BY_OTHER_EDITORS } type Reply { """ The reason why the current user cannot edit this reply. null if the current user can edit. The blockers are determined in the following order: (1) current user is the author or not (2) `positiveFeedbackCount` and `negativeFeedbackCount` are both 0 or not (3) all normal article-reply to this article are by the current author or not """ updateBlocker: ReplyUpdateBlocker } mutation { """ Updates reply text, type & reference when (1) current user is the author (2) `positiveFeedbackCount` and `negativeFeedbackCount` are both 0 (3) all normal article-reply to this article are by the current author """ UpdateReply( replyId: String! text: String type: ReplyTypeEnum reference: String waitForHyperlinks: Boolean = false ) { ""' The reply after update. `null` when update is not successful """ reply: Reply """ The reason why update fails. null when can update. """ blocker: ReplyUpdateBlocker } } "all normal article-reply to this article are by the current author" can be achieved by loading article-reply of a reply using <https://github.com/cofacts/rumors-api/blob/master/src/graphql/dataLoaders/articleRepliesByReplyIdLoaderFactory.js|`articleRepliesByReplyIdLoader`> and check each article-reply's author ID.
2024-11-11
> 在ZeroTrust設特定endpoint需要service token會比較簡潔
我覺得 admin endpoint 大概會有
• Badge 相關 API：新 badge 與把 badge 加到人身上
• 管版相關 API:
我看了一下
• Zero Trust / Application 是個可以指定 policy 的單位。但 Application
我覺得 admin endpoint 大概會有
• Badge 相關 API：新 badge 與把 badge 加到人身上
• 管版相關 API:
我看了一下
• Zero Trust / Application 是個可以指定 policy 的單位。但 Application
# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2024 -
但因為也不是正規的api shield (要enterprise) 所以權限管理上可能要用比較奇怪的方法 把application當成access group概念 有token就可以過
是ㄉ
2024-11-13
現在 Cofacts staging 機器上有兩個 docker-compose 跑起來的服務，不透過 nginx 而是直接走 cloudflared & Cloudflare tunnel 對應到兩個網域。
我看了一下 Cofacts 的 nginx config，其實所有東西都能用 Cloudflare 設定。這樣一來，是不是就可以把 nginx 關掉，然後通通都用 nginx 就好？ XD
我看了一下 Cofacts 的 nginx config，其實所有東西都能用 Cloudflare 設定。這樣一來，是不是就可以把 nginx 關掉，然後通通都用 nginx 就好？ XD
跟 @alex2002 聊的之後得到的經驗筆記
• 單台的時候，這種 tunnel 接到非公開 server 的方式非常好，因為不用對外開放一個 IP 接進來，而且 deploy 到哪裡都可以直接上線（在只有一台的狀況）
• 缺點：tunnel 只能有一個，要 load balance 的話要其他處理
• 單台的時候，這種 tunnel 接到非公開 server 的方式非常好，因為不用對外開放一個 IP 接進來，而且 deploy 到哪裡都可以直接上線（在只有一台的狀況）
• 缺點：tunnel 只能有一個，要 load balance 的話要其他處理
2024-11-14
Cofacts 這裡的圖與影片是用 signed url ，不確定這樣還會不會遇到 ihower 遇到的這種事情
https://www.facebook.com/share/p/18HpYzXc1Q/
https://www.facebook.com/share/p/18HpYzXc1Q/
signed url 不是一樣會被計算流量嗎？如果惡意使用者故意重覆下載同一隻影片 N 百次應該就會燒到 cofacts 的荷包了？
以前 s3 還有個 bug ，就是連 404 都會計量跟收費，所以你不用知道他有什麼檔案，你只要狂去 access 他的 bucket 就會害對方帳單爆表了
確實如此
我檢查了一下我的 signed URL 時間，目前是開 24hr XD
https://github.com/cofacts/rumors-api/blob/a43812f20b43daaa92a27bc42dcbc30912536230/src/graphql/models/Article.js#L552-L561
我檢查了一下我的 signed URL 時間，目前是開 24hr XD
https://github.com/cofacts/rumors-api/blob/a43812f20b43daaa92a27bc42dcbc30912536230/src/graphql/models/Article.js#L552-L561
我自己是用一台 linode 掛 s3fs/gcsfuse 開 cache
Cofacts 這裡的圖與影片是用 signed url ，不確定這樣還會不會遇到 ihower 遇到的這種事情
https://www.facebook.com/share/p/18HpYzXc1Q/
https://www.facebook.com/share/p/18HpYzXc1Q/
facebook.com
(被 DDoS 攻擊收到鉅額 GCP 帳單的經驗分享和求助) 網路上看到過幾次網站被 DDoS 而收到鉅額流量帳單的故事，沒想到這次的受害人是我自己 :tired_face: 大約半年前，我客戶網站上的一張放在 Google Cloud Storage (台灣 asia-east1 區) 的圖片，被 DDoS 攻擊，持續下載同一張圖片(500MiB/s，每秒 8k requests 來自歐美的七個 IP 位址)...
signed url 不是一樣會被計算流量嗎？如果惡意使用者故意重覆下載同一隻影片 N 百次應該就會燒到 cofacts 的荷包了？
以前 s3 還有個 bug ，就是連 404 都會計量跟收費，所以你不用知道他有什麼檔案，你只要狂去 access 他的 bucket 就會害對方帳單爆表了
確實如此
我檢查了一下我的 signed URL 時間，目前是開 24hr XD
https://github.com/cofacts/rumors-api/blob/a43812f20b43daaa92a27bc42dcbc30912536230/src/graphql/models/Article.js#L552-L561
我檢查了一下我的 signed URL 時間，目前是開 24hr XD
https://github.com/cofacts/rumors-api/blob/a43812f20b43daaa92a27bc42dcbc30912536230/src/graphql/models/Article.js#L552-L561
我自己是用一台 linode 掛 s3fs/gcsfuse 開 cache
signed url 不是一樣會被計算流量嗎？如果惡意使用者故意重覆下載同一隻影片 N 百次應該就會燒到 cofacts 的荷包了？
以前 s3 還有個 bug ，就是連 404 都會計量跟收費，所以你不用知道他有什麼檔案，你只要狂去 access 他的 bucket 就會害對方帳單爆表了
確實如此
我檢查了一下我的 signed URL 時間，目前是開 24hr XD
https://github.com/cofacts/rumors-api/blob/a43812f20b43daaa92a27bc42dcbc30912536230/src/graphql/models/Article.js#L552-L561
我檢查了一下我的 signed URL 時間，目前是開 24hr XD
https://github.com/cofacts/rumors-api/blob/a43812f20b43daaa92a27bc42dcbc30912536230/src/graphql/models/Article.js#L552-L561
2024-11-18
Replied to a thread: 2024-11-08 15:05:53
@jhk482001 增加 Admin API 的架構 PR 已發：
https://github.com/cofacts/rumors-api/pull/337
加一支 API 的 PR 大概會像這樣：
https://github.com/cofacts/rumors-api/pull/352
今晚開會的時候我也會講一次
晚上見~~
https://github.com/cofacts/rumors-api/pull/337
加一支 API 的 PR 大概會像這樣：
https://github.com/cofacts/rumors-api/pull/352
今晚開會的時候我也會講一次
晚上見~~
感謝! 🙏
今天開會時間是？
8pm 唷
歡迎來參加
歡迎來參加
Replied to a thread: 2024-11-08 15:05:53
# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2024 -
2024-11-19
感謝 @jhk482001 的 PR，昨天有 review xji
今天想到一個可能會影響 schema 的東西：如果未來有複數個 Badge manager，要怎麼區分「A 組織能發的 badge」與「B 組織能發的 badge」。
目前我的想法是
• Badge document 上紀錄這是誰發的 badge (具體來說是 service token 的 client ID，從 Cloudflare JWT token 中的 `common_name` 欄位拿)
• Admin API 增加一個 `post /badge` API 實作新增 badge，同時也把「誰發的 badge」寫進去。
• Admin API 的另一隻「給人 badge」的 API 會多做檢查說，要發的 badge 是不是跟 create badge 的人是同一個
目前我的想法是
• Badge document 上紀錄這是誰發的 badge (具體來說是 service token 的 client ID，從 Cloudflare JWT token 中的 `common_name` 欄位拿)
• Admin API 增加一個 `post /badge` API 實作新增 badge，同時也把「誰發的 badge」寫進去。
• Admin API 的另一隻「給人 badge」的 API 會多做檢查說，要發的 badge 是不是跟 create badge 的人是同一個
cc/ @jhk482001 @chunlin
現在 admin API 的各個 endpoint 的 `request` 都有 `userId` 可以判斷現在打 API 的人是誰～
https://github.com/cofacts/rumors-api/blob/master/src/adm/util.ts#L86
不過要注意的是，用 web 登入的人會跟 service token 視為不同人這樣
https://github.com/cofacts/rumors-api/blob/master/src/adm/util.ts#L86
不過要注意的是，用 web 登入的人會跟 service token 視為不同人這樣
感謝 @jhk482001 的 PR，昨天有 review 囉 https://github.com/cofacts/rumors-db/pull/74
> Design doc: <https://g0v.hackmd.io/@cofacts/rd/%2Fzx_Au6iiRN601tnMK7gx3A|https://g0v.hackmd.io/@cofacts/rd/%2Fzx_Au6iiRN601tnMK7gx3A> • Add 'badges' schema for maintain supported badges infromation • Add 'badges' to 'users' schema for maintain user obtained badge list
今天想到一個可能會影響 schema 的東西：如果未來有複數個 Badge manager，要怎麼區分「A 組織能發的 badge」與「B 組織能發的 badge」。
目前我的想法是
• Badge document 上紀錄這是誰發的 badge (具體來說是 service token 的 client ID，從 Cloudflare JWT token 中的 `common_name` 欄位拿)
• Admin API 增加一個 `post /badge` API 實作新增 badge，同時也把「誰發的 badge」寫進去。
• Admin API 的另一隻「給人 badge」的 API 會多做檢查說，要發的 badge 是不是跟 create badge 的人是同一個
目前我的想法是
• Badge document 上紀錄這是誰發的 badge (具體來說是 service token 的 client ID，從 Cloudflare JWT token 中的 `common_name` 欄位拿)
• Admin API 增加一個 `post /badge` API 實作新增 badge，同時也把「誰發的 badge」寫進去。
• Admin API 的另一隻「給人 badge」的 API 會多做檢查說，要發的 badge 是不是跟 create badge 的人是同一個
cc/ @jhk482001 @chunlin
現在 admin API 的各個 endpoint 的 `request` 都有 `userId` 可以判斷現在打 API 的人是誰～
https://github.com/cofacts/rumors-api/blob/master/src/adm/util.ts#L86
不過要注意的是，用 web 登入的人會跟 service token 視為不同人這樣
https://github.com/cofacts/rumors-api/blob/master/src/adm/util.ts#L86
不過要注意的是，用 web 登入的人會跟 service token 視為不同人這樣
今天想到一個可能會影響 schema 的東西：如果未來有複數個 Badge manager，要怎麼區分「A 組織能發的 badge」與「B 組織能發的 badge」。
目前我的想法是
• Badge document 上紀錄這是誰發的 badge (具體來說是 service token 的 client ID，從 Cloudflare JWT token 中的 `common_name` 欄位拿)
• Admin API 增加一個 `post /badge` API 實作新增 badge，同時也把「誰發的 badge」寫進去。
• Admin API 的另一隻「給人 badge」的 API 會多做檢查說，要發的 badge 是不是跟 create badge 的人是同一個
目前我的想法是
• Badge document 上紀錄這是誰發的 badge (具體來說是 service token 的 client ID，從 Cloudflare JWT token 中的 `common_name` 欄位拿)
• Admin API 增加一個 `post /badge` API 實作新增 badge，同時也把「誰發的 badge」寫進去。
• Admin API 的另一隻「給人 badge」的 API 會多做檢查說，要發的 badge 是不是跟 create badge 的人是同一個
2024-11-21
@thchu649 has joined the channel
2024-11-23
Replied to a thread: 2024-11-13 13:49:40
跟 @alex2002 聊的之後得到的經驗筆記
• 單台的時候，這種 tunnel 接到非公開 server 的方式非常好，因為不用對外開放一個 IP 接進來，而且 deploy 到哪裡都可以直接上線（在只有一台的狀況）
• 缺點：tunnel 只能有一個，要 load balance 的話要其他處理
• 單台的時候，這種 tunnel 接到非公開 server 的方式非常好，因為不用對外開放一個 IP 接進來，而且 deploy 到哪裡都可以直接上線（在只有一台的狀況）
• 缺點：tunnel 只能有一個，要 load balance 的話要其他處理
- ❤️1
2024-11-24
@aigaten has joined the channel
歌詞:
歌詞:
當收到可疑的訊息時怎麼辦
當收到可疑的訊息時找 Cofacts
疑似假新聞 假訊息 先不急
長按回傳訊息給Line bot處理
最新詐欺手法 無啥物
政治新聞的謠言 一次搞定
靠大家的團結力 打敗惡勢力
由 Cofacts 來照你
當收到可疑的訊息時怎麼辦
當收到可疑的訊息時找 Cofacts
疑似假新聞 假訊息 先不急
長按回傳訊息給Line bot處理
最新詐欺手法 無啥物
政治新聞的謠言 一次搞定
靠大家的團結力 打敗惡勢力
由 Cofacts 來照你
- 🙌2
Health Check Name: api.cofacts.tw
Health Check ID: 86c058fd4a13c3a35fd33ecb2c6e74cf
Time : 2024-11-24 09:23:34 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:24:09 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: line-bot.cofacts.tw
Health Check ID: 43bacff73e318b0ee85fdcda1f7d8627
Time : 2024-11-24 09:25:10 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:29:09 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:33:30 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:37:00 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:40:50 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
看起來 API、網站、 LINE bot 在 11/24 17:23~18:50 不明原因倒站（served by origin 驟降）
但沒看到奇怪的攻擊 spike
但沒看到奇怪的攻擊 spike
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:46:00 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 09:52:10 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:05:41 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:08:11 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:14:31 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:19:21 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:24:12 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:37:32 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:38:55 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:46:42 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:50:33 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 10:54:23 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: line-bot.cofacts.tw
Health Check ID: 43bacff73e318b0ee85fdcda1f7d8627
Time : 2024-11-24 11:01:11 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
2024-11-25
Health Check Name: api.cofacts.tw
Health Check ID: 86c058fd4a13c3a35fd33ecb2c6e74cf
Time : 2024-11-24 19:34:49 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 19:34:53 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: api.cofacts.tw
Health Check ID: 86c058fd4a13c3a35fd33ecb2c6e74cf
Time : 2024-11-24 19:46:05 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
Health Check Name: cofacts.tw
Health Check ID: 26c31cd565ee9448e8cff64528205cd3
Time : 2024-11-24 19:49:07 +0000 UTC
Status: Unhealthy
Failure reason: HTTP timeout occurred
咦，原來昨天有被打
咦，原來昨天有被打
Replied to a thread: 2024-11-24 17:41:07
看起來 API、網站、 LINE bot 在 11/24 17:23~18:50 不明原因倒站（served by origin 驟降）
但沒看到奇怪的攻擊 spike
但沒看到奇怪的攻擊 spike
Health Check Name: api.cofacts.tw
Health Check ID: 86c058fd4a13c3a35fd33ecb2c6e74cf
Time : 2024-11-25 06:24:16 +0000 UTC
Status: Unhealthy
Failure reason: Response code mismatch error
Expected codes: [200]
Received code: 502
LINE bot server 好像死翹翹好一陣子，剛才我要更新 API 時才發現
LINE bot server 好像死翹翹好一陣子，剛才我要更新 API 時才發現
# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2024 -
cc/ @jhk482001 @chunlin
現在 admin API 的各個 endpoint 的 `request` 都有 `userId` 可以判斷現在打 API 的人是誰～
https://github.com/cofacts/rumors-api/blob/master/src/adm/util.ts#L86
不過要注意的是，用 web 登入的人會跟 service token 視為不同人這樣
https://github.com/cofacts/rumors-api/blob/master/src/adm/util.ts#L86
不過要注意的是，用 web 登入的人會跟 service token 視為不同人這樣