新規記事の投稿を行うことで、非表示にすることが可能です。
ファンブログあるある:スパムで溢れた未承認のコメント一覧・トラックバック一覧の対処法
このブログ、a8ネットが運営するファンブログを利用しています。
ファンブログで投稿しているとスパムコメントやトラックバックが増えてきます。ブログの設定でOFFにすることができます。ONの場合、承認後表示するモードが有効にできます。このブログはコメント、トラックバック共にONで承認後表示するにを入れています。
スパムは後からやってきます。アクセスがある記事を狙ってきます。スパムはコピー商品へリンクを送るようなものが多いです。
→承認後表示するがおすすめの設定ですよ。
→SNS主流な状況です。トラックバックもOFFでいいと思っています。
ブログが育ってくると、スパム(自動的にどこかの怪しげなショッピングサイト系が多いです)コメントがたくさん入ってくるように。
初めはIP禁止、禁止URL、禁止WORDとかでガードすることを試みていますが、スパムはIPを変え、URLを変えやってくるので追いついていけなりました。
現在は、気がついたときにある程度削除。という手動でやっていますが、ここにも罠があります。
ファンブログのコメント一覧(承認待ちコメント一覧)はという選択をコメント毎に設定し、削除する操作(実行)になります。
デフォルトが承認なんです。一覧には20件ぐらい表示されるんですが、一つ一つをに切り替える操作が必要なんです。スパム相手にはとても不親切な設計だと思っていますよ。デフォルトの指定もできないし・・・
こんな時、一覧表示された20件を承認から削除に一括で変更するスクリプトを使って、楽しています。
↓1行にまとめています。コピペで簡単に実行できます
20回の承認→削除の切り替え操作が減ります。内容を確認し、問題がなければ実行する流れでいけるので負担は減っていますよ。
一覧20件ではなく、100件、1000件選べるようにしてほしいですね
- 登録(無料)で維持費もかからず、ずっと無料で使えてます
- しばらく放置(ブログ投稿がない)すると勝手に広告が表示される
- httpsに対応している(2022年7月に対応しています)
ずっとhttpのままだったので、別のブログに移動しちゃおうかと思っていました。対応してくれてよかったです。
- 投稿システム自体は古めの感じです。慣れると気になりません。
↓興味のある方はこちら↓
ファンブログで投稿しているとスパムコメントやトラックバックが増えてきます。ブログの設定でOFFにすることができます。ONの場合、承認後表示するモードが有効にできます。このブログはコメント、トラックバック共にONで承認後表示するにを入れています。
スパムは後からやってきます。アクセスがある記事を狙ってきます。スパムはコピー商品へリンクを送るようなものが多いです。
→承認後表示するがおすすめの設定ですよ。
→SNS主流な状況です。トラックバックもOFFでいいと思っています。
ブログが育ってくると、スパム(自動的にどこかの怪しげなショッピングサイト系が多いです)コメントがたくさん入ってくるように。
初めはIP禁止、禁止URL、禁止WORDとかでガードすることを試みていますが、スパムはIPを変え、URLを変えやってくるので追いついていけなりました。
現在は、気がついたときにある程度削除。という手動でやっていますが、ここにも罠があります。
ファンブログのコメント一覧(承認待ちコメント一覧)はという選択をコメント毎に設定し、削除する操作(実行)になります。
デフォルトが承認なんです。一覧には20件ぐらい表示されるんですが、一つ一つをに切り替える操作が必要なんです。スパム相手にはとても不親切な設計だと思っていますよ。デフォルトの指定もできないし・・・
こんな時、一覧表示された20件を承認から削除に一括で変更するスクリプトを使って、楽しています。
var elms = document.querySelectorAll('#cms-MainCommentList select');
for( var i=0; i < elms.length; i++ ){ elms[i].value = "do_delete"; }
- ブラウザの右クリック操作のメニューで検証(Chrome)や要素の詳細を表示(Safari)を選択することでDevToolやWebインスペクターが表示できます。
- 1)ここのコンソール(Chrome)、下の入力可能エリア(Safari)にコピペすることで動作します。
【注意点】承認したい内容でも、一括で削除を選択します。
コメント一覧、トラックバック一覧で動作します。
- 2)上から順に20件確認して、削除しても問題ないかを確認します。
- 3)下に表示されている「実行」ボタンを押します。
- 以降は1)〜3)の繰り返しです。
無心にやっているとミスがあるかもしれません。スクリプトを実行を忘れて(承認状態)で実行してしまった。2)の手順で先頭が削除になっていることをついでに確認しておくと防ぐことができます。
↓1行にまとめています。コピペで簡単に実行できます
まとめ:少し負担が減ります。
20回の承認→削除の切り替え操作が減ります。内容を確認し、問題がなければ実行する流れでいけるので負担は減っていますよ。
一覧20件ではなく、100件、1000件選べるようにしてほしいですね
タグ:ファンブログ
【macOS】swiftプログラムからmacOSの通知センターへ表示する簡単な方法
Xcodeを利用したmacOS用アプリで通知を利用したい場合があります。
目につきやすいメリットがあります(見逃すことは当然ありますね)。
UserNotifications(詳しくは→ https://developer.apple.com/documentation/usernotifications)を使う方法が正当です。タイトルやアイコンを自由に設定できるメリットがありますが、デメリットも感じています。
AppStoreに登録して公開するようなアプリではなく、自分用プログラムですので、もっと簡単な方法がない?あります
osascript(Apple Script)を使うことで通知できます。
この方法にはデメリットがあります。通知表示のアイコンやタイトルはスクリプトエディタです。
これを回避したい場合は、Swift標準方法のUserNotificationsを使うしかありません。
以下のようなメソッドを用意して呼び出すだけです。
簡単に通知できました
Macの通知センターでは、見逃した通知を確認したり、ウィジェットを使って予約、誕生日、天気、最新ニュースのヘッドラインなどをデスクトップから直接確認したりできます。
https://support.apple.com/ja-jp/guide/mac-help/mchl2fb1258f/mac
目につきやすいメリットがあります(見逃すことは当然ありますね)。
UserNotifications(詳しくは→ https://developer.apple.com/documentation/usernotifications)を使う方法が正当です。タイトルやアイコンを自由に設定できるメリットがありますが、デメリットも感じています。
- Xcodeのアップデートで利用方法が変わることがある。
- セキュリティが強化され、追加の許可設定が必要なことがある
AppStoreに登録して公開するようなアプリではなく、自分用プログラムですので、もっと簡単な方法がない?あります
osascript(Apple Script)を使うことで通知できます。
この方法にはデメリットがあります。通知表示のアイコンやタイトルはスクリプトエディタです。
これを回避したい場合は、Swift標準方法のUserNotificationsを使うしかありません。
【macOS】swiftプログラムからmacOSの通知センターへ表示する簡単な方法のソース例
以下のようなメソッドを用意して呼び出すだけです。
func macOSへ通知(_ message: String){
let task = Process();
task.executableURL = URL(fileURLWithPath: "/usr/bin/osascript")
task.arguments = ["-e", "display notification \""+message+"\""]
do{try task.run()}
catch{print("exception")}
}
- osascriptはmacOS標準のコマンドです。man osascriptでマニュアルを読むことができます。
- macOSへ通知("メッセージ")と呼び出すことで通知センターにメッセージが表示されます。
- macOSへ通知("メッセージ\nメッセージ")でメッセージを改行できます。
webmaster=googleapiclient.discovery.build('webmasters','v3',credentials=credentials)でエラーになったら
Google Search Consoleでわかる順位やキーワード(QUERY)は、APIで取得することができます(詳しくは→https://developers.google.com/api-client-library)。APIで日々サイトのデータを収集(python3)、まとめ(php)ています。スケジューラーやクーロンで実行し、気になった時だけ参照する程度だとサーバー側の変更に気が付かず対応が遅れてしまうことがありますよね。これは本当にそのパターンです。
UnkonwAPINameOrVersionエラーが発生するようになっていました。
2020 年 12 月 9 日(水)に発表されたGoogleの資料(https://developers.google.com/search/blog/2020/12/search-console-api-updates#discovery-doc-migration)を見ると解決できました。
管理しているpythonソースコード上では以下のような修正でgoogleapiclient.errorsは無くなりましたよ。
Traceback (most recent call last):
File xxx in <module>
webmaster=googleapiclient.discovery.build('webmasters','v3',credentials=credentials)
File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/googleapiclient/_helpers.py", line 130, in positional_wrapper
return wrapped(*args, **kwargs)
File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/googleapiclient/discovery.py", line 235, in build
"name: %s version: %s" % (serviceName, version))
googleapiclient.errors.UnknownApiNameOrVersion: name: webmasters version: v3
UnkonwAPINameOrVersionエラーが発生するようになっていました。
2020 年 12 月 9 日(水)に発表されたGoogleの資料(https://developers.google.com/search/blog/2020/12/search-console-api-updates#discovery-doc-migration)を見ると解決できました。
管理しているpythonソースコード上では以下のような修正でgoogleapiclient.errorsは無くなりましたよ。
#webmaster=googleapiclient.discovery.build('webmasters','v3',credentials=credentials)
webmaster=googleapiclient.discovery.build('searchconsole','v1',credentials=credentials)
wp-jsonは閉じました。
wp-jsonってご存知でしょうか?最近のワードプレスに標準装備されているAPIです。
個人的にとても面倒だと思っているのは、認証不要でもアクセスできるエンドポイント(URL)が存在することです。把握しきれません。
また、wp-jsonへのアクセスはデータベースに対するクエリーが発生し、このクエリーがキャッシュされていない場合とても重いところがとても嫌です。
bingbotは新しいことが大好きなのようで、wp-json経由で情報を取得することを試みます。bingbot以外にもduckduckgoや怪しげな攻撃者が利用していることを確認しています。エンドポイントの実例は以下のような感じです。
Googleがこのwp-jsonにアクセスした実績は今の所ありませんでした。
そもそも、sitemap.xmlにも記載していないURLへのアクセスなので攻撃に等しいんじゃないかと思いますよ。> bingbot
同様のことは、ワードプレスのactionやfilterなどでも可能だと思います。PHPで判断するコストが発生するので、初めの段階でアクセスしないように.htaccessで除外しています(↓の例ではwp-jsonで始まるURLはトップページにリダイレクト)。
.htaccessでwp-json系へのアクセスは全部トップページに遷移するようにしました。これでwp-jsonは無効になっています。
wp-jsonを利用できなくするデメリットは?今の所ありません。
ご自身で導入しているプラグイン、テーマ等でwp-jsonを利用しているパターンもあるかもしれません。こういった場合、wp-jsonは有効にしておく方がいいですね。
- HTTP ベースの REST API
- サイトのユーザー、投稿、タクソノミー、その他のデータに対してシンプルな HTTP リクエストを送信することで、取り出したりアップデートすることが可能
- デフォルトで有効
wp-jsonの厄介なポイントは
個人的にとても面倒だと思っているのは、認証不要でもアクセスできるエンドポイント(URL)が存在することです。把握しきれません。
また、wp-jsonへのアクセスはデータベースに対するクエリーが発生し、このクエリーがキャッシュされていない場合とても重いところがとても嫌です。
wp-jsonへアクセスしてくるのはbingbot(microsoft)
bingbotは新しいことが大好きなのようで、wp-json経由で情報を取得することを試みます。bingbot以外にもduckduckgoや怪しげな攻撃者が利用していることを確認しています。エンドポイントの実例は以下のような感じです。
- /wp-json/wp/v2/tags/521
- /wp-json/wp/v2/users/
- /wp-json/wp/v2/posts/3882
- /wp-json/wp/v2/pages/2213
Googleがこのwp-jsonにアクセスした実績は今の所ありませんでした。
そもそも、sitemap.xmlにも記載していないURLへのアクセスなので攻撃に等しいんじゃないかと思いますよ。> bingbot
wp-jsonへのアクセスをガッツリ遮断する
同様のことは、ワードプレスのactionやfilterなどでも可能だと思います。PHPで判断するコストが発生するので、初めの段階でアクセスしないように.htaccessで除外しています(↓の例ではwp-jsonで始まるURLはトップページにリダイレクト)。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-json(.*)$ https://サイト/ [R=301,L]
</IfModule>
まとめ:wp-jsonは閉じました。
.htaccessでwp-json系へのアクセスは全部トップページに遷移するようにしました。これでwp-jsonは無効になっています。
wp-jsonを利用できなくするデメリットは?今の所ありません。
ご自身で導入しているプラグイン、テーマ等でwp-jsonを利用しているパターンもあるかもしれません。こういった場合、wp-jsonは有効にしておく方がいいですね。
SQLite3 1000件未満のテーブルでselectに1.78秒かかる、効果的に遅いSELECTを0.088秒へ高速化
sqlite3データベースのファイルサイズは114,570,240バイト、テーブル数は1件だけです。ファイルサイズはそこそこあるんですが、1テーブルのみのデータベースで960件ぐらいの登録数です。この程度ならケア不要かと思っていたんですが、間違いでした。
SQLite3は「EXPLAIN QUERY PLANコマンド」でSQLの問題点(というかどんな感じに処理しているのか)を見つけることができます。(詳しくはこちら=>https://www.sqlite.org/eqp.html)
調査中データベースに変更を加える事になるので、対象のデータベースファイルをコピーしたものを利用しています。
phpで「$開始=array_sum( explode(' ', microtime() ));処理;echo array_sum( explode(' ', microtime() )) - $開始;」とmicrotime関数を利用すると精度の高い実行時間を計測することが可能です。
↓で1.78秒かかっていました。EXPLAIN QUERY PLAINで見つけたindexで0.088秒に改善することができました。
今回の知見:データベースファイルサイズが大きいと、USE TEMPを利用するパターンは速度的な影響をモロに受けることがわかりました。
EXPLAIN QUERY PLANはクエリがデータベースインデックスを効果的に利用しているのか?、インデックスを設定することで速くできるのか?という視点で調査する場合に使えるコマンドです。
SQLite3 1000件未満のテーブルでselectに1.78秒かかる
- sqlite3のバージョンは3.7.17。
- スキーマはこんな感じです
CREATE TABLE tbl( pk INTEGER NOT NULL PRIMARY KEY,
sts, model,year, post_id, time, lapse,
mokuji, html, error_reason, fatal_reason ); - 問題になったのは「select * from tbl order by time, year desc」の発行です。
約1.78秒かかりました。サーバーの負荷が高い場合は30秒近くかかることがありました。 - どうすべきか?処理の見直し、EXPLAIN QUERY PLANを使って調査、原因追求して対処するしかないですね。
処理自体見直しましたが、これといっておかしな部分はありませんでした。
1000件未満のテーブルでselectに1.78秒かかる原因はUSE TEMP
SQLite3は「EXPLAIN QUERY PLANコマンド」でSQLの問題点(というかどんな感じに処理しているのか)を見つけることができます。(詳しくはこちら=>https://www.sqlite.org/eqp.html)
調査中データベースに変更を加える事になるので、対象のデータベースファイルをコピーしたものを利用しています。
- PKが効いているパターンはこんな感じにシンプルな結果になります。
explain query plan select * from tbl;
0|0|0|SCAN TABLE tbl (~1000000 rows) - 遅いSQLはB-TREEのテンポラリを使ったソートを使っていることがわかります。
explain query plan select * from tbl order by time, year desc;
このUSE TEMPを消すことができれば速く改善できます。
0|0|0|SCAN TABLE tbl (~1000000 rows)
0|0|0|USE TEMP B-TREE FOR ORDER BY - インデックスはtime,yearは不正解でした。
sqlite> create index idx_1 on tbl( time, year );
結果は変わりません。
sqlite> explain query plan select * from tbl order by time, year desc;
0|0|0|SCAN TABLE tbl (~1000000 rows)
0|0|0|USE TEMP B-TREE FOR ORDER BY
sqlite> drop index idx_1 ; - order句に指定しているすべてを対象にします。time,year descが正解です。
sqlite> create index idx_1 on tbl( time, year desc);
USE TEMPが消えました。
sqlite> explain query plan select * from tbl order by time, year desc;
0|0|0|SCAN TABLE tbl USING INDEX idx_1 (~1000000 rows)
まとめ:indexを適切に設定することで改善できます。EXPLAIN QUERYは万能ではないです
phpで「$開始=array_sum( explode(' ', microtime() ));処理;echo array_sum( explode(' ', microtime() )) - $開始;」とmicrotime関数を利用すると精度の高い実行時間を計測することが可能です。
↓で1.78秒かかっていました。EXPLAIN QUERY PLAINで見つけたindexで0.088秒に改善することができました。
$results = $db->query("select * from tbl order by time asc,year desc");
今回の知見:データベースファイルサイズが大きいと、USE TEMPを利用するパターンは速度的な影響をモロに受けることがわかりました。
EXPLAIN QUERY PLANはクエリがデータベースインデックスを効果的に利用しているのか?、インデックスを設定することで速くできるのか?という視点で調査する場合に使えるコマンドです。