2023 名古屋

高山陣屋

去年十一月底的時候,安排了一趟名古屋的旅遊,一開始的目標很簡單,就是帶小孩去樂高樂園,所以挑選了名古屋,結果這趟旅遊在出發前還真是一波三折,首先是因為差不多快要楓葉季了,所以挑選時間時就想說挑個可以順便看楓葉的時間,又考量到公司專案的時程,兩週不錯的時間挑了第二週,和本來那個專案的時間差了兩三週,結果公司專案最後還是拖到我出國前還沒上線;接著在規劃行程時,本來想說一天去下呂溫泉,然後前面四天後面五天都在市區或是近郊,接著看回程要怎樣到機場時,考慮到有想多買行李箱,所以可能無法搭電車,就看了一下計程車費,不意外的很貴,想了一下去查了一下租車一天的價錢,結果發現差不多!但是都租車了,乾脆多租幾天在附近玩,所以就看起了中部國際機場所在的知多半島的觀光景點,發現有虎河豚套餐可以吃,後來老婆覺得可以不用太多小孩行程,想去飛驒高山,排到最後變成:

11/25 名古屋車站
11/26 Toyota 博物館、大須商店街
11/27 栄、Harbs 本店、東山植物園
11/28 Lego Land
11/29 三井 Outlet、名花之里
11/30 飛驒高山
12/01 下呂溫泉
12/02 犬山城、住南知多(源氏香)
12/03 知多半島、河豚套餐
12/04 臨空區、機場回程
閱讀「2023 名古屋」全文

源氏香 南知多

源氏香

前陣子去了一趟名古屋,一開始其實只是想說帶小孩去樂高樂園,結果行程規劃從一開始的名古屋市區和周邊為主,弄到後來變成市區五天租車五天的,然後打算最後一天住在機場旁邊,就想說那前一天就在附近玩玩好了,要去的地方就因此多了一個一開始完全沒考慮過的「知多半島」了,當然也有研究住宿,當時也有找到「源氏香」這間旅館,不過那時候已經有安排了下呂溫泉的溫泉旅館,所以就沒考慮這個價位的住宿了,就在一切都安排好後沒幾天,突然就看到 FB 上有人分享到他們有特別的,針對台灣人的免費體驗方案,就是入住後要在 SNS 上分享。

閱讀「源氏香 南知多」全文

Sign-in with OOO ID

最近工作上在研究 Sign-in with Apple/Google ID,其實這件事情也作過很多次了,不過距離上次也有點久了,不知道那些 SDK 有沒有什麼改變,所以還是要重頭來,而且這次多研究了一個 Apple,有搞懂些以前沒釐清的細節,想說紀錄一下。

首先就是,我發現到 Google 和 Apple 現在都會回一個 ID Token,內容則是 JWT,而且是認真的 JWT,真的會有帶一點使用者資料(像是 email)的,可以用來作 user authentication(認證)用的,這在以前只有 OAuth 2.0 的時候是沒有的,查一陣子資料才發現這其實是 OpenID Connect(簡稱 OIDC) 規範的,該規範是是 2014 年發布的,其實還比 JWT 早定稿。

相較於 OAuth 2.0 做的是 authorization(授權),OIDC 做的則是 authentication(認證),只不過 OIDC 是整個依附在 OAuth 2.0 的架構上,利用的就是 OAuth 2.0 的 response_type,本來只有codetoken兩種,在 OIDC 多提供了 id_token,ID Token 是用 JWT,而且也有明確定義有裡面的 user profile 相關的欄位(不是定義哪些是必須提供,而是定義好語意和對應的欄位名稱)。

第二個則是我一直存疑已久的問題,就是 OAuth 2.0 的設計上基本是用 redirection flow,而且 redirect_uri 也是必要的,但是 Google 其實一直都支援純 JS 的方案,也就是說 Relying Party(應用程式端)不需要實作一個 redirection endpoint 來接資料,前端的 JS 就可以直接拿到 authorization code 和 access token,這次也認真的研究了這個問題,結果發現,Apple 的 OAuth 流程中,response_mode 給的值是目前不在標準內的web_message,而 Google 則是 redirect_uri 給的是一個沒見過的 scheme:storagerelay://的 URI。

其實我一開始以為這些設計,是各個公司自己想一想然後就自己做下去的,結果沒想到其實不是,首先是 Apple 的實作,用的是 OAuth 2.0 Web Message Response Mode 這份草稿的設計,這份草稿其中一位作者 Nat Sakimura 現在是 OpenID 的 chairman,而且他也是其他很多相關規範的作者(像是 JWT),不過這份草稿只有一版且沒人更新,有很多細節沒有寫定,大部分都是提供範例程式碼而已,所以 Apple 有些東西不是照範例做,例如 message 的 payload;Google 實作的則是 OAuth 2.0 IDP-IFrame-based Implicit Flow,這份文件其實是我最後才找到的,因為這份只有出現在 OpenID 的 mailing-list,而且也完全沒有討論和更新,不像前一份還有發到 IETF,回到文件內容,這份的作者,就全部都是 Google 的人了,內容完整許多,也有定義好 message 的 payload 結構,不過還是有些細節有缺,像是認證完成後的回傳事件,現在 Google 用的事件名稱在這份文件中就找不到。

除了這兩份草稿外,其實還有一份是 Curity 提出的 OAuth 2.0 Assisted Token,一樣有發到 IETF,而且還比較有在更新,最新一版是 2021 的,Assisted Token 的設計是多給了一個流程叫做 Assisted Token Flow,用不一樣的 URL 來使用這個 flow,這個流程的最後一步就是 postMessage 回到 opener/parent,規範寫的比較完整,包括各種新屬性的 registry、message 的 payload,還有安全性相關的考量都有,不過我看一看有些地方覺得有些疑惑,第一個是 message payload 的結構似乎辨識度沒很高,第二個則是完全沒提到 refresh token 和 authorization code,不確定是目前還沒考慮到那邊,還是因為安全性考量把它們先排除。

第三個是 Apple 的實作,雖然基本上還是照著 OAuth,但是其實限制更多,首先就是,scope就只有 email 和 name 可以拿,而且 Apple 做成,只有第一次 authorization 時,會把 user profile 傳給 RP,之後是拿不到的(不過 email 有在 id token 內),然後,雖然可以拿到 access token,但是其實完全沒有可以使用它的 API endpoint,所以什麼事情都不能作,真的只能用來做 authentication,最後一個,就是用 code 換 token 時,要給的client_secret參數還特別麻煩,要自己組一個 JWT(但是也因此會 expire 比較安全),然後用之前從 Apple Developer 後台生好的 secret key 去算 signature。

最後一個想紀錄的就是,這幾份標準和文件裡面幾乎都有一個章節是 Security Consideration,內容雖然不全面但是還蠻值得一看的,也有提到一些攻擊手法,而除此之外,其實還有一份文件:RFC6819: OAuth 2.0 Threat Model and Security Considerations,內容就是有說明 OAuth 2.0 各種設計在安全性上的考量(像是為什麼有 Refresh Token,什麼情境下它有助於安全性的提升),以及各種可能的攻擊手法。


Celeste

Celeste

一直想寫一篇關於 Celeste(蔚藍山脈)的文章,不過拖了很久一直寫不出來,其實我當初也是拖了很久才玩的。我因為原本就很喜歡 2D 的平台遊戲,然後看到 Celeste 的介紹覺得很特別,以登山為目標,沒有戰鬥但是有挑戰性的平台遊戲,多麼特別啊!所以 2019 年我就把它買下來了,還是 Limited Run Games 的版本,結果買回來後,稍微玩一下覺得怎麼難到爆炸,就放置了。

後來到了 2021 年底,在 FB 看到橘子說他登頂了,我才一點手癢一點不服輸的又重拾了起來,結果這次就順利了突破一開始的障礙,漸漸的上手了起來,後來橘子更是把全部的關卡包括第九章都過完了,本來想說我 B 面 C 面不勉強(有多難可以參考机核的文章:《蔚蓝:Celeste》:每个人心中都有一座山,但并非每个人都能登上山顶),結果還是不服輸的就慢慢的也都過完了,必須說這關卡難度的曲線設計的真的是非常棒,最後花了一個月左右,遊戲時間 50 多小時,成績是把全部關卡通過,收集到所有除了黃金草莓以外的草莓,認真的說,這遊戲真的很難,我相信一定很多人無法達到這樣的成績,當然我也不是要說我多厲害,因為我這樣的成績還不是全要素收集,更上一層還有無死通關的金草莓,不過這樣的挑戰歷程已經讓我想寫文章記錄下來了。

Celeste

我覺得這款遊戲最讓我感到厲害的,就是它遊戲的內外呼應,遊戲內的故事主軸是登山,而在了遊戲故事之外,這款遊戲也設計成了一個讓人攀登的高山,關卡和整體的難度就是設計的非常精巧,大家都可以在山腳出發,但是可能只有一半人能到五成高度,到了八成高度的地方就只剩下兩成,而真正能到達山頂,達成全要素,收集到所有的草莓,真正見到最後那個山頂風景的,就只有少數的那些玩家,那 26 個黃金草莓,全世界登記有案能拿到的大約只有三百多人台灣也有至少一位),Celeste 也有賣出一百萬套左右,也就說只有萬分之三的人,能夠到達這款遊戲的真正的山頂(要素的山頂、還有另一批人在拼 speed run)。

本來還想要介紹更多的東西,但是寫了兩三次都不盡如意,最後決定,留下這篇文章作為自己參與了這段挑戰的紀錄,我到現在偶爾,都還會拉出當時登山時的一些影片紀錄,有些關卡真的是非常困難,難到讓人過關時都忍不住會按下 Switch 的錄影按鍵紀錄下來,甚至也不少是功虧一簣的紀錄,當然,我拿到最後一顆 moon berry 的紀錄也有,當時也有貼在 FB 上。

附上幾篇開發相關的延伸閱讀:

其他延伸閱讀可以參考橘子的第二篇 FB 貼文。


➡ 看看其它文章