プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

Cognito ユーザープール : メールアドレスの変更と確認について

Cognito ユーザープール、少しづつですが使ってみています。

今回はメールアドレスの変更をやってみました。基本的には、ドキュメントにある通り処理をすればOKです。

メールアドレスも属性の一つなので、属性の更新を行えば更新できます。 ただ、同じページのサンプルに『属性の確認』というのがあります。

言葉からすると、きっとメールアドレスを変更した場合はこれで再度確認をしないといけないんだろうな、と想像がつきます。が、いまひとつよくわかりません。 なので、いろいろと試した結果を、自分用のメモとしてまとめておきます。

前提

いま試しているユーザープールの設定は、

  • エイリアスは指定していない
  • ログインは、ユーザー名のみを許可
  • 属性として、 メールアドレス、preferred_username を追加

となっています。このあたりの設定が異なると、以下の挙動も違うかもしれませんのでご注意ください(特に確認していません)。

メールアドレスの変更で起きること

まず試しにメールアドレスを変更してみます。 変更前は、こんな感じだったのが、

f:id:junichim:20180817084816p:plain

メールアドレスを変更すると、こんな感じになりました(属性の確認は未実施)。

f:id:junichim:20180817084917p:plain

  • アカウントそのものは CONFIRMED の状態のまま
  • email_verified のステータスが false となる
  • アカウントに対するメールアドレスは変更済み(黒塗りでわからないですが、変わってます)

つまり、確認され有効なアカウントに対して、メールアドレスを変更すると、メールアドレスの確認が取れていないが、登録メールアドレスそのものは変更されている、という状態になります。 また、メールアドレスの変更時は、存在しないメールアドレスや別のアカウントで使っている重複するメールアドレスを指定しても変更ができました。なお、重複するメールアドレスの扱いはエイリアス指定があるときっと挙動が変わってくると推測されるところです。

この状態(メールアドレスだけ変更して、属性の確認は未実施)だと、なにができてできないかを調べたところ

  • ログイン:できる
  • パスワードのリセット:できない
  • メールアドレスの再変更:できる

となりました。登録メールアドレスが未確認の状態でも、パスワードでログイン等をする分には問題ないようです。 また、間違ったメールアドレスを入力してしまった、という場合でも、再度メールアドレスの変更ができるのでなんとかなるようです。

ということで、この状態でこまるのが、パスワードのリセットですね。 下記の記事にも、困ってしまった話が載っていました。

wp-kyoto.net

メールアドレスの確認

では、ということで、『属性の確認』を行えば、メールアドレスの確認ができるのだろうと考え、メールアドレスの確認処理を実装してみました。 となるのですが、公式のサンプルがちょっとわかりにくかったので、少し自分で修正してみました。

公式のサンプルだと、確認コードの取得(登録メールアドレスに送信)と確認コードの検証が一緒になったサンプルになっているようです。 なので、

morisoftsample.getAttributeVerificationCode = function(cognitouser) {
    return new Promise(function(resolve, reject) {
        cognitouser.getAttributeVerificationCode('email', {
            onSuccess: function(result) {
                console.log('success getAttributeVerificationCode');
                resolve(result);
            },
            onFailure: function(err) {
                console.log('failed getAttributeVerificationCode: ' + JSON.stringify(err));
                reject(err);
            }
        });
    });
}

という確認コードの取得(登録メールアドレスに送信)する関数と

morisoftsample.verifyAttribute = function(cognitouser, vericode) {
    return new Promise(function(resolve, reject) {
        cognitouser.verifyAttribute('email', vericode, {
            onSuccess: function(result){
                console.log('email verification success');
                resolve(result);
            },
            onFailure: function(err) {
                console.log('email verification failed');
                reject(err);
            }
        });
    });
}

という、取得した確認コードでメールアドレスをverifyする関数に分離してみました。 なお、上記のサンプルでは、それぞれの処理を Promise でラップしていますので、Promise を使わない場合は適当に読み替えてください。あと、cognitouser というのは、

で取得したログイン済みのユーザーになります。

この関数を呼び出すように、クライアント側のjavascriptを書くと、めでたく、確認コードの取得と確認コードのverifyを分けて扱うことができました。

ちなみに、Githubのリポジトリのほうのサンプルの Use Case 6 に少しだけ説明が載っていますので、ご参考までに。

github.com

はてなブログを https に対応しました (2/2)

はてなブログを https に対応させた話の続きです。

blog.mori-soft.com

Mixed Contents の修正

HTTPS Checker で Mixed Contest ありと指摘された ページを順次みていき、修正していきます。 自分のサイトの場合は、次のような点について修正しました。

はてなfotolifeの画像

幸い、はてなブログを使い始めたのが最近(2016/8頃、移行の顛末はこちら)だったためか、特に記事の更新をせずとも、https になっていました。 はてなブログへ移行時にインポートした記事も同様です。

これは助かりましたね。

埋め込みリンクの修正

他のサイトや自分の過去の記事にリンクを貼る際に、リンク先が http でかつ埋め込みでリンクを貼っていると、埋め込みが iframe のため、 Actice Mixed Contents として扱われます。

これは、地道に https に直していきます。この時、リンク先のサイトが https に対応していない場合は、URLが https のままとなるのは仕方ないので、埋め込みではなく『タイトル』等のリンク方法に変更します。

Tex 記法

テストサイトでは Tex記法 を含む記事は Passive Mixed Contents となっていました。 で、この Tex 記法を含む記事は、編集画面で更新をしてやると、Mixed Contents が解消されていました。

とはいうものの、テストサイトで、 Mixed Contents となっていたのですが、https 化した本ブログで記事が Mixed Contents か否かを確認する前に、 Tex 記法を含む記事を更新してしまったので、何もしない状態で Mixed Contents だったのかはいまとなってはわからないです。

まあ、少なくとも、記事の更新すれば問題なくなるとはいえるかもしれません。

にしても、確認忘れ、しまったなー。

dropxbox

この部分は、直接的には Mixed Contents とは無関係なのですが、一緒に作業したので備忘録として残しておきます。

はてなブログに移行した際の設定で、画像以外のファイルは、 dropbox から配信するようにしていました(こちらの記事を参照)。

今回、Mixed Contents の確認作業でたまたま気づいたのですが、 dropbox ってファイルをホスティングして公開する機能を廃止していたようです。

単にリンク先からファイルをダウンロードするだけなら今でも使えますが、html や javascript のコンテンツとして扱おうとするとできなくなっていました。

なので、これらのファイルをホストする場所を変更します。 どこがいいかな?と考えたのですが、いろいろと面倒がなさそうだということで、 S3 を使うことにします。

ということで、dropbox で公開していたコンテンツを S3 に移行します。 併せて、URL を dropbox のものから S3 のものに変更します。

なお、 S3 側の公開方法は ウェブサイトホスティングを使うのではなく、ファイルごとにパブリックアクセスを行うという方法をとることにします。

qiita.com

というのも、ウェブサイトホスティングにすると、CloudFront 経由の設定にしないと https でアクセスできなくなるためです。 ホストしているコンテンツもそんなに多くないので、そこまでしなくても、というのが本音です。

OpenLayers

本ブログ中で OpenLayers のサンプルについて書いたものがいくつかありました。 で、記事に埋め込む形で、実際に動作するサンプルを載せていました。 記事作成当時は、ライブラリ自体も http での配信だったので当然記事中でも https でURLを指定しています。

まずはこれを https で取得する必要があります。単純に http -> https でいけるかと思いきやダメでした。困ったなと思って調べていると、CDNで配信していることがわかりました。

ちょうど、記事作成当時、使っていた 2.13.1が配信されていたので、

cdnjs.com

こちらの一覧から、必要なライブラリのURLを取得して、それを指定します。

また、サンプルの js ファイルを dropbox から配信していたこともあり、前節のとおり、 https 化以前から動いていなかったようです。 そこで、必要な js ファイルを S3 から取得するように変更します。

最後に、タイルサーバーを指定します。OpenLayers (少なくともこのバージョン)では何も指定がなければ、デフォルトの openstreetmap.org のサーバーを http で使うようです。

gis.stackexchange.com

これについて、上記記事にかかれているように、

   map.addLayer(new OpenLayers.Layer.OSM(
            "OpenStreetMap", 
            // Official OSM tileset as protocol-independent URLs
            [
                '//a.tile.openstreetmap.org/${z}/${x}/${y}.png',
                '//b.tile.openstreetmap.org/${z}/${x}/${y}.png',
                '//c.tile.openstreetmap.org/${z}/${x}/${y}.png'
            ],
            null)
        );

のように、タイルサーバーを指定するようにしました。

その他

Mixed Contents とは少し違うのですが、 https 化の際に気になった点を書いておきます。

Slideshare

Slideshare については、CORS でエラーが出るようです。

とりあえず、対策はないようです。困りましたね。とりあえずは現状のままとしておきます。

はてなブログのログイン画面

こちらの記事に載っていたのですが、

https://atn.hateblo.jp/entry/2017/11/23/105121atn.hateblo.jp

はてなブログのログイン画面って、ブラウザの横幅を小さくしていくと、アドレスバーに注意のアイコンがつき、『この接続は安全ではありません」が表示されるようになります。 手元のFirefoxで試してみたら、見事に再現しました。

f:id:junichim:20180802105850p:plain

f:id:junichim:20180802105901p:plain

こんなこともあるんですね。なかなか https 化は難しいようです。

さいごに

一応、これで Mixed Contents も解消したはずです。とはいうものの HTTPS Checker で漏れなくチェックできているかちょっとわかりません。現に、 OpenLayers 関係の記事でチェックから漏れているものがいくつかありました。まあ、あとは問題を見つけ次第適宜修正するというのが良いのかな。

とりあえず一段落です。

はてなブログを https に対応しました (1/2)

昨今、サイトを https にしないとダメなようで、はてなブログも https に対応してくれました。

このブログも仕事の合間を縫って、 https 化してみたので、作業メモを残しておきます。

準備

どういう問題が起こりそうか、事前に何をしておけばよいのか調べておきます。

このブログの場合に関係しそうなところとしては、

  • はてなfotolife の画像貼り付け
  • Amazon のアフィリエイトリンク

といったところになりそうです。 はてなfotolifeが記事の変更なしでいいけど、更新しないといけないのがちょっとやっかいそうです。

まずは、下記の記事を参考にテスト用ブログを立ち上げて、そちらでいろいろと調べてみようと思います。

バックアップ

まず、テスト用ブログ構築とバックアップを兼ねて、既存記事をエクスポートしておきます。 エクスポートは、はてなブログの管理画面から『設定』->『詳細設定』とすすむと、下のほうに『エクスポート』とあるので、こちらをクリックします。

f:id:junichim:20180802090013p:plain

すると、

f:id:junichim:20180802090203p:plain

のような画面が表示されるので、『(ブログ名)をエクスポートする』ボタンを押せば、OKです。

問題なくエクスポート作業が完了すると、

f:id:junichim:20180802090250p:plain

のような画面が表示されるので、『ダウンロード』ボタンを押して、データを取得しておきます。

テストブログ構築

はてなブログの場合、1アカウントについて10個までブログを作れます(PROの場合です)。無料版だと3つですね。

なので、テスト用のブログを立ち上げて、そちらでいろいろとテストしておきます。『ダッシュボード』から『新しいブログを作成』を選択し、必要事項を入力すれば完了です。

f:id:junichim:20180802092220p:plain

ブログを立ち上げたら、設定を本来のブログと合わせておきます。主なものとしては、

  • テーマの設定およびカスタマイズの内容
  • 編集モード
  • キーワード自動リンク

あたりでしょうか。 なお、現時点(2018/8/1)では、新規にブログを立ち上げると、いやでも https が有効になっています。なので、httpsに関する設定は特に必要ありません。

準備ができたら、さきほどバックアップした記事をインポートします。なお、インポート時の注意点は、

  • キーワード自動リンクの設定をオフにする前に、記事をインポートすると、あとから設定を変更しても反映されません。
  • エクスポート前の編集モードがMarkdownであっても、インポート後は設定によらず、すべて『見たまま』モードになります。

といったものがあります。特に2つ目は注意が必要ですね。

今回の作業中も、2つ目の編集モードが変わっていることに気づかず、記事中で Markdown 記法のものを検索してもひっかからないということがありました。

なお、編集モードが変わってしまうことを考えると、この機能はあくまでも簡易的なバックアップとしての利用にとどめておいたほうが良さそうです。

(参考)

混在コンテンツのチェック

さて、準備が出来たら、早速混在コンテンツのチェックです。 混在コンテンツのチェックには、Chromeの開発者モードを使う、などというのがありますが、記事数が多いとやってられません。

ということで、ツールの登場です。下記の説明でもツールが2つほど紹介されています。

このうち、オンラインで使える

www.jitbit.com

は、残念ながらページ数の上限が200ということで、このブログですら記事数が200を超えるので、あきらめました。

なので、今回は HTTPS Checker を使うことにします。

httpschecker.net

HTTPS Checker については下記の記事などを参考にしました。

HTTPS Checker のインストール

サイトからツールをダウンロードして、exeファイルをダブルクリックしてインストールします。 問題なくインストールが完了すれば、下記のような画面が表示されて、メールアドレスの登録を求められます。

f:id:junichim:20180802092453p:plain

メールアドレス他、必要事項を入力すれば、起動します。

HTTPS Checker の実行

HTTPS Checker を起動すると、下記のようなURL入力画面が表示されます。

f:id:junichim:20180802092904p:plain

さきほど作ったテスト用のブログのURLを入力して、Modeとして Mixed Contents Only を選択します。 Run ボタンを押したら、チェック開始です。

無事にチェックが完了するとこんな感じの画面が出て、どのURLに問題があるか教えてくれます。

f:id:junichim:20180802093206p:plain

f:id:junichim:20180802094141p:plain

実は、このブログ、現時点で記事数が211ありました。で、HTTPS Checker の上限が500ページなので、大丈夫かな?と思っていたのですが、ブログって、ひとつの記事に対して、投稿年月別やタグ別のリンクも生成するので、全然足りませんでした。

なので、エクスポートしたファイルが幸いテキストファイルだったので、これを適当に2分割します。で、テスト用ブログを2つ作り、それぞれに対して分割した記事を割り当てます。で、 HTTPS Checker を2回実行する形でチェックしました。 (結局、両方の合計で 515ページでした。あと少しで500ページに収まったのになー。惜しかったなー)

https 化

HTTPS Checker で Mixed Contest ありと指摘された ページを修正していきます。 修正の手順はいろいろとあると思いますが、はてなブログの場合、インポートした記事は編集モードが見たままモードになっており、ちょっと作業がやりにくいと感じました。

なので、ざっと指摘されたページの内容を見て確認したうえで、対象記事数もそんなに多くなかったので、最悪表示されなくても影響は少ないと考え、先にブログ本体を https 化して、そのうえで終生作業を行うことにしました。修正対象記事のURLは、さきほどの HTTPS Checker を見れば分かりますしね。

既存ブログの https 化は非常に簡単で、『設定』->『詳細設定』を選択し、

f:id:junichim:20180802093706p:plain

『HTTPS配信』の『HTTPS配信の状況を確認する』をクリックすると

f:id:junichim:20180802094319p:plain

のような確認画面が表示されるので、『変更する』をクリックすると、https が有効になります。

つづく

長くなってきたので、実際の Mixed Contents の修正については下記にまとめます。

blog.mori-soft.com