t_wの輪郭

は？やべぇ。攻撃来てるかも。攻撃戦だ。

nginxのログみたら、SQLっぽいクエリで検索めっちゃされてる。
nginxでIPをはじくようにした。
IPをBANしたら、一旦攻撃は止んだ。

攻撃の対策どうしよう、fail2banのnginx-403-404は設定してるけど、サイト内検索を連打されるとこれ効かないんだよな。
WAF入れるのが手っ取り早いんだろうけど、勉強にならないし、お金かかるしで、もうちょっとほかの手段を検討したい。

①fail2banでSQLインジェクションを検知してBANする
②nginxで高頻度の検索を検知してBANする
あたりかしら

設定するのめんどくせー
ちゃんと設定できてるか検証するのもめんどくせー

①検証用の被攻撃サーバーと攻撃用サーバーを立ててそこで対策が有効かを検証
②本番環境に反映したら攻撃用サーバーから攻撃してみて、ちゃんと対策されているか検証

って感じで進めるとお行儀が良さそう。
めんどくせー
本番環境でペペぺって設定して、自宅のPCから実際攻撃して検証したい。そして自宅のPCから本番環境にアクセスできなくなるワナ。

こういうのって制定された手順とかあるんかな。ありそう。先に調べよう。

そもそもサイト内検索が大変重たいという問題も解決したい。
自作の検索機能がDBにインデックス張ってないわ、title LIKE %hogehoge% OR body_text LIKE %hogehoge%とかやって全文検索走るわでイケてない。
DBにちゃんとインデックス張ればいいんだろうけど、PostgreSQLの日本語のインデックスって、PGroonga入れたり、pg_bigm入れたりで、これまた検証サーバー立てないと怖いのよね。
めんどくせー。

今日も21時まで残業で疲れた。
本番運用前の本番環境でバグが出て、開発環境で再現できずに苦労した。

　Android Chromeで開発機のlocalhost(HTTP)上で動かしているウェブサイトに接続するとService Workerが動かない。もしやHTTPSじゃないとService Workerが動かない？

サービスワーカーは、セキュリティ上の理由から HTTPS での実行に制限されています。

ローカルでの開発を容易にするために、 localhost はブラウザーによって安全なオリジンとみなされます。

　あー完全に理解した。ホストしているPCでlocalhostに接続すると動くなーと思ってたらそういう条件なんだ。スマホからパソコンのlocalhostに接続したら特権を失うということなのね。

　Service Workerを使うプッシュ通知のテストを本番環境でやるの、さすがに利用者の迷惑になるだろうから、やめねばと思っている。
　プッシュ通知を登録する人なんて開発者以外に誰もいないでしょと思ってたら、1人いるっぽいんですよね。大切にしたい。

　利用者が1人しかいない中で、本番環境を使ってテストしたくないとかいうのは開発者のエゴだろうか。
　いや、やっぱりちゃんとローカルでテストできるようにしよう。localhostをhttpsで接続できるようにしよう。

2022年8月1日

プッシュ通知登録ボタンをフォローポップアップに移動させて集約した。

GoneのときにDBから削除するように作り変える。今はエラーのときに削除なので意図せず消えている可能性がある。

2022年7月31日

　プッシュ通知を実装した。記事の閲覧回数が一定以上になったらプッシュ通知される。はずである。試験がしづらすぎてちゃんと動くか検証できるまで大変だった。

　PV数でプッシュ通知する目的としては、以下を満たすためである

• 読者は更新されるたびプッシュ通知されたくない
• 読者はよく見られている記事だけを読みたい
• 筆者の私が良く見られている記事に気付きたい

2022年8月7日

朝からElevated accessの申請をした。

うおおおおTwitter APIでTwitterに自動投稿できるようになった！！！
やっと更新通知（と呼んでたけど記事が一定数閲覧されたらTwitter APIでTwitterに投稿）する機能を実装できるぞ！！！

記事が一定数閲覧されたらTwitter APIでTwitterに投稿する機能を実装した。

リリースした。

トークンとかの格納に.envを使っているのだけれど、これがrsyncすれば開発環境から本番環境に反映されると思っていて、本番環境でエラーを起こしていた。

2022年8月6日

Twitterへの自動投稿はめんどくさかった
ブログ更新したらTwitter APIで自動投稿したいとか考えてたけど、思ってた100倍ぐらいめんどいことが分かった

めんどくさい理由：

• 投稿に使うtokenが有効なのは2時間だけ
• refresh_tokenを使えばtokenの再取得ができるが、その際にrefresh_tokenも新しいものが払い出され、古いrefresh_tokenは利用できなくなる
• 故に、DBにrefresh_tokenを入れておく必要があり、さらに常に有効であるかに気を配る必要がある
• refresh_tokenが無効化した場合には、DBを触ってrefresh_tokenの入れ直しが必要

OAuth2.0だとめんどくさいらしく、OAuth1.0aを使った方が良いとSNSで情報をいただいた。ただ、OAuth1.0aの投稿APIはElevated accessが必要とのこと。

twitterAPIはoauth1.0aで使うのがオヌヌメ

oauth2.0はリフレッシュトークンの管理がめんどい

OAuth1.0が一生うまくいかん。
ブログ更新ツイートぐらいだったら手動でやればいいやという気持ちになってきたけど、それはそれとしてOAuth1.0に負けるわけにはいかない。

あきらめてライブラリ使ってもいいですか。

力尽きた。

丸一日OAuthに捧げたけど成果物は何もないし、いまだにAOuthって書きそうになる