blog.taaas.jp

MFA - MTで多要素認証を有効にするプラグイン

Movable Typeで、サインイン時に多要素認証を利用できるようにするプラグインを公開しました。

現時点では「Eメールによる確認コードの送信」と「Google Authenticator（TOTPが利用できるデバイスやアプリ）による確認コードの生成」に対応しています。（どちらか一方のみを、システムで有効化できます）

いずれのプラグインも、Movable Type 6 でも Movable Type 7 でも利用できます。（どちらかというと Movable Type 7 に最適化されています）

Eメールによる確認コードの送信

デモ

使い方

以下の2つのプラグインをインストールします。

インストールすると全てのユーザーで、サインイン時にEメール経由で送信される確認コードの入力が必要になります。

Google Authenticatorによる確認コードの生成

デモ

インストールに必要な要件

CPANモジュールのDigest::HMAC_SHA1を必要としています。マネージドなレンタルサーバーではインストール済みであることが多いと思います。自分で環境を構築している場合には明示的にインストールする必要があるかもしれません。

また、同じくCPANモジュールのMath::Random::MTは、必須ではないものの推奨されています。このモジュールがインストールされていると暗号的により好ましい設定が生成されます。（ただ、多要素認証はパスワード認証を補強するものであるので、「インストールされていなくてやや好ましくない設定が生成される」状態ではあっても、充分に有用なものであると言えると思います）

使い方

以下の2つのプラグインをインストールします。

インストールすると各ユーザーが、ログイン後に「システム > 多要素認証」のメニュー内の「Google Authenticator」で有効と無効を切り替えられるようになります。Google Authenticatorだけでなく、 AuthyなどTOTPに対応している多要素認証のコードを生成するアプリケーションであれば利用できると思います。有効化されているユーザーでは、サインイン時に確認コードの入力が必要になります。

万が一、デバイスを紛失するなどでコードが生成できなくなった場合には、管理者としてサインインすると「システム > ユーザー」で多要素認証のリセットを行うことができます。（管理者がサインインできなくなった場合にはまずは落ち着いて、その後プラグインをアンインストールしてサインインして、サインイン状態のまま再度インストールするとサインイン状態が維持されるので、そこでリセットの操作を行うことができます）

TODO

現時点では、これらのプラグインでは最低限の機能しか提供されていませんが、今後としては以下のような展開があってもいいかもしれません。

リカバリーコードを利用できるようにする
- デバイスが手元になかったり紛失したりしてしまった場合に利用できる、リカバリーコードを生成できるようになるとよさそうです
有効にする認証のタイプを選択できるようにする
- 現在は、システム全体でEメールかGoogle Authenticatorのどちらか一方しか利用できないので、ユーザー自身で複数のタイプから選択できるようになるとよさそうです
多要素認証のポリシーをシステム全体で設定できるようにする
- 「多要素認証を、全てのユーザーで必須にする」などのポリシーを定められるようになるとよさそうです

この記事について

この記事は Movable Type Advent Calendar 2017 の21日目の記事です。

記事を読む

MySQLの「Incorrect string value: '🍣'」問題

CREATE TABLE `注文` (
  `内容` TINYTEXT CHARACTER SET utf8mb4
);

なテーブルに、🍣だけをたくさん挿入しようとすると「Incorrect string value: '🍣'」になる。

> INSERT INTO `注文` (`内容`) VALUES (REPEAT('🍣', 64));
ERROR 1366 (HY000): Incorrect string value: '\xF0\x9F\x8D\xA3' for column '内容' at row 1

🍣 と 🍺の場合には「Data too long」になる。

> INSERT INTO `注文` (`内容`) VALUES (REPEAT('🍣 と 🍺', 64));
ERROR 1406 (22001): Data too long for column '内容' at row 1

TEXT系のカラムの場合にはカラムのサイズで切ったバイト列に対して正しい文字列かどうかを判定していて、そのためマルチバイトのエンコーディングで文字の途中で切られた場合には（実際には「Data too long」という理由で切られたのに）「Incorrect string value」となっていたということのようでした。

Bug #87100として報告してStatusはVerifiedになったのですが、その後動きがないように見えるので、今後どうなるかはよくわかっていません。

記事を読む

検証環境用のアクセス制限をnginxで11行で設定する

どんな状況での話か

公開前や移行時の確認用のサーバーに、念のためパスワードを設定しておきたい
- 厳密なアクセス制限は必要なく、「URLにアクセスしただけでは見られない」という程度の制限でよい
ウェブサーバーはnginxで、バックエンドのサーバーにプロキシしている
バックエンドのサーバーで、BASIC認証やDigest認証が使われている
- つまり、nginxで単純にBASIC認証をかけてしまうと不都合がある

という稀によくありそうな状況で、既存の設定に影響をあたえること無く11行くらいで設定する方法についての話です。

注意事項

ユーザーが思った通りに認証情報を破棄できなかったりするので、本番運用でのアクセス制限として利用するものではありません。

設定前のファイル

な感じです。

設定後のファイル

11行(変数定義などで+4行)追加して以下のようになります。

流れとしては、

サーバーでは、秘密のcookieが確認できない場合にはBASIC認証が必要とのレスポンスを返す
ブラウザでは、BASIC認証が設定されているときのダイアログが表示される
サーバーでは、正しいパスワードが送られてきた場合には秘密のcookieを設定する
それ以降は、秘密のcookieが設定されていればBASIC認証の情報は必要なくアクセスできるようになる

となっています。

あえてBASIC認証のダイアログである必要はなく、セキュリティ的には期待される動作と異なるUIで好ましくはないのですが、403的なページを用意するよりもパスワードのダイアログを出してしまった方が楽だし説明も省けるので、一時的な制限ならこんなのもありではないかと思います。

記事を読む

therubyracerをAlpine linuxでも動くようにするDockerfileを書きました

TL;DR

Alpine linux上では単純に$ gem install therubyracerしただけではtherubyracerは動かないのですが、これを動くようにするDockerfileを書きました。

DockerfileはDocker Hubのruby-with-therubyracerに置いてあり、usualoma/ruby-with-therubyracer:2.4.0-alpineという名前でbase imageとしても利用できるようになっています。（親のbase imageはruby:2.4.0-alpineです。）

何が必要だったか

therubyracerはlibv8というgemに依存しており、インストール時にlibv8に含まれるv8のライブラリにリンクされます。ここで、libv8は（ドキュメントにもあるのですが）通常だとコンパイル済みのバイナリで、Linuxの場合にはglibcにリンクされたものがインストールされるようになっているということのようです。そしてAlpine linuxではglibcではなくmusl libcがベースになっているという事情から、そのままでは動かないということでした。

そこまで分かれば後はlibv8をDockerfileでコンパイルすればよいだけなので既存のDockerfileを参考にしてlibv8をインストールして、その上でtherubyracerをインストールするようにしました。

docker image のサイズを抑えるためにやっていること

therubyracerではインストール時にlibv8のライブラリは静的にリンクされて利用時にはlibv8は参照されないようなので、libv8側のライブラリが含まれるディレクトリを$ rm -fr $(dirname $(dirname $(gem which libv8)))/vendorという形で削除しています。行儀のいいやり方ではありませんが、これだけで76MBほどかせぐことができます。

いずれにいしてもv8が入るのである程度大きくはなりますが、base imageから比較して55MB程度の増加で、debian8.0がベースのruby:2.4.0-slimで同じようにインストールしたものとと比較しても一応小ささは保たれているという感じです。

記事を読む

FilteredObjects - MTの「フィルタ」機能を公開側で利用するプラグイン

Movable Type のリスティングフレームワークの機能の一部である「フィルタ」を、MTタグやDataAPIのエンドポイントで利用することができるFilteredObjectsというプラグインを公開しました。

mt-plugin-FilteredObjects

記事やウェブページを複雑な条件で絞り込んで表示する場合、これまでは MTML で頑張るか、SearchEntriesで条件を指定していたと思います。FilteredObjects プラグインはこういったケースでのもう一つの選択肢になるものです。MTの「フィルタ」機能を利用するため（「フィルタ」は管理画面からGUIで条件を編集できるので）、プログラミングの知識がなくても条件を細かく指定することができ、MTMLの方ではそれを使ってシンプルな書式で結果を得ることができるようになります。

Getting sterted（とりあえず使ってみる）

プラグインのインストール

まずはFilteredObjectsプラグインをインストールしてください。

リスティングフレームワークを拡張するプラグインのインストール（必要な場合だけ）

FilteredObjectsはリスティングフレームワークを拡張する別のプラグインと組み合わせるとより強力になります。（プラグインによっては組み合わせることができない可能性もあります。）そして特に、カスタムフィールドで複数の条件を指定して絞り込みができるとここでは格段に便利になると思うので、おすすめはCustomFieldsListingプラグインです。（ただ実は、CustomFieldsListingプラグインはFilteredObjects側からだいぶ無理して利用させてもらう形になっているので、同時に利用した場合CustomFieldsListingの機能が正常に動作しなくなってしまう可能性があります。同時利用で不具合が起きる場合にはFilteredObjectsプラグインを削除してください）

「フィルタ」の準備

一覧ページで「フィルタ」の新規作成へと進み、条件を指定したあと、「識別子」を指定して「フィルタ」を保存してください。

screen-shot 2016-12-20 4.15.34.png

screen-shot 2016-12-20 4.17.36.png

MTMLで出力する

「識別子」を付けて保存した「フィルタ」は mt:FilteredEntries と mt:FilteredPages を使って以下のように出力することができます。

Data API で取得する

Data API では /filtered-objects/entries に filter パラメータを指定して取得することができます。

Advanced Usage（もう少し凝った使い方）

MTの「フィルタ」では、「または（OR）」という条件を指定することができないのですが、FilteredObjects では複数の「フィルタ」を「または（OR）」でつなげることができます。

やや複雑になるので、具体的な例で考えてみます。

複数のニュースのブログから条件を指定してピックアップする

以下のように、複数のニュース用のブログがあるとします。

会社全体のニュース
製品毎のニュース

ここで、ウェブサイトのトップページに、

会社全体のニュースからは全部
製品毎のニュースからは「全体のニュースに表示する」にチェックを入れたものだけ

という条件で表示するケースを考えます。

この場合は「フィルタ」を2つ、それぞれ上の条件と同じものを指定して作成します。（特定のブログを指定するための「ブログID」の条件はMTの標準では表示されませんが、FilteredObjects をインストールすると表示されるようになります。）

screen-shot 2016-12-20 5.00.56.png screen-shot 2016-12-20 5.03.40.png

screen-shot 2016-12-20 5.09.59.png screen-shot 2016-12-20 5.10.34.png

スクリーンショットの内容で、以下の2つのフィルタを作成したとします。

blog-general-news
show-in-general-news

ここまでできれば MTML 側は簡単で、 mt:FilteredEntries タグの filter に2つのフィルタを「OR」でつなげて指定することで目的の記事を表示することができます。

また、Data API の /filtered-objects/entries エンドポイントで取得することもできます。

制限事項など

MTタグ、Data APIのエンドポイントの両方で、公開されている記事のみが対象になります
誤って削除してしまうことのないように、「識別子」を付けた「フィルタ」ではゴミ箱アイコンが表示されなくなります
- 「システム > フィルタの管理」で削除することができます
種類が「日付と時刻」のフィールドでは「今より前」「今より後」が表示されますが、これは CustomFieldsListing を独自に拡張しているもので、うまく動かない場合は FilteredObjects 側の問題です
- 日付の場合「今より前」は「今日の23時59分59秒より前」となり、「今より後」は「今日の0時0分0秒より後」となります
「自分の記事」の条件には未対応です
対象となるブログは「フィルタ」からいい感じに選択されるはずですが、うまくいかない場合には明示的に指定してください
- mt:FilteredEntries/mt:FilteredPages では、マルチブログのモディファイアを指定することができます
- /filtered-objects/entries エンドポイントでは、blogIds パラメータにブログのIDを「,」（カンマ）区切りで複数指定することができます

FilteredObjects プラグインでの「フィルタ」の運用について

MTでは「フィルタ」は「ユーザ」毎に管理されるデータなので、FilteredObjectsのようにテンプレートやData APIでで利用する道具としては向いていない部分があります。（他の「ユーザ」の「フィルタ」を見ることができない、など。）

「識別子」のついた「フィルタ」がいろいろな「ユーザ」のデータとして散らばるのは好ましくないと思うので、現時点としては『専用の「ユーザ」を作成して、全ての「フィルタ」はそこで管理する』が現実的な一つの回避策ではないかと思っています。

プラグインのインストール

GitHubからzipファイルをダウンロードしてください。リリース一覧
ダウンロードしたファイルを展開してください。
pluginsディレクトリにアップロードしてください。
インストール後のディレクトリの配置は以下のようになります。
```
$MT_HOME/
    plugins/
        FilteredObjects/
```

サポートしている機能

スタティックパブリッシング
Data API

サポートしていない機能

ダイナミックパブリッシング

動作環境

この記事について

この記事は Movable Type Advent Calendar 2016 の20日目の記事です。

記事を読む