鳥山明過世

鳥山明訃報

今天(2024-03-08)官方發布的消息,七龍珠的作者鳥山明在三月一日時因病過世了,JUMP 也有訃報,而且還有堀井雄二、桂正和、尾田栄一郎和岸本斉史的緬懷文(巴哈姆特 GNN 有譯文),在緬懷鳥山明之餘,想來紀錄一下我對七龍珠系列的一些小心得。

首先是作者名字,其實我小時候一直搞錯,而且搞錯很久,把「鳥」當成「島」,即使到現在我都還需要在腦中確認一下,然後直到今天我才知道名字的念法(Akira Toriyama);然後就是雖然現在大家對於 Z 那段的印象是很拖,但是其實拖的是電視動畫而已,後來我回去重看漫畫時,其實節奏還蠻明快的,當然有不少轉折拉長連載的時間,但不會在同一段劇情上拖拖拉拉;然後另外一個印象就是角色強度的通膨,以前總有個是不是一直吃書改設定的印象,像是佛力札已經號稱是宇宙最強了,怎麼後面還可以一直有更強的角色,後來重看漫畫才發現其實沒有,宇宙帝王佛力札就是在那個時間點的該宇宙中戰鬥力最高的人,接在後面的人造人是紅緞帶軍團製造出來的,魔人普烏則是古早時候就被大界王神封印的,所以佛力札作威作福時人造人還不存在,普烏則是被封印的狀態。

然後動畫故事到魔人普烏之後的續作,有「GT」和「神 vs 神」、「超」那一個系列的兩個線,其實我兩部都蠻喜歡的,比較早的 GT 是鳥山明沒有參與的,這邊就先略過,後來好不容易鳥山明回來參與的「神 vs 神」劇場版開始的世界設定,擴展了整個世界/宇宙的設定,從和界王神成對的破壞神開始到後來的多重宇宙、超級賽亞人 Blue、全王等等,我覺得都很非常的精巧,有趣而且最厲害的是沒有破壞到既有的設定,只能說真不愧是鳥山明,不知道這些設定有多詳細,和未來的企劃也不知道有多少關聯(像是那個還沒開始的大魔),不管如何,都是無限讓人惋惜啊。

最後想放一個 YouTube 的影片連結:

https://www.youtube.com/watch?v=aOXs5hg0a5Y

這是龍珠超最後悟空和吉連對決最高潮的片段,也就是悟空進入「身勝手の極意」狀態的片段,似乎是在墨西哥的非官方?公開放映的景象(一開始有非授權的放映,但是後來有各種地方政府取得授權的放映活動),當初看到這影片的時候就覺得很驚訝,沒想到會在離日本這麼遙遠的地方,有個國家這麼多人都對七龍珠有這麼大的熱情,真的是個空前的成就。

追記:在發文的時間點,推特(現在的 X)的日本的 Trends 上沒有鳥山明,不過其實有三個相關的:「かめはめ波」、「スーパーサイヤ人」和「国民栄誉賞」。

Japan Trends 2024-03-08



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,什麼情境下它有助於安全性的提升),以及各種可能的攻擊手法。


➡ 看看其它文章