blog.taaas.jp

発生する条件

php.iniで以下のように設定されている時に、multipart/form-dataでUTF-8の内容をPOSTすると文字化けすることがある。（application/x-www-form-urlencodedでは文字化けしない）

mbstring.encoding_translation = On
mbstring.http_input = auto
mbstring.internal_encoding = UTF-8

どんな流れで発生しているか？

PHPではPOST時のハンドラをMIMEタイプ毎に登録する仕組みになっているようで、mbstringでは以下の場所でapplication/x-www-form-urlencodedとmultipart/form-dataで別々のハンドラが登録されている。

https://github.com/php/php-src/blob/master/ext/mbstring/mbstring.c#L680-L681

application/x-www-form-urlencodedの場合はmbstring内でリクエストのボディ全体から文字コードを判定するため、期待した通りUTF-8として扱われる

multipart/form-dataの場合は以下の場所で文字コードの判別が行われるが、

https://github.com/php/php-src/blob/master/main/rfc1867.c#L427-L429

判別対象のデータが例えば以下のようなヘッダー行なので、

Content-Disposition: form-data; name="name"

「mbstring.http_input = auto」 => 「ASCII,UTF-8」だとASCIIだと判定されてしまい。その下に続く内容もASCIIとして「ASCII -> UTF-8」で変換が行われてしまう。

回避方法

以下のような方法がある。

• 「mbstring.http_input = UTF-8」にする
• フォーム要素に「multipart/form-data」をつけない
• 全ての項目のname属性にマルチバイトの文字を入れる

以下のようなフォームであれば文字化けしない。

<form enctype="multipart/form-data" method="POST">
<input name="📛" value="天野" />
</form>

この記事について

iOS12で利用できるようになったショートカットアプリは、自分の好みの「手順」をSiriから呼び出せるようにしたりホーム画面にショートカットを作ったりできるというものですが、その中でどうやら「手順」としてウェブAPIへのリクエストをなかなか自由にできるらしいという話を聞いたので、それならばということで、Movable TypeのData APIとの連携を試してみました。

この記事では、実際の運用でありえそうなパターンとして以下の3つのサンプルを紹介します。

• 写真を選択して記事を作成
  • 写真は複数選択が可能で、記事には写真を撮影した際の位置情報が付与されます。
• Evernoteから記事を作成
• コンテンツタイプとしてURLを収集

それぞれのパターンについて、項目の下の方にエクスポートした「.shortcut」へのリンクを置きました。iOS12でショートカットアプリをインストールしてあれば、実際にショートカットを試してみることもできます。（動画では実行時にパスワードが表示されてしまっていますが、「.shortcut」からインストールされるバージョンでは実行しただけでは表示されないように修正されています。）

対象になるMTのバージョン

コンテンツタイプを利用するサンプルではMT7が必要です。それ以外のサンプルはMT6でも動作します。

写真を選択して記事を作成

ショートカットアプリを使うと「共有シート」に項目を追加して、選択した写真を「ショートカット」に渡すことができるようになります。

このサンプルではそれを使って、以下の操作で記事を作成できるようにしてみました。

1. 写真を選択（複数可）
2. シェアボタンから、登録したショートカットを選択
3. タイトルと本文を指定

写真はアセットとしてアップロードされ、記事の本文に挿入されます。（カスタムフィールド版もあります）写真に位置情報が含まれている場合には、緯度と経度も投稿情報に含まれます。

MTへ画像を投稿.shortcut

カスタムフィールド版

カスタムフィールド版では、「記事」に対して以下のようなベースネームを持つフィールドが設定されていることを想定しています。

• image
• latitude
• longitude

1枚目の画像がimageのフィールドに入り、2枚目以降の画像は本文に挿入されます。

MTへ画像を投稿（カスタムフィールド版）.shortcut

Evernoteから記事を作成

メモアプリや編集アプリからデータを受け取り、MTで記事を作成するパターンです。ここではEvernoteと連携させています。

Evernoteでは普通に書くとh2、h3などの細かい指定はできないため、以下のような形で置き換えるようにしています。

• 太字 -> h3
• リスト -> そのまま
• その他 -> divなどは削除し、極力シンプルなHTMLになるようにする

変換結果がやや不安定なので、このサンプルは現実的に使い物になるかどうかはやや微妙です。Markdownの編集アプリからそのままMarkdownとして投稿などの方が現実的かもしれません。

EvernoteからMTへ投稿.shortcut

コンテンツタイプとしてURLを収集

スマートフォンからアクションすると考えると、「記事」よりも細かい（「ソーシャルブックマークに追加」程度の）粒度でなにかできるとよい場合もあると思います。このサンプルでは、以下のようなフローで記事作成を行うための「URLの収集」をショートカットでできるようにしてみました。

• 記事にするURLをスマートフォンで収集しておく
• 後で収集したURLを組み合わせて「まとめページ」をつくる

こういった場合には、MT7のコンテンツタイプが使えそうです。

• URL
• タイトル
• og:image
• 埋め込みHTML

といったフィールドをもつコンテンツタイプを作り、ここにデータを貯めていきます。「タイトル」「og:image」はショートカットの中で自動で取得します。「埋め込みHTML」はURLがTwitterの場合にのみ、oembedのAPIを使って自動で取得します。（少し拡張すれば、YouTubeなどoembedのAPIを提供している他のサービスでも取得できるようになります）

URLをMTへ保存.shortcut

管理画面の方は以下のような雰囲気です。

サンプルの紹介は以上になります。

サンプルを利用する場合の注意事項

これらのショートカットアプリではWebアプリのパスワードを利用するのですが、「テキストデータ」としてしか保存する方法が見つからなかったので、「ショートカット」を開くと確認できる状態で保存されます。一応、通常の使用では表示されないように工夫はしているのですが、アプリから開くと容易に表示可能です。特に強い権限を持つユーザーで利用する場合には注意が必要です。（「iCloudキーチェーン」が使えるとよさそうなのですが、それはまだできないようで。）

「ショートカット」の可能性

ショートカットアプリで作成した「ショートカット」は共有のために書き出すことができるのですが、書き出されるファイルは（バイナリの）plist形式なので、少し手を加えることでテキストエディタで編集することもできます。Macであれば以下のようなコマンドを実行することで編集が可能です。（Linuxにも同様の結果を得ることができるコマンドがあります）

テキストとして編集できることにより、例えば以下のようなことができるようになります。

• エンドポイントの設定の埋め込み
• ユーザーIDやパスワードの埋め込み
• メッセージの多言語化

これらを利用することで、例えばリテラシーの高くないユーザーに対しても「（編集済みの）ショートカットを受け取ってインストールするだけで、エンドポイントやパスワードを設定しなくても利用できる」というようにすることができそうです。

まとめ

これはなかなか面白いものだと思います。上のサンプルよりもっとシンプルなものでも、例えば「アセットの一括アップロード」だけでも十分に役立ちそうなので、MTを使っているならば（特別にマッチするような運用ではなくても）普通に便利に使えるような気がしています。 パスワードをそのまま埋め込まざるを得ないなど、現状としては課題もありますが、それらは今後のアップデートを（あまり期待せずに）待ちたいと思います。

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

• mt-plugin-MFA
• mt-plugin-MFA-Email
• mt-plugin-MFA-GoogleAuth

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

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

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

デモ

使い方

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

• mt-plugin-MFA
• mt-plugin-MFA-Email

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

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

デモ

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

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

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

使い方

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

• mt-plugin-MFA
• mt-plugin-MFA-GoogleAuth

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

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

TODO

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

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

この記事について

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

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になったのですが、その後動きがないように見えるので、今後どうなるかはよくわかっていません。

どんな状況での話か

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

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

注意事項

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

設定前のファイル

な感じです。

設定後のファイル

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

流れとしては、

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

となっています。

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