カテゴリー
Internet

ソフトイーサ社がフレッツ用 PPPoE 実験用アクセスポイントを新型コロナ対策で無料開放

筑波大学発ベンチャー企業である ソフトイーサ株式会社 (本店所在地 茨城県つくば市、以下「ソフトイーサ」といいます) は、新型コロナウイルス感染防止を目的に日々在宅勤務されている方々を対象として、これまで学術実験目的で試験構築してきた NTT 東日本フレッツ用 PPPoE 方式のインターネットアクセスポイント (東京・茨城) を、本日より新型コロナウイルス対策が必要な当面の期間 (以下「コロナ期間」といいます)、無償・無保証で開放いたします。

https://www.softether.jp/7-news/2020.03.06

現時点では、テレワークの導入は未定ですが… 実施されることになったら利用させていただくとしましょう。

カテゴリー
MySQL

MySQLのAUTO_INCREMENTで値が再利用されるケースがある

他社が制作したWebサイト( PHP + MySQL )で、新規登録したユーザーの履歴に他人の情報が紐付いているのが見つかったので、修正したいと依頼があって初めて知ったこと。

提供頂いたデータを確認すると新規登録したユーザーレコードの作成日付より古い履歴情報レコードと紐付いているデータが数件あったため、いろいろ調べてみるとシステムメンテナンスを実施した後に発生していることが判明。

テスト環境を構築して、さらに調べるとAUTO_INCREMENT で割り当てられた最新番号(最後)のレコードが削除された後で、MySQLサーバー(MySQLd)を再起動して新しくレコードを追加すると「MySQLd 再起動前に削除した最新番号」が再利用されていた。

MySQL のマニュアルを調べてみると… 「14.6.5.1 従来の InnoDB の自動インクリメントロック」に

InnoDB テーブルに AUTO_INCREMENT カラムを指定すると、InnoDB データディクショナリ内のテーブルハンドルに、カラムに新しい値を割り当てる際に使用される自動インクリメントカウンタと呼ばれる特別なカウンタが含まれます。このカウンタは、ディスク上には格納されず、メインメモリー内にのみ格納されます。
InnoDB では、ai_col という名前の AUTO_INCREMENT カラムを含むテーブル t に自動インクリメントカウンタを初期化するために、次のようなアルゴリズムが使用されます。サーバーの起動のあとで、テーブル t への最初の挿入をするために、InnoDB は次のステートメントと同等なものを実行します。

SELECT MAX(ai_col) FROM t FOR UPDATE;

14.6.5.1 従来の InnoDB の自動インクリメントロック

と記載があり、MySQL の仕様でした。

MySQL の InnoDB テーブルでは、AUTO_INCREMENT の番号って、メモリ上で管理されていて MySQLd を再起動するとデータベース内のデータの最大値から再設定されるようになっていたのですね。

MySQL も PostgreSQL の「シリアル型」と同様にデータベースにAUTO_INCREMENT の値を持っていると考えていたこともあり、AUTO_INCREMENT は、削除しても「欠番」になり再利用されないと思い込んでいたので、意外な落とし穴があることに今更ながら驚いた。

カテゴリー
WordPress

RSSで各投稿者の最新記事を1件ずつ配信する

すぐに思いついたのは、posts_groupby フィルターフックで、Group By させる方法。

function post_groupby_tbnf1025 ( $groupby ){
    if ($query->is_feed) {
        global $wpdb;
        return "{$wpdb->posts}.post_author";
    }
}
add_filter( 'posts_groupby', 'post_groupby_tbnf1025' );

他にいい方法無いかなぁ…

カテゴリー
macOS Mail

macOS で稼働させている Postfix ログの見方

開発環境として、macOS を使っている場合に macOS に最初からインストール済みの Postfix を利用してメールの送信テストをしている。

プログラムからメールの送信がうまくいかないため、Postfix のログを確認すると /var/log/mail にログが記録されていない状況だった。

調べてみると macOS の場合、 log コマンドを使ってログを確認する必要があった。

Postfix のリアルタイムのログを表示する方法は、いろいろなところで紹介されていますが、問題が発生した際に過去のログを探す方法が分からないと言われたので紹介しておきます。

リアルタイムのログを確認する方法

log stream --predicate  '(process == "smtpd") || (process == "smtp")' --info

過去のログを表示する方法は、man log するとマニュアルに記載されていた。

     show             Shows contents of the system log datastore, archive or a specific tracev3
                      file.  If a file or archive is not specified, the system datastore will be
                      shown.  If it is from a future system version that log cannot understand,
                      it exists with EX_DATAERR (65) and an error message.  The output contains
                      only default level messages unless --info and/or --debug are specified.

書式は、

     log show [--archive archive | --file file] [--predicate filter] [--source]
         [--style json | syslog] [--start date/time] [--end date/time] [--info] [--debug]
         [--last time [m|h|d]] [--timezone local | timezone]

ということなので、

log show --predicate '(process == "smtpd") || (process == "smtp")' --info --start '2019-09-01' --end '2019-09-30 23:59:59'

で、無事に表示することができ、ろぐから問題点を把握できた。

カテゴリー
迷惑メール

さくらインターネットを騙ったメールが届いていた

さくらインターネットからの「重要なお知らせ」を装ったメールが届いていました。

おかしいなぁ… このドメイン、さくらインターネットで使っていないんだけどなぁ… 誰が勝手に申し込んだんだろう。(苦笑)

まあ、とりあえず URL を見に行くために、Webブラウザに URL を手入力してみると…   開いたのは、さくらインターネットの Webメールのログイン画面を真似した画面。アドレスバーをみると 「https://www.ngfbakery.com.au/ secured.sakura.ad.jprscontrol.webmail/sakura.html」(一部全角に変更) となっていて、ドメインが異なるのだけど、気が付かないで「メールアドレス」「パスワード」を入れる人がいるのでしょうね。(macOS の Mail.app が、「迷惑メール」と判断するぐらいだから流行しているんだろうなぁ…)

入力するとどうなるのかと思って、テストで 「admin@example.jp」「mail-pass-word」と入れてみると、リダイレクトされて本来のさくらインターネットのWebメールのログイン画面に転送されました。(メールアドレスとパスワードの収集が目的なサイトのようです。)

調べてみると さくらインターネットの公式サイトのサポート情報で「さくらメールボックスを騙る「なりすましメール」に注意ください。」とアナウンスされていますね。

皆様も不審なメールにはご注意ください。

カテゴリー
WordPress

カスタムテンプレートファイルのみ処理を分岐する

WordPress 案件で、特定の「カスタムページテンプレート」を表示している場合のみ処理を変えてほしいという話がありました。

WordPress の関数 is_page_template() で、使用しているテンプレートが判別できるので、これが利用できますね。

(例) custom_news_template.php を使用している際に 追加の CSS ファイルを読み込む。

functions.php で wp_enqueue_scripts フックで、追加CSS を読み込む際に条件分岐させる

function add_custom_css() {
    if ( is_page_template("custom_news_template.php") ){
        wp_enqueue_style( 'custom_news_style', get_template_directory_uri() . '/css/custom_news_style.css', "", '20190409' );
    }
}
add_action( 'wp_enqueue_scripts', 'add_custom_css' );

又は header.php で

<?php if ( is_page_template("custom_news_template.php") ): ?>
    <link rel="stylesheet" href="<?php echo get_template_directory_uri(); ?>/css/custom_news_style.css">
<?php endif; ?>

カテゴリー
WordPress

WordPressが出力するリンクURLのスキーマを強制的に書き換える。

WordPress の出力する HTML では、内部リンクも含めてすべての URL が絶対リンクになっています。

2018年より、主要なWebブラウザが 非SSLなサイトに対して「保護されていない通信」や「この接続は安全ではありません」とメッセージが表示されるようになったので、常時SSL化を進めています。WordPress の投稿にメディアを埋め込んでいる場合等に埋め込み時の従来の「http://〜」で始まるURL が残っている場合があります。

この場合URLが残っているページを表示した際に下記のような「混在コンテンツ」の警告が Webブラウザに表示されることがあります。

Mixed Content: The page at ‘https://example.com/’ was loaded over HTTPS, but requested an insecure image ‘http://example.com/wp-content/uploads/image20170301.png’. This content should also be served over HTTPS.

画像ファイルであれば、大きな問題にならないのかもしれませんが、CSS や JavaScript で発生した場合はファイルが読み込まれないため、レイアウトが崩れたり、スクリプトエラーが発生することもあります。

根本的な対策としては、すべての絶対 URL を 「http://〜」な URL に書き換えることですが、コンテンツの担当者が異なる等のいろいろな事情により簡単にできない場合もあります。

せめて、WordPress の内部リンクだけでも何とか対策したいと思ったので、下記のファンクションを導入して表示の際に URL のスキーマとホスト名を WordPress のサイトURLで置き換えるようにしてみました。

function my_homeurl_replace_tbnfn($buf) {
    $new_url = get_home_url();
    $old_url = str_replace( '/', '\\/', preg_replace( '/https*/', 'https*', $new_url ) );
    $buf = preg_replace( '/'.$old_url.'/', $new_url, $buf);
    return $buf;
}

function my_buf_start_tbnfn() {
    ob_start('my_homeurl_replace_tbnfn');
}

function my_buf_end_tbnfn() {
    if (ob_get_length()) {
        ob_end_flush();
    }
}

add_action('after_setup_theme', 'my_buf_start_tbnfn');
add_action('shutdown', 'my_buf_end_tbnfn');

プログラムの中身は単純で、php の ob_start() 関数で、出力内容をバッファリングして、「WordPressサイトのURL」を強制的に常時SSL化されたWordPressのサイトURLに書き換えて出力しています。

WordPress のサイトURLが、常時SSL化されていて、「get_home_url()」で「https://〜」な URL を取得できることが前提になっています。

カテゴリー
Blog

宅ふぁいる便が調査結果を発表

3月14日にオージス総研が、ファイル転送サービス「宅ふぁいる便」に不正アクセスがあった事件についての調査が完了したと発表していました。

それによると、流出したのは個人情報だけで、「一時預かりファイルの漏洩はなかった」となっています。

気になる「宅ふぁいる便」が再開されるかですが、下記のように発表されており、再開のめどは未定のようです。

宅ふぁいる便の今後について
将来にわたって安心してご利用いただくために、最新技術の採用や利便性向上等のためのシステム再構築が必要であることから、本サービスは当面休止とさせて頂きます。今後の対応につきましては、方針決定後速やかに当社ホームページ等でお知らせします。

https://www.ogis-ri.co.jp/news/1272165_6734.html
「宅ふぁいる便」サービスにおける不正アクセスについて ~お客さま情報の漏洩について(お詫びとご報告)~
画像はオージス総研から

【関連URL】

カテゴリー
未分類

円周率の世界記録が更新される

Google が円周率で、ギネス記録を更新したとニュースになりました。

それによると、Google は、Google Cloud 上で、小数点以下31兆4159億2653万5897桁まで円周率を計算したと発表しています。

Pi in the sky: Calculating a record-breaking 31.4 trillion digits of Archimedes’ constant on Google Cloud

【関連】

カテゴリー
Blog

円周率の日

今日は、「円周率」の日だそうです。

【関連】