アイデアの甕

アイデアを放り込んでおくと甕は腐臭を発しない

当サイトではアフィリエイトプログラムを利用して商品を紹介しています。

Dockerコンテナからwebbrowser.errorを回避してflow.run_local_serverを実行する方法(Google OAuth)

エラー

bukki.hatenablog.com

上記で実行できていたflow.run_local_serverがうごかない。2023/09/27に動かなくなったことを確認。

具体的には「webbrowser.error could not locate runnable browser」とエラーが出て、ブラウザを実行できないようす。

YouTube Data APIを使うのにブラウザからのOAuth認証が必須なので、これは解消しときたい。

解決に向けた分析

エラー文言からするとどうもブラウザが実行できないというか、見つからないらしい。

実行すべきブラウザのパスがわからないらしいので明示的に指定してやればいいという情報がネット上で見つかるものの問題が。

いま、Docker上でプログラム(Pythonスクリプト)を実行しているのだ。

Dockerコンテナにはブラウザをインストールしていないから、指定すべきブラウザは存在しない。

じゃあこれまで実行できていたのがなぜなのか疑問が残る。これまではホスト側のChromeが既定ブラウザとして起動できていたのに急にできなくなったのはなぜなのか?

  • Dockerの更新・仕様変更
  • Pythonライブラリ(google-auth-library-python-oauthlib)の更新
  • Chromeの更新

まえに実行できていたタイミング以降、それぞれ更新したかどうかもわからないが原因追及の道のりはありそう。だけど…更新履歴を探るような面倒なことは避けたい。

解決方法

幸い、OAuth認証の機会はそう頻繁じゃない。だから、

  • 自動的にブラウザを起動させるのをやめる
  • アクセスすべきURL文字列をDockerとHostでやり取りする
  • Host側のChromeを手動で立ち上げ、OAuth認証をする

という方針でエラーを回避しよう。

方法は簡単だ。

flow.run_local_serverのキーワード引数にopen_browser=Falseを渡す

以上。

これで下記ソースコード上のエラー送出箇所を回避できる。

github.com

現況

これまで自動的に立ち上がっていたブラウザが立ち上がらなくなった。

上記対策によりVSCodeのプロンプト上に認証用のURLが表示されるようになった。

これをダブルクリックすると既定ブラウザであるChromeが立ち上がり、認証フローを進められた。

前回記事で示した通り、ホスト側からDockerへリダイレクトを通すこともできている。

Dockerコンテナへflow.run_local_serverをリダイレクトする方法(Google OAuth)

突然のエラー

2023年9月。久々にDockerコンテナ上のアプリからYouTube Data APIを触ってみると、2022年(?)までつかえていたPythonコードがエラー。

AttributeError: 'InstalledAppFlow' object has no attribute 'run_console'

run_consoleはコード実行の認可にかかわるメソッド。dir関数でしらべてみると、たしかにInstalledAppFlowオブジェクトにはrun_console属性がなく、実行できなくなった模様。

コード実行前に下記ライブラリの更新をしていたので、これが原因と判断。

  • google-auth
  • google-auth-httplib2
  • google-auth-oauthlib

原因追及

これまで使えていたメソッドがエラーを出すだけじゃなく、それ自体がなくなってしまうというのはけっこうな異常事態な気がしたので調査。

同じような問題にぶちあたった人は海外含めているようで、いくつかの質問サイトで議論されていた。

結論としては、下記のセキュリティ強化によるものだろうと。時期的にも合致。

developers.google.com

公式にrun_consoleは使えなくなったから存在自体なくしてしまったと。いうわけで、ライブラリのバージョンをダウングレードするとか、ソースコードをちょこっといじるといったハックは使えないと判断。

リダイレクト

run_consoleの代わりは一択で、run_local_serverを選ばざるを得ない。が、run_consoleを使っていた理由はrun_local_serverによる認可プロセスがうまくいかなかったからだ。

run_local_serverはブラウザ上での操作後、リダイレクトしてアプリにフローを引き継ぐ。しかし、Docker上のアプリではリダイレクト先の指定方法がよくわからないのだ。

この点はやはり日本でも海外でも話題になっている。どうすればうまくいくのか?と。

現時点での答えは下記にあった。

github.com

かなり息の長いIssueで、2020年に開始されて、2023年まで断続的に議論が進行している。

要点は2点。

  • コンテナ起動時に-p 8080:8080のオプションをつけろ
  • flow.run_local_server(bind_addr="0.0.0.0")と引数を設定しろ

以上。

すこし詳しく

-p 8080:8080

下記サイトによれば、run_local_serverは引数にportがあって、8080がデフォルトだ。

google-auth-oauthlib.readthedocs.io

なので、ポートフォワードでdockerコンテナの内と外をつないでやればいい。

もし8080ポート以外を設定したければ、引数としてport=xxxxと明示すればいい(はず)。

bind_addr="0.0.0.0"

run_local_serverの引数にbind_addr(またはhost?)を設定するとリダイレクト先が指定できる。

デフォルトが"localhost"だから、dockerを使わない場合はこれでうまくいくらしい。

dockerを使いたければ"0.0.0.0"を指定する。

イメージ

run_local_serverを実行すると、docker内にサーバーが立ち上がる。このサーバーは認可プロセスの完了を待ち受ける。

認可プロセス自体はdockerの外(ブラウザ上)で進めるから、完了後はリダイレクトでこのdocker内サーバーに伝えなければならない。

伝えるためにどこで待ち受け中かを指定したいのだが、dockerの外から内へはlocalhost("127.0.0.1")では伝わらない。

"0.0.0.0:8080"みたいに指定してやる必要がある。

ルイボスティーと乳化剤のまずい味わい

追記(2023/09)

一番のお気に入りが更新。

やさしいルイボスティーがおいしい。後発品かな?乳化剤もなくてのみやすい。リピートしてます。

ルイボスティーのみたい

ルイボスティーって変なお茶があるなと思ったところから常飲するようになったきっかけは何だったか。 たぶん、セブンイレブンで買ったペットボトルのルイボスティーがおいしかったから。いや、まぁ飲めるなと思ったから。

7premium.jp

コーヒー・紅茶の代わりになるノンカフェイン飲料を求めていたのだ。

体質的にカフェインが利きすぎてしまう(気がする)から、常飲できるノンカフェイン飲料がほしかった。水では味がなさすぎる。できれば温めても飲みやすく、おいしければなおよし。

まぁ枯れ葉を煮出したような味がおいしいかどうかはともかく、飲める。ルイボス、飲める。

Amazonで調達

常飲するようになればいちいちコンビニでペットボトルを買うのは面倒だ。ネット通販で箱買いしちゃうほうがいい。というわけで。

あじ濃いなー。これ味濃いなーとおもいつつ、24本を消費する頃には慣れてしまった。

次に買ったのがこちら。

やすい。うまくない。なんかヘン。飲み続けることができひん。

これはいける。味うすめ。

原材料の乳化剤

それぞれの飲料の原材料を確かめてみると、気になるのは「乳化剤」。上にあげたものだと、なんかヘンな味わいがある、まずさを感じるHappy Bellyブランドの商品にだけ乳化剤が含まれる。

ペットボトル飲料は大量生産の工業製品で、乳化剤には消泡作用があったりして製造・流通に役立つことがあるらしい。だから添加するらしい。

だけど、味わい変わるらしい。たぶん。

Happy Bellyを買ったあと、いくつかのルイボスティーブランドで乳化剤が入っていることを確認し、それを避けた。避けた結果の良品物語ブランド。のみやすい。

いちおう、Happy Bellのレビューを見れば、「おいしい。のみやすい。」が並んでいることは述べておこう。

味覚は、すごく個人的なものだ。遺伝だって関係しているらしい。特定の遺伝子を持っている人だけに感じる味わいがあるらしい。たぶん、乳化剤に敏感な遺伝子もあるんやろとおもう。おいしく飲める人だってたくさんいるはず。

出会いがだいじ

ルイボスティーってあるな、試してみるかな、と思って手に取ったのがセブンイレブンのもので、たしか伊藤園が製造していて、なぜかAmazonでは流通している不思議。

不思議はさておき、これには乳化剤が入っていなかった。だから飲めた。おいしいとは言えずとも、お茶として、喫茶できた。

もしこれが乳化剤入りのもので、変な味わいをルイボスティーそのものと認識していたら、今ではルイボスティーを飲んじゃいなかったはずで。

いやほんま大事やん。出会いが、第一印象が大事やんと感じつつ、今後二度と乳化剤入りのお茶を買わないでおこうと思う。

ChromeOS/Windowsキーボードでスリープは「Win+Shift+L」

古いWindowsノートパソコンにChrome OSを導入。導入方法などは他サイトを参照のこと。

「検索」がない

Chrome OSのキーボードショートカットはChromebookの独特な「検索キー|🔍キー」を使用したものがあり、PCをスリープ状態にするショートカットもまたその一例となっている。

無操作状態で既定の時間がたてばスリープ状態へ勝手に移行するし、ノートパソコンであれば画面を閉じる動作でもスリープにできる。…がしかし、任意のタイミングで簡単にスリープにできるオプションも欲しいし実際によく使うので、やはりこれを元Windows機でも利用したい。

というわけで調べてみると、「検索キー」は「Windowsキー」に割り当てられているそうな。

Windows向けの通常の日本語タイプのキーボードなら左下に四角形と十字の窓で表現されたWindowsキーが設置されている。これがChrome OSにおける「検索」キーとしてはたらくというわけだ。

瞬息スリープ

スリープは「検索」と「Shift」と「L(エル)」の3キータイプのショートカット。ちなみにシフトキーを使わなければ、「検索」と「L」でロック(パスワード入力必須のログイン画面へ移行)となり、これはWindows機と似た挙動となっている。

よって、Windowsキーボードなら「Windows」キーと「Shift」と「L」でスリープにでき、快適な体験を得られた。

Chromebook隆盛の時代にあえて旧型のWindowsChrome OSを導入する例は少ない気もするが、記録として残しておく。

【解決】PowerShell上のdocker runで-vオプションが利かなくなった【for Windows 2.3.0.2】

Docker-1

Docker for Windowsを更新。2020-05-11に公開されたDocker Desktop Community 2.3.0.2。

docs.docker.com

どうやらWindows 10 Proだけでなく、Windows 10 Homeでも導入可能になったとかでそれなりに大きなアップデートみたいです。

マウントされないボリューム

アップデート(新規インストール&旧版アンインストール?)は無事終了し、いつも通り「docker run」してみる。

動く。

ただ、いつものコマンドが通らない。

調べてみると、「-v」オプションで指定したvolumeがマウントされずホスト・コンテナ間でのファイルのやり取りができていない。

解決策

普段「docker run」コマンドは直打ちしておらず、PowerShell用のps1ファイルを読み込む形で実行していたのですが、その一部にこのような記載がありました。

-v ~/path/to/file:/file/to/path

ユーザーのホームディレクトリを示す「~」による記述。

どうやらこの記述が(PowerShellを介した「docker run」では)機能しないようになったらしく、フルパスで書けば確かにマウントされることを確認。さらに環境変数?を使用して以下のように書き換え。

-v $HOME/path/to/file:/file/to/path

この書き換えにより、アップロード前の挙動が再現されました(ただし体感では立ち上がりが数秒遅くなっているような…?)。

「問いの数が増えても答えの数を増やせない問題」が増加する問題

下記記事の感想。

 

bunshun.jp

 

「どんな仕事に就くの?」「何歳くらいで結婚するの?」「いつまで働くの?」「妻の職業は?」「何歳くらいで子供が欲しい?」「育休は取るの?」「子育てはどれくらいできると思う?」「家事はどれくらいやるつもり?」「子供は何人くらい欲しい?」「そもそも働くの?」などの問いを続けざまに投げかけました。

 要するに「キミはどうやって生きていきたいんだ?」「キミにとって本当に大事なものは何なんだ?」という問いです。

「『男なんだから俺が稼がなきゃ』という義務感で仕事をしていたら、仕事がうまくいかなくなったときにきっときつくなるよ。いろんな選択肢があるなかで、好き好んで自分はいまこれを選んでいるんだと言えるように、自分の選択に責任をもつことが大事」。そんな話もしました。

 

たしか橘玲さんが著書で紹介していたように、人間にとって「意志」は有限の資源。何かを決定するには「意志」の消費が必要で、回答を見出すべき問いの数が増えれば増えるほど「意志」が足りなくなる可能性は高い。

 

とすると、問いを続けざまに投げかけると起こることはどちらかと言えばネガティブで、おおよそ「何もしない」や「何もできない」を選ぶことになるんじゃないかと。

 

「どんな仕事に就くの?」「何歳くらいで結婚するの?」「いつまで働くの?」「妻の職業は?」「何歳くらいで子供が欲しい?」「育休は取るの?」「子育てはどれくらいできると思う?」「家事はどれくらいやるつもり?」「子供は何人くらい欲しい?」「そもそも働くの?」などの問いを続けざまに投げかけました。 

 

これらの問いかけに「普通は○○だよね」という通念的な回答が用意されていなければ、自らの「意志」によって回答を選択する必要があるのであれば、「意志」の資源があらかじめ十全に用意できない人には選べなくなる。

 

21世紀の「男の子」の親たちへ 男子校の先生たちからのアドバイス (単行本)

21世紀の「男の子」の親たちへ 男子校の先生たちからのアドバイス (単行本)

 

 

「らしさ」が与えていたのは、あるいは文化が「らしさ」を求めるのは、特別な機会に「意志」を温存することだったのかも。

【2018】国税庁様式検索システムで法人税申告書の別表等を入手

忘備録ということで、法人税申告書の最新版の別表等がダウンロードできるリンク先を示しておきたい。*1

国税庁 様式名称検索

上記リンク先から、検索条件を入力してご所望の様式を入手してください。

年度によって書式が異なる場合がありますので、くれぐれもご注意を。

別表ダウンロードへの道

f:id:bukki:20180411145704p:plain 国税庁

リニューアル後のウェブサイトでは、

トップページの「分野別メニュー」にある「申告手続き」のうち、「申告・申請・届出等、用紙(手続の案内・様式)」を選択し、リンクにある「国税庁様式検索システム」から「国税庁様式検索」へたどり着くことができます。

国税庁 様式名称検索

使いづらい検索システム

f:id:bukki:20180411151318p:plain

2018-04-11時点では、「●届出書・申請書等の名称の部分的な語句による検索」が使えない気がします。

Chromeでも、Internet Explorerでも絞り込めない。

「●様式の種類等による検索」はかろうじて使えるみたいなので、こちらをお試しください。

f:id:bukki:20180411151617p:plain

しかし、絞り込めないのは致命的やないか…?

*1:2016年の記事に記載したURLが国税庁ウェブサイトのリニューアル(2018-03-31)でことごとくリンク切れになりましたので、改めて記事化しました。