実録!!Python Social Auth の Twitter OAuth API マイグレーションプロジェクトとその教訓

PyCon APAC 2023の登壇資料です。
https://2023-apac.pycon.jp/timetable?id=FQLVVU

Transcript

1. Python Social Auth の Twitter OAuth API マイグレーションプロジェクトとその教訓 2023.10.27@PyCon APAC 2023
2. Takanori Koroki (興梠敬典) @rocky_manobi https://github.com/rockymanobi https://lapras.com/public/rocky_manobi CTO@LAPRAS株式会社 2009年からSWEをしていて、エンプラ/Webサービス等々色々作ってました
3. Python Social Auth の Twitter OAuth API マイグレーションプロジェクトとその教訓 2023.10.27@PyCon APAC 2023
4. はじめに 本セッションでは、 実際に行った「Python Social Auth の Twitter OAuth API マイグレーション対応」を題材に、 その背景や対応内容、結果、感想、学びなどなどについて共有してまいります。 - OAuth APIのマイグレーションを行う際に注意すべきポイント - 依存しているサービスやOSSの変更対処の考え方の一例 などをご提供できれば良いなと考えプロポーザルを出しました。 しかしながら....
7. ネタ枠としての期待にも答えなければならないのか
8. はじめます
9. Python Social Auth の Twitter OAuth API マイグレーションプロジェクトとその教訓 ◆ 前提知識の共有 ソーシャルログインや、今回の対応の背景情報について軽く触れつつ、 本セッションで題材にするシステム/サービスについてご紹介します。 ◆ 実録マイグレーションプロジェクト 無料API廃止アナウンス及びその後の動きに対するLAPRASでの対応について、 システム的な内容を含めてご紹介します。 ◆ 結果と振り返り 対応プロジェクトの結果や各局面における判断について振り返り、 今回得た学びを共有します。 ◆ まとめなど
10. 前提知識の共有
11. 前提知識の共有 - ソーシャルログインについて
12. ソーシャルログイン
13. ソーシャルログイン 会員登録やログインの手間の軽減 - 情報入力を簡略化することができる - ログインに必要な情報を増やさずに済む※ SNS情報の取得とサービスへの活用
14. - Firebase Authentication - Auth0 - okta - Stytch - AWS Cognito ソーシャルログイン - 実装の選択肢 IDaaS等のサービスを利用 OAuthプロトコルを直接利用 https://github.com/joestump/python-oauth2 https://github.com/pennersr/django-allauth https://github.com/python-social-auth ◆ django-allauth ◆ python-social-auth ◆ python-oauth2 例 : 以下のようなライブラリが利用可能 例 : 以下のようなサービスが利用可能
15. - Firebase Authentication - Auth0 - okta - Stytch - AWS Cognito ソーシャルログイン - 実装の選択肢 IDaaS等のサービスを利用 OAuthプロトコルを直接利用 https://github.com/joestump/python-oauth2 https://github.com/pennersr/django-allauth https://github.com/python-social-auth ◆ django-allauth ◆ python-social-auth ◆ python-oauth2 例 : 以下のようなライブラリが利用可能 例 : 以下のようなサービスが利用可能 今日のお話は python-social-auth にフォーカス システム的な課題については他のライブラリでも同じよ うな課題が発生しそうではあります。 (内部を軽く見た感想なので要出典です) 今回は触れませんが、 最近は直接利用よりもIDaaSを積極的に利用する流れが 強い印象です(私も同意です)
16. ソーシャルログイン https://speakerdeck.com/yktakaha4/python-social-authdexue-bu-oauth2-dot-0ren-ke-kodohuroniokeruyi-chang-xi-henodui-chu @yktakaha4 さんの PyCon JP 2022 のセッション発表資料を読むと、 ソーシャルログインやOAuth2.0の認可フローについての理解が深まります。 あわせて読みた い
17. 前提知識の共有 - Twitter API騒動
18. Twitter API 騒動 2023.02.02 「1週間後の2月9日にAPIの無料アクセス廃止する よ」 EnterPriseなのに止まった！ 2月9日になったのにアナウンスがない?? API v1.1死んだ？ API使えなくなったのでサービス終了します ログインできなくなりました 落ちた！！ 2023.07.24 「Xになったよ」 2023.08.22 「API v1.1も続々廃止していく よ」 なんか復活した? API制限でツイート見られない？ 2023.01.xx 「昔からあるルールをちゃんと守っていないアプリはAPIアクセスをブロックする よ」 100$/月 !?? 対応完了しました
19. 前提知識の共有 - 題材となるシステムの紹介
22. データ収集 ポートフォリオ データ構築 ビジュアライズ
23. Userサポートのための Twitter監視のためのツ イート取得APIコール データ収集 ポートフォリオ データ構築 ビジュアライズ データ取得のための APIコール ユーザ認証のための APIコール(主にOAuth) Crawler こちらが今日のメインです 話題にはでてきます
25. サポートしているログイン方式
26. 本編 - マイグレーション対応
27. 2023.02.02 ~ 2023.03.30 無料API廃止宣言
28. https://twitter.com/XDevelopers/status/1621026986784337922?s=20
29. そのときのわたし 気分転換タスクを片付けていい気分だった 出社日をお祝いしてくれるSlackBotの新verを作っていた
30. 影響調査 2023.02.02時点では料金や必要な手順などの情報は一切不明であったため、 Twitter APIが一切使用できなくなることを想定して一次調査を実施した。 Crawler への影響 画面に表示するTwitterアカウントページへのリンク、 フォロワー数等の情報が取得できなくなる => 最悪許容するしかない ログイン・新規登録 への影響 Twitterによるログイン・新規登録ができなくなる => 最悪許容するしかない => ログイン手段がTwitterのみであるユーザはサービスにログインする手段を失う可能性があり、こ の事象は許容できない が、事後でもユーザの操作のみで救済できるルートが確率されている = メール アドレスによるログインを追加できる(※) ことを確認できたため、ケアができていると判断 ※サービス登録時、SNSによる認証であってもメールアドレスを入力する仕様があり、 このメールアドレスを指定してパスワードリセット操作を実行すると以後メールアドレスとパスワードでログインが可能
31. 影響調査 - 事業数字周り 新規獲得への影響 => 軽微 注力ターゲット(当時) のうち、 Twitter広告経由かつTwitter連携で獲得できているユーザは全体の1% MAU / DAU => 軽微(+) 当月のアクティブユーザのうち、 Twitterが唯一のログイン手段であるユーザの割合は0.3%。 ※ただし、普段遣いでTwitterを用いているユーザがその他の手段を取ることが面倒になり... というケ ースは考えられる ※サービス登録時、SNSによる認証であってもメールアドレスを入力する仕様があり、 このメールアドレスを指定してパスワードリセット操作を実行すると以後メールアドレスとパスワードでログインが可能
32. 影響調査 APIアクセスをCloseされたとしても 致命傷には至らないことは分かったので、 続報を待つことに
33. その後 正式な続報が 3月30日 に展開されますが...
34. おまけ！ おまけ - Xデーとされた 2月9日 https://twitter.com/XDevelopers/status/1623467615539859456 https://twitter.com/XDevelopers/status/1623467618400374784 https://twitter.com/XDevelopers/status/1623467619725774848 追加情報は展開されるも、 細切れなので具体的な対処には踏み切れない
35. おまけ！ おまけ - 対応延期の報 https://twitter.com/XDevelopers/status/1625234161010343941 https://twitter.com/XDevelopers/status/1626732269174943745 これまで発信した方針はまだ活きている けれど段階的に進めていくよ...てきな。
36. https://www.itmedia.co.jp/news/articles/2303/13/news159.html おまけ - 各所の反応や情報発信 https://twitter.com/maximehugodupre/status/1625237066115084311?s=20&t=9midKkco2YTM2gvVhmlC4A 2/14
37. 2023.03.30 - 新しい料金体系と移行スケジュールの発表 https://twitter.com/TwitterD ev/status/1641222782594 990080?s=20
38. 現在はPROプランが存在するが、 この時点ではアナウンスもされていない
39. Crawler - API v2.0 を利用するように変更する - rate limit を上回る場合はplanを変更する (こちらもややこしい経緯がありますが今回は割愛します) ログイン・新規登録 - 対応しない - 厳密に言うとここについては自信を持てる状態ではなかった。 しかしながら、一時的なダウンは許容できるという評価と、仮に v1.1廃止に伴 う影響があるとしても局所対応が可能であると判断。 加えて、これまでの経緯からアナウンス通り対応したとしても影響無しで対処 しきれるとは考えられなかったため、事実が確定する事後対応のスタンスをと ることにした。 - 料金体系が変更される(無料 or 100$ or Enterprise) - API v1.1 が廃止される (これは誤解。最後に触れます) - OAuthAPI v1.0a は引き続き利用できる(廃止の報に含まれていない) 解釈 対応 方針
40. おまけ - 2023.04.04 に起きた2つのできごと https://twitter.com/koni/status/1643047128745512960 Enterprise APIを利用しているサービス含め、 APIが予告なく凍結される騒動も https://social-dog.net/ja/
41. おまけ - 2023.04.04 に起きた2つのできごと 柴犬をシンボルとする暗号資産「ドージコイン」が30%急騰したらしいです https://twitter.com/koni/status/1643047128745512960 Enterprise APIを利用しているサービス含め、 APIが予告なく凍結される騒動も https://social-dog.net/ja/ メイン画面左上のアイコンが柴犬に変更される 心中お察しします
42. 2023.04.27 強制Suspended 突如Twitterログインができなくなる
44. 緊急対処 : メッセージ表示による通知 / ログインボタンの非表示化など
45. 無傷での対応は不可避 最速でのTwitterログイン機能を復旧する道をとるならば Crawlerやサポート用のアプリを消去すれば良いが... 強制的なプラン移⾏によって、無料プランの「1アカウントに紐付けられるアプリ 数 =1個」が適⽤され、溢れた分が全てsuspendされた。 suspendされる多少はランダムのようだった。 OAuth v1.0aは廃⽌されてはいなかった(ここは想定通りではあった) dev⽤, staging⽤は消せるが、その他のAppは本番動作している。 異なるアカウントで新しくAppを作成すると OAuth v1.0a、API v1.1 は使えない。 API v2.0移⾏対応は完了していない。 原因 - APIの廃止ではなくアプリの数制限に抵触した
46. 消したとして...まともに動くのか？ APIが中途半端に動く状態である可能性も否定できない 我々のシステムはその状態を想定できているだろうか.... (ものすごく検証しづらい) 仮に無事復旧ができたとして、 今後のイレギュラーにも付き合い続けられるのか...？ (この対応中に更にサプライズが起きて状況が悪化する等あれば、機能のサポートをそのままクローズさせることも考えていました) 対応方針 最速でのTwitterログイン機能を復旧する道は取らない。 Twitterに関連する機能をクローズしたまま、利用APIを全て最新のものに入れ替える等、 安全性・確実性がもっとも高いと考えられる方法をとる。 APIはv2.0に上げる。OAuth API も2.0に上げる。 ただし、事業数字であるDAUや新規登録数に悪影響が見られた場合は方針を転換する。 結論
47. https://developer.twitter.com/en/docs/twitter-api 当時のアナウンス 現在のWebページの表記 おまけ - 言い訳のスライド 今振り返ればアナウンスはあったと言えるが...
48. 2023.04.27 ~ 2023.06.05 システム的対処
49. A. python-social-auth を Twitter OAuth API v2.0 に対応させる B. アプリ側のマイグレーション課題の解決 C. QA / リリース システム的対処 python-social-auth を題材にお話しますが、 おそらく同じようなところが問題になりそうな気がします
50. システム的対処 - python-social-auth を Twitter OAuth API v2.0 に対応させる
51. python-social-auth の構造 social-core social-app-django python-social-auth のコアロジック ソーシャルログインに関する共通的な機能やインターフェイスを提供 認証プロバイダ毎の固有実装(backendと呼称されている) いくつかのリポジトリ/パッケージに分かれている social-core をDjango に組み込むための各種機能を提供 - Model / View / Middleware / etc,
52. 使い方は social-docs というリポジトリに https://github.com/python-social-auth/social-docs python-social-auth の構造 social-core には各種OAuthプロバイダに対応するclassが定義されている settings.py にて利用するプロバイダを指定
53. OAuth2.0用の backendが無かったので これを実装 python-social-auth を Twitter OAuth API v2.0 に対応させる ここの実装についての詳細は割愛します。 [参考] https://github.com/python-social-auth/social-core/pull/791
54. - 先々social-coreに破壊的変更が発生した場合に、リポジトリ内部においているコードは取り残され てしまう / 誰かが別の実装の TwitterOAuth2対応を行った場合ややこしいことになる - リポジトリに用意されたテストのヘルパー等を利用したテストを実行できる - contributionフローにのっとりつつ、メンテナのレビューを通ることで意識できていないリスクをあ る程度減らすことができる - 後述する、アプリ側のOAuthAPIのマイグレーション対応が開発負荷としては比重が大きく、こちら が早く終了しても対応完了は早くならない - mergeされない、リリースされない場合はそれがわかってからでもforkしたものを参照する/リポジ トリ内部でbackendを実装するという手段を取ることができる 手元のリポジトリ内部にオリジナルのバックエンドとして実装する選択肢はとらず、 あくまで本家に取り込んでもらうルートをベストシナリオとして対応した。 python-social-auth を Twitter OAuth API v2.0 に対応させる ここの実装についての詳細は割愛します。 [参考] https://github.com/python-social-auth/social-core/pull/791 OAuth2.0用の backendが無かったので これを実装
55. - 先々social-coreに破壊的変更が発生した場合に、リポジトリ内部においているコードは取り残され てしまう - リポジトリに用意されたテストのヘルパー等を利用したテストを実行できる - contributionフローにのっとりつつ、メンテナのレビューを通ることで意識できていないリスクをあ る程度減らすことができる - 後述する、アプリ側のOAuthAPIのマイグレーション対応が開発負荷としては比重が大きく、こちら が早く終了しても対応完了は早くならない - mergeされない、リリースされない場合はそれがわかってからでもforkしたものを参照する/リポジ トリ内部でbackendを実装するという手段を取ることができる 手元のリポジトリ内部にオリジナルのバックエンドとして実装する選択肢はとらず、 あくまで本家に取り込んでもらうルートをベストシナリオとして対応した。 python-social-auth を Twitter OAuth API v2.0 に対応させる ここの実装についての詳細は割愛します。 [参考] https://github.com/python-social-auth/social-core/pull/791 OAuth2.0用の backendが無かったので これを実装 CTOならそれくらいやりなよ - 一緒にやるからさ という @yktakaha4氏からの温かいお声掛けもあり...
56. social-auth-app-django social-auth-core LAPRAS アプリへの取り込み LAPRASからは「social-auth-app-django」を経由して利用している。 - [ ] masterマージ - [ ] リリース - ✅ masterマージ - [ ] リリース - [ ] 依存バージョン更新
57. social-auth-app-django social-auth-core LAPRAS アプリへの取り込み LAPRASからは「social-auth-app-django」を経由して利用している。 - [ ] masterマージ - [ ] リリース - ✅ masterマージ - [ ] リリース - [ ] 依存バージョン更新 PR作成から2weeksでマージしてもらえた(ありがたい)、 なかなかリリースはしてもらえなかった(しかたない) (直近は1回超/月はリリースされていたのに...)
58. social-auth-app-django social-auth-core LAPRAS アプリへの取り込み 「social-auth-core」を手元でビルドしてLAPRASのコードにtar.gzを配置しつつ、 pyproject.tomlを以下のように記述して取り込む (poetry利用) 手元でビルドして取り込み ※本家のmasterには入っているので今後のアップデートがTwitterOAuth2のコードを無視 して進む危険性はないので一旦はよしとした。
59. 未だリリースされていない。メンテナ名のり出る必要があるのかもしれない
60. システム的対処 - アプリ側のマイグレーション課題の解決
61. 課題 1 以前に Twitter OAuth v1.1 で登録/ログインしていたユーザが、 Twitter OAuth v2.0 の認可フローを通ってログインを試みたとき、 別人として扱われ、新規登録フローにすすんでしまう
62. python-social-auth では OAuth認可フローを通過した後の各処理が細切れに実装されている。 => pipeline functionと呼称 python-social-auth の構造 詳しくはコチラに https://zenn.dev/rocky_manobi/articles/438cd4f01166af pipeline function は 定義された実行順序の通りに実行される 各 pipeline functionが戻した値は次に実行される関数に 引数として渡されていく
63. Appのログインセッションが活きていない場合 - UserSocialAuthというモデル(テーブルを) provider と uid をキーにして検索し、 既に存在しているかどうかを判定 - 存在する場合は「既存ユーザのログイン」と判定 存在しない場合は「新規ユーザの登録」と判定 セッションが活きている場合 - UserSocialAuthというモデル(テーブルを) provider と uid をキーにして検索し、 現在ログインしているユーザと一致しているか否かを調べる - 一致していない場合は「既に他のユーザと紐づいている」エラーとする 原因と解決策
64. Appのログインセッションが活きていない場合 - UserSocialAuthというモデル(テーブルを) provider と uuid をキーにして検索し、 既に存在しているかどうかを判定 - 存在する場合は「既存ユーザのログイン」と判定 存在しない場合は「新規ユーザの登録」と判定 セッションが活きている場合 - UserSocialAuthというモデル(テーブルを) provider と uuid をキーにして検索し、 現在ログインしているユーザと一致しているか否かを調べる - 一致していない場合は「既に他のユーザと紐づいている」エラーとする Twitter OAuth API v1.0a の場合の provider は “twitter” Twitter OAuth API v2.0 の場合の provider は “twitter-oauth2” 検索キーとなる値が異なるため、 常に新規作成ユーザ と扱われてしまっていた 原因と解決策
65. Providerが”twitter-oauth2”である場合には、 provider = twitter であるデータを探して判定する pipeline fnctionを作成
66. Providerが”twitter-oauth2”である場合には、 provider = twitter であるデータを探して判定する pipeline fnctionを作成 is_new などのpipeline functionに渡される引数については こちらを参照ください。 https://zenn.dev/rocky_manobi/scraps/dd78bdd777c42f
67. 詳しくはコチラに https://zenn.dev/rocky_manobi/articles/438cd4f01166af 原因と解決策 ‘social_core.pipeline.social_auth.social_user’ の後段で実行してくれるよう、 settings.pyに実行順序を定義する ※Twitter OAuth 1.1a をサポートし続ける場合はこの逆「twitter -> twitter-oauth2」の考慮も必要
68. 課題 2 こういうやつ.... SNSサービス と OAuth Provider は別のもの。 名前がたまたま同じだからといって同じように扱うと痛い目を見るという典型。 provider名 => SNS名 の読み替えを行う機構を作って対処。 (サービスの性質上利用箇所が多岐にわたっており...) どのようなライブラリ / サービスを利用していても、このような箇所がないかどうか はチェックしたほうが良さそうです。
69. システム的対処 - QA / リリース
70. Featureフラグを用いて、 TwitterOAuth2対応のコードがデプロイされているが UI上は利用されない状態を作れるように実装しつつ... QA / リリースの工夫 既存の動作を壊していないことを確認するためのQAを集中して実施 Featureフラグ = OFF の状態で2週間 本番稼働を監視 デプロイ リリース(Featureフラグ ON) 追加した Twitter OAuth API v2.0 周りの挙動をQA (staging)
71. 結果！ ⭕ 移行後システムトラブルはなし(今のところ) ⭕ 機能を閉じていた間の事業数字(新規獲得/DAU,MAU)への悪化も認められず (他の要因で説明がつく状態) MAU昨対比 新規獲得
72. おまけ - 鳥とTwitterの痕跡はまだ...
73. 感想戦
74. Twitterログイン機能の早期復旧を目指さない選択肢は正解だったのか？ 感想戦 - 1 2023.08.22 「API v1.1も続々廃止していく よ」 選ばなかった世界線の評価は難しいところではあるけれど、正解と考えている。 結果としてトラブル無く対応を完了できたことや、 対応完了後にアナウンスされた API v1.1 を廃止するというアナウンスに反応しなくて済み、 普段の開発を継続できている。 このさきOAuth API v1.1a が廃止される日が来たとしても対応済みとして構えることができる。 やってわすれる。大事。
75. 廃止アナウンスに対する構えは隙だらけだった 最悪を想定して調査/見積もりを行うことはできていた。 本当に最悪が起こるとしてやるべきことを考えていない楽観思考があった。 Twitter関連機能をフラグ操作1つでクローズできるような仕組みを構築する程度 の対応は行われてしかるべきだった。 (要因は色々考えられますが飲み会とかでお話しましょう) 感想戦 - 2 Twitterのアナウンスが信用できない / 何が起こるかわからない と言っておきながら、 「ここは影響がなさそう」という楽観材料については信じてしまう心の弱さが強く出ていた？ 機能としての重要度がそこまで高くないという背景と、結果論的には問題がないとは言えることと、 当時のことは記憶をたどることしかできないので、このあたりは次にこのような状況があったときに自 問できるようにしておこうとおもう。
76. 感想戦 - 3 そもそもTwitter API についての理解が圧倒的に足りていなかった 今回の対応には少なくとも以下の単語について、 意味合い、役割、関係を理解した上で望む必要があったはず。 Essencial, Standard, Premium, Elevated, basic, pro, free, enterprise, API v1, API v1.1, API v2 OAuth API v1.0a , OAuth API v2.0 これらを理解した上で改めてアナウンスを追いかけると、 我々は途中で直面したトラブルの原因を多く見誤っていたことが分かった。 そしておそらく我々と同じく多くの人が同じような誤解をしていたと考えられる。 例えば … 少なくともX(Twitter)は 2023.08.22 まで、 API v1.1 を廃止するというアナウンスはしていない(名指しした特定のAPIを除いて)。 にもかかわらず ….. つづきは口頭で！
77. 感想戦 - 3 そもそもTwitter API についての理解が圧倒的に足りていなかった 今回の対応には少なくとも以下の単語について、 意味合い、役割、関係を理解した上で望む必要があったはず。 Essencial, Standard, Premium, Elevated, basic, pro, free, enterprise, API v1, API v1.1, API v2 OAuth API v1.0a , OAuth API v2.0 これらを理解した上で改めてアナウンスを追いかけると、 我々は途中で直面したトラブルの原因を多く見誤っていたことが分かった。 そしておそらく我々と同じく多くの人が同じような誤解をしていたと考えられる。 例えば … 少なくともX(Twitter)は 2023.08.22 まで、 API v1.1 を廃止するというアナウンスはしていない(名指しした特定のAPIを除いて)。 にもかかわらず ….. つづきは口頭で！ 雰囲気で触るというのはとても危ない 強い気持ちで使っているものを理解している状態を目指そう
78. おわりに 一連の流れを 改めて調べてみての感想
79. 複雑な料金体系や新旧複数のドキュメントの不整合による混乱は 確かに問題の種ではあるけれども... それは試行錯誤を重ねてきた証であり、 WebAPIを用いたものづくりが当たり前になる前の時代から続くその試行錯誤は 現存するAPIの運用や料金設計のベストプラクティスやノウハウに多少なりとも 還元されているのは間違いないし、結果としてWeb APIを用いたマッシュアップ のカノ生を切り開くことにも大きく貢献していたのだとおもう。 今回の急激な変化について思うことがないわけではないけれども、 そこには敬意を払いつつ、もしエコシステム維持の負担が集中してしまってい たのであれば、継続できるようにするための変化は受け入れる姿勢は持ちたい なと思いました。
80. Python Social Auth の Twitter OAuth API マイグレーションプロジェクトとその教訓 2023.10.27@PyCon APAC 2023