まず、今回紹介するのは Node.js + Express で作った API を CORS 対応にする、という、これ自体はシンプルな内容なのですが、この話を考えるに至った経緯を最初にまとめておきます。


【背景】
普段からウェブアプリケーション・サービスを開発しています。詳しいアーキテクチャはともかく、ユーザーのアクセス先となるフロントエンドのアプリケーション・サーバーとバックエンド（データベースなど）があって、クラウドっぽくバックエンドには API サーバー経由でアクセスする、という形態を多く採用しています。

この形態を採用している時に限らない話ですが、「サービスの安定運用」を考えると「いかにフロントエンドを安定させるか」を考慮する必要があります。ネットワークやバックエンド含めたサービス全体のどこかに不具合が生じた場合であっても、ユーザーが最初にアクセスするフロントエンドが動いていれば「画面に障害発生メッセージを出す」ことができるようになります。逆にフロントエンドにアクセス過多を含めた不具合が発生してしまうと、「メッセージで利用者に不具合が発生していることを知らせる」ことすらもできなくなってしまいます。

このフロントエンドサーバーを安定稼働させるための技術として、最近は（docker などの）コンテナ技術であったり、（k8s や OpenShift などの）コンテナのオーケストレーション技術が流行っています。ここまでは「いわゆる一般論」的な話です。

一般論を理解した所で、技術者としての「一般論ではない話」も考えます。自分は業務でもプログラミングや作ったりサービスの運用を行ったりしていますが、業務外でも（つまり個人でも）プログラミングしたり、作ったサービスを公開して運用したりします。２つの異なる立場を持っているわけです（決して珍しくないと思ってます）。前者ではある程度の予算の中でクラウドのサービスを契約したりして、必要であればベンダーが提供するコンテナやコンテナ・オーケストレーションも使って構築することになります。　一方後者では、これらのインフラ構築部分も自腹になるわけです。まあ「これも授業代」と太っ腹に考える人は立派だと思いますが、コンテナ・オーケストレーションまで使おうとするとそれなりに懐も痛む価格だったりします。


要するに「個人開発者としての自分はケチ」なわけで（繰り返しますが、決して珍しくないと思ってますｗ）、「ケチはケチなりに知恵と作業でなんとかしたい」と考えるわけです。コンテナ技術やコンテナ・オーケストレーション技術を否定するつもりは全くありませんが、「より安価」に「フロントエンドを安定稼働」させる方法はないものか、と：



＃「コンテナ・オーケストレーションまで自分で構築すればいい」と考える人もいると思うので一応コメントを。技術的にはそのとおりなんですが、目的はあくまで「安価なフロントエンドの安定稼働」です。そう考えると例えば１ノードで構築した場合に目的を達成しているといえるか・・・　では複数ノードを構築する場合、今度は安価といえるのか・・・　となってしまうと考えました。


そんな自分にひらめいた１つの案が「フロントエンドを GitHub Pages にする」方法です。GitHub Pages は GitHub の無料アカウントがあれば使うことのできる「静的ウェブコンテンツの公開サービス」です。GitHub の一部として考えると、容量は（ほぼ）無制限で、アップロード直後にバックアップされ、世界中のウェブサービスの中でも指折りの安定稼働を誇っています。「フロントエンドを安定させたい」という目的だけを考えると、「かなり使える案」だと思っています：

（↑フロントエンドを GitHub Pages にして、バックエンドを IBM Cloud にする場合）


もちろんこの方法は万能ではありません。まず GitHub Pages で公開できるコンテンツはウェブアプリケーションではなく「静的ページ」、つまり HTML ページに限られます（この時点で i18n などを考慮するアプリケーションページの公開は難しくなります）。表示データは REST API で取得すれば良いのですが、フロントエンドが静的ページである以上、通信は AJAX に限られてしまいます。その結果、API 側は（クロスオリジン通信をすることになるため）CORS を考慮した設計が必須となります：



フロントエンドはウェブアプリケーションではないので、ウェブページをテンプレートから作る、といった便利な手法が使えず、AJAX を駆使したレンダリングを実装しないといけないことも不利な点となりますが、バックエンド側も考慮点の影響が大きな方法ではあると思っています。ただ「安価にフロントエンドを安定稼働」させる面ではイケそうな方法にも感じています。


・・・といった背景がありました。この前提だと REST API 部分も便利なサービスを有償契約して使うのではなく、安価なアプリケーション・サーバーを使って、自前で API サーバーを構築する必要があります（最悪、ここにトラブルがあってもフロントエンド側ではその旨を伝えることができる構成）。というわけで、無料のライトプランが使える IBM Cloud で「Node.js + Express で作った API を CORS 対応にする」ための方法を理解しておく必要がありました。


【Node.js + Express の REST API を CORS 対応する】
こちらはサンプルを用意しておきました：
https://github.com/dotnsf/express-cors


まず settings.js の exports.cors 配列変数内にクロスオリジン通信を許可するオリジン（ドメイン）を登録しておきます。デフォルトでは以下のようになっていて、'http://localhost:8080' と 'https://dotnsf.github.io' からの AJAX 通信を許可するよう設定しています。前者はローカルでの動作確認用ですが、実際に Github Pages で運用を始めた後は削除しておくべきです。後者は僕の Github Pages のドメインです。実際にみなさんが Github Pages でこの API を使う場合は自分自身の Github Pages ドメインに変更してください：

//. settings for CORS
exports.cors = [ 'http://localhost:8080', 'https://dotnsf.github.io' ];

本体とも言える app.js の内部は以下です：

//. app.js
var express = require( 'express' ),
    app = express();

var settings = require( './settings' );

app.use( express.static( __dirname + '/public' ) );

//. CORS
if( settings && settings.cors && settings.cors.length && settings.cors[0] ){
  var cors = require( 'cors' );
  var option = {
    origin: settings.cors,
    optionSuccessStatus: 200
  };
  app.use( cors( option ) );
}

app.get( '/ping', function( req, res ){
  res.contentType( 'application/json; charset=utf-8' );
  res.write( JSON.stringify( { status: 'OK' } ) );
  res.end();
});


var port = process.env.PORT || 8080;
app.listen( port );
console.log( "server starting on " + port + " ..." );

赤字以外の部分はごく普通の Node.js + Express を使った REST API アプリケーションです。この例では GET /ping という動作確認用のシンプルな API を１つだけ定義しています（サーバー側に障害等が起きていなければ、返り値は常に { status: 'OK' } という JSON です）。

肝心の CORS の対応をしているのが赤字部分です。settings.js の内容を確認し、exports.cors 配列に有効な値が１つでも含まれていると判断した場合は、cors ライブラリを使って設定されているオリジンを対象に CORS を有効にします。ちなみに settings.js の exports.cors が例えば null とか []（空配列）とかに設定されている場合は CORS の処理が行われないので、CORS の処理としてはデフォルトの「全てのクロスオリジンからの AJAX アクセスを許可しない（同一オリジンからの AJAX アクセスのみ許可する）」ことになります。

あとは必要に応じてベーシック認証を加えるとか、トークン認証を加えるとか（フロントエンドが静的コンテンツだとトークンの管理が面倒そうだけど）するなどして CORS 対応の REST API を構築することができます。ここは手順がわかってしまえば簡単そうですね。


【運用時】
こんな感じでデータベースへの読み書き検索などが REST API 化され、CORS 対応までできていれば Github Pages の HTML からも利用できるので、かなり安定したフロントエンドコンテンツを実現できそうです。この形で REST API が実現できていると、例えばウェブアプリを作るハンズオンでもあらかじめ用意した REST API を Github Pages から呼び出す形で実現できるので、フロントエンドの運用サーバーは無料で（しかもかなり安定したものを）用意できます。更にフロントエンド部分の開発時にはこんなフォルダ構成の Node.js + Express のアプリケーションにしておくと docs/ 以下の静的コンテンツを対象に作って、ローカルで動作確認もして、コードごと Github にあげて docs/ 以下を Github Pages で公開する、といった便利な開発・運用も可能になります：

//. app.js
var express = require( 'express' ),
    app = express();

app.use( express.static( __dirname + '/docs' ) );

var port = process.env.PORT || 8080;
app.listen( port );
console.log( "server starting on " + port + " ..." );

（↑メインファイル。静的コンテンツのフォルダを /docs に指定している以外はごく普通のシンプルな Express アプリ）



（↑このプロジェクトを Github に上げる）



（↑Github Pages の設定で /docs フォルダ以下を公開するよう指定する）


フロントエンドコンテンツは全て AJAX 対応させる必要があり、昨今の流行りとは違う形での実装は必要になります。それはそれで大変だし、普通のウェブアプリケーションで使える便利な技術も使えなくて不便な面も出てくるのですが、"Poorman's stable web contents" みたいに割り切って使うネタを準備しています。まだアイデア先行な面もあって実証実験が必要な段階だと思っていますが、運用していて気づくことがあったらまたこのページに追記します。

タグ ：

#node.js

#nodejs

#express

#cors

Github の認証をスマホアプリを使った２段階認証にするための手順を紹介します。対応したスマホアプリはいくつか存在しますが、このブログエントリでは IBM Security Verify アプリを使った設定手順を紹介します。

なお Github の２段階認証を有効にするには、ここで紹介する手順を実行する前に、Github の認証方法をベーシック認証ではなくパーソナルアクセストークン認証に切り替えておく必要があります。そちらの手順については以前のブログエントリを参照してください：
Github のベーシック認証が利用できなくなる前にパーソナルアクセストークンに対応する


【Github の２段階認証対応】
今回は IBM Security Verify アプリを使った Github の２段階認証対応手順を紹介します。まず iPhone や Android スマホでストアアプリを起動し、"IBM Security Verify" を検索して該当アプリをインストールします（無料です）：



そして起動します。下図は初回起動直後の画面です。この時点ではまだどのサービスとも連携できていないので、「アカウントの接続」ボタンが表示されます。このボタンをタップします：



「コンピュータの QR コードをスキャンしてください」というメッセージが表示されます。この後 Github と連携するための QR コード読み取りを行います。スマホアプリ側はいったんこの状態にしたまま続けて Github 側の作業を行います：



別の PC などで Github にログインし、"Settings" メニューから "Account security" を選択し、２段階認証を有効にするため、画面内の "Enable two-factor authentication" ボタンをタップします：



次の画面で "Set up using an app" ボタンを選択します：



すると以下のようなリカバリーコードが表示されます。リカバリーコードはアカウントにアクセスできなくなった場合に、再びアクセスできるようにするためのコードです。"Download" ボタンを押して内容を保存してから、"Next" ボタンをクリックして先に進みます：



すると以下のように QR コードが表示されます。改めて先程起動したままだったスマホの IBM Security Verify アプリの画面から「QR コードのスキャン」を選択し、起動したカメラでこの QR コードを撮影します：


するとアプリ側は「完了しました」と表示されます。"OK" をクリックします：



Github との接続が完了した様子がわかります。この "Github" 部分をタップします：



すると以下のような画面が表示されます。モザイクになっている箇所にはアクセスコードと呼ばれる６桁の数字が表示されており、約30秒ごとに異なる値に変更されます：



この数字が変更になる前に Github 画面内の QR コード下部に６桁の数字を入力して、"Enable" ボタンをクリックします（作業途中で数字が切り替わってしまった場合、その６桁の数字は無効です。改めて有効な数字を入力して、切り替わる前に "Enable" ボタンを押してください）：



これで IBM Security Verify アプリを使った Github の２段階認証が有効になりました：



うまく設定できているか、動作確認をしてみます。この状態で PC の Github からサインアウトし、再びサインインします：



するとパスワード入力後に２段階認証のコード入力画面に切り替わります：



スマホにインストールした IBM Security Verify アプリを起動して、先程と同様に Github アカウントを選択すると６桁の認証コードが表示されています：



入力期限が切れる前にこの６桁の数字を正しく入力して "Verify" ボタンをクリックするとログインできます：







 

タグ ：

#ibm

#security

#verify

#github

#twofactor

#authentication

Github の認証ルールが変わったらしく、最終的には 2021 年 8 月 13 日からベーシック認証を用いた利用ができなくなるようです：
Token authentication requirements for Git operations


普段から Github は頻繁に使っていて、しかも現在はベーシック認証中心に使っていました。突然利用できなくなると困るので、早めの対策を取っておきました。その手順を紹介します。　また合わせて Github の２段階認証を利用すべく、IBM Security Verify アプリを使った２段階認証対応手順を紹介します。

【Github のパーソナルアクセストークン認証】
Github のベーシック認証の利用ができなくなる前にパーソナルアクセストークンと呼ばれるトークンを使った認証に切り替える必要があります。まずはその手順を紹介します。

Github ページにログインし、画面右上のアイコンをクリックして "Settings" を選択します：



プロフィールページが表示されるので、画面左のサイドメニューから "Developer settings" を選択します：



開発者向け設定ページが表示されます。ここでも画面左のサイドメニューから "Personal access tokens" を選択します：



設定済みのパーソナルアクセストークン一覧画面が表示されます。新しいパーソナルアクセストークンを作成するために "Generate new token" を選択します：



新たに作成するパーソナルアクセストークンの説明（名前）を Note に入力し、スコープは全てにチェックを入れます：



最後に "Generate token" ボタンをクリックしてパーソナルアクセストークンを作成します：



新しいパーソナルアクセストークンが生成されました。このトークン文字列はこの作成直後のタイミングのみ表示されます（別のページに推移したら２度と表示できません）。このタイミングでコピーするなどして値を保存しておくことを推奨します：



これでパーソナルアクセストークンを生成することができました。これ以降で git push するなど認証が必要になった場合は、ID としてユーザー名、パスワードとして（これまでのログインパスワードではなく）パーソナルアクセストークン文字列を指定して認証することができるようになります。また 2021 年 8 月 13 日以降は（ベーシック認証が利用できなくなるため）このパーソナルアクセストークン文字列を使った認証のみがサポートされるようになります：



【Github の２段階認証】
記事を分けて紹介することにしました。こちらを参照ください：
IBM Security Verify アプリを使って Github の２段階認証を設定する

タグ ：

#github

#ibm

#security

#verify

#personal

#access

#token