カテゴリー: 技術メモ1

ある商品を探していたのだが、迂闊にも詐欺サイトのカートをポチってしまった。 届いた確認メールが突っ込みどころ満載だったのでそのサイトの模倣元に確認して事なきを得たが、住所と電話番号と氏名を抜かれてしまった。 あれ、自分はITで食ってるんじゃなかったか？詐欺サイトにハマるなんて...。 と疑心暗鬼になった。せっかくなのでブログのネタにしてみる。 実は技術的にこのサイトの秘密を暴いてみようと思ったのだが、 それ自体が不正アクセス禁止法に触れるため載せられないことが判明した。 詐欺サイト自体のセキュリティは緩かった。 サイトの特徴 アパレルのECサイトです。模倣元の子サービスという設定。 リテラシが比較的高くない女性向けだと思います。 市場価格から適度に格安。明らかにパチもんという設定ではない、 楽天との関係を装っています。 かなり精巧に模倣されているが、致命的な抜けがあります。例えば... ドメインが怪しい 特定商取引法の掲示がない 模倣サイトの子サービスの扱いなのに模倣サイトの電話番号がない スマホからだとポチるかも... 誤解を恐れずに言うならば詰めが甘い。もっとできるはず。 なお、情報の少ないスマホ経由だとかなりキワドい。 実質的にはスマホから流入して軽くポチッた人が被害にあっていそうだ。 確認メール おそらくチャイナだろう。日本語がメチャクチャ。詰めが甘いんだよな。 大多数の日本人はここで止まると思う。実質的には個人情報を抜く目的なのかもしれない。 ゆうちょ銀行の口座番号に振り込めと来た。 偽サイトを見つけたら 金銭的な被害がないので警察も動かないでしょう。 100円とか振り込んで相手方の様子を見て遊ぶのも面白いかもしれません。 七面倒臭い展開が待っていると思うのでやりませんがｗ 出来ることなんて以下ぐらい。 模倣元に偽サイトか否かの確認と事実の報告 振込先金融機関に口座番号が詐欺サイトに使われていることの報告 どういう仕組みで実行犯は金融機関の口座を取得し利用できているのだろうか。 恐らく善良な市民の口座がハックされ犯罪に使われているのだろうが、 そのあたりは知らない方が身のためだと思うので詮索は終わります。 もし実被害が出た場合、警察は指定口座から実行犯を割り出すことができるのだろうか。 公権力はどこまで力を持っているのか興味はあります。興味だけです。 実はもっと技術的に解析を試みたのだが、いくら相手が犯罪者とはいえ、 不正アクセス防止法を犯す行為をネットに晒すことは社会人として許されることはないから書かない。 セキュリティ的に無防備なサーバが存在し、どういう訳がそこで今回のような模倣サイトが運営されていた。 やり得な世界が広がっている事実に寒気がした。

標題の通りなのですが。AESなんて枯れてるんだから鍵長と暗号モードを合わせれば出来るだろうと、軽く見積もってました。結果、無茶苦茶頑張ってみましたが出来ませんでした！ 結論から先に書くと、以下の方法で逃げました。 PythonでEncrypt/Decrypt Classを書く Python側からは上記のClassをそのまま使う 上記のClassを叩くPythonスクリプトを書き、PHPからシェル経由でそのスクリプトを実行する。 もっと頑張れば道が見つかったかもしれませんが、本当にPython/PHPをクロスして暗号化/復号の対ができるのか心配になって、これに落ち着きました。 出来ない理由.. 正直出来ない理由もハッキリしません。 だいたいどちらでも以下ぐらいは設定できるものなのですが、以下を合わせたぐらいでは片方で暗号化したものを復号することができません。 鍵長=256bit Cypher Algorythm=Rijndael 暗号モード=ECB orCBC まともな暗号処理をするには暗号モードにECBは使えずInitialVector(IV)を与える必要があるのですが、乱数からIVを生成する箇所の共通性が怪しかったり、Python側では共通鍵の鍵長にAPIで制限がかかるものの、PHPでは任意に指定できたり、本当に実装すると突っ込みどころ満載になります。 Pythonのコードはだいたい以下のような感じになります(IVを共有するためにダイジェストにIVを含んでいるのは本質的でないので除いてみてください）。 PythonのCrypto.Cipherは Encryptした結果を自力でPaddingしてBase64エンコードしてますが、PHPのmdecryptはいきなりPrintableな文字列を要求します。普通に考えて、PHPのmdecryptがBase64デコードして同じようにPaddingを取り除くのを期待するのはナンセンスでしょ。 import base64 from Crypto import Random from Crypto.Cipher import AES class AESCipher(object): def __init__(self, key, block_size=32): self.bs = block_size if len(key) >= len(str(block_size)): self.key = key[:block_size] else: self.key = self._pad(key) def encrypt(self, raw): raw = self._pad(raw) iv = Random.new().read(AES.block_size) cipher = AES.new(self.key, AES.MODE_CBC, iv) return base64.b64encode(iv + cipher.encrypt(raw)) def decrypt(self, enc): enc = base64.b64decode(enc) iv = enc[:AES.block_size] cipher = AES.new(self.key, AES.MODE_CBC, iv) return self._unpad(cipher.decrypt(enc[AES.block_size:])) def _pad(self, s): return s + (self.bs - len(s) % self.bs) * chr(self.bs - len(s) % self.bs) def _unpad(self, s): return s[:-ord(s[len(s)-1:])] 気付いたこと 何か勘違いしているかもしれませんが、早々に別の道に進みました。

PSR-4の一次情報を読んだことだし、現在の理解でPSR-4 Autoloadに対応したクラスを作成し実際にAutoloadしてみる。composerもPSR-4に対応しているが、まずはPHP-Figがサンプルとして公開しているspl_autoloaderを使った例を試すことにする。 仕様は以下の通り。 Fully qualified class name ikutyexamplePsr4HelloWorld Namespace Prefix ikutyexamplePsr4 Base Directory ./src/ikuty/example/Psr4 Resulting file path ./src/ikuty/example/Psr4/helloworld.php サンプルクラスの作成 ./src/ikuty/example/Psr4/helloworld.phpを以下の通り作成する。 $ pwd ./src/ikuty/example/Psr4 vi helloworld.php <?php namespace ikutyexamplePsr4; class HelloWorld { public function __construct() { echo \"Hello World!\"; } public function say() { echo \"Hello World!\"; } } 呼出側の作成(PSR-0的) PHP Figにあるクロージャ版spl_autoloaderを使った実装例を試してみる。 ikutyexamplePsr4HelloWorldをnew()すると、spl_autoload_registerで登録したクロージャが評価される。 なお、名前空間の深さとBaseDirectoryの深さ等しくしている意味でPSR-0的なサンプル。 [sample.php] <?php 2 spl_autoload_register(function ($class){ 3 4 //project-specific namespace prefix 5 $prefix = \'ikuty\\example\\Psr4\\\'; 6 7 //base directory for the namespace prefix 8 $base_dir = __DIR__ . \'/src/ikuty/example/Psr4/\'; 9 10 //does the class use the namespace prefix? 11 $len = strlen($prefix); 12 if (strncmp($prefix, $class, $len) !== 0){ 13 // no, move to the next registerd autoloader 14 return; 15 } 16 17 //get the relative class name 18 $relative_class = substr($class, $len); 19 20 //replace the namespace prefix with the base directory, replace namespace 21 //separators with directory separators in the relative class name, append 22 //with .php 23 $file = $base_dir . str_replace(\'\\\',\'/\', $relative_class).\'.php\'; 24 25 //if the file exists, require it 26 if (file_exists($file)) { 27 require $file; 28 } 29 30 }); 31 32 $example = new ikutyexamplePsr4HelloWorld(); 33 $example->say(); 名前空間プレフィックスとBaseDirectoryの紐づけは結局人力でやっている。「名前空間プレフィックス」と「クラス名」の間にある「サブ名前空間」を読み飛ばしている。名前空間プレフィックスに続く「サブ名前空間」分をクラス側が自由に使えるところが興味深い。 実行結果 実行してみる。実行結果から分かりにくくて恐縮だが、new()してもHello World!は出力されず、say()メソッドを実行したときにHello World!が2回表示された。late-binding的な感じ。 $ php sample.php Hello World!Hello World! 名前空間の深さと関係なくBaseDirectoryを設定する(PSR-4的) 例えば、ikutyexamplePsr4HelloWorldの名前空間プレフィックスikutyexamplePsr4をBaseDirectory ./ikuty-example-psr4 に紐づければ、名前空間がどれだけ深くてもデプロイは影響を受けない。 Fully qualified class name ikutyexamplePsr4HelloWorld Namespace Prefix ikutyexamplePsr4 Base Directory ./src/ikuty-example-Psr4 Resulting file path ./src/ikuty-example-Psr4/helloworld.php <?php 2 spl_autoload_register(function ($class){ 3 4 //project-specific namespace prefix 5 $prefix = \'ikuty\\example\\Psr4\\\'; 6 7 //base directory for the namespace prefix 8 //$base_dir = __DIR__ . \'/src/ikuty/example/Psr4/\'; 9 $base_dir = __DIR__ . \'/src-ikuty-example-psr4/\'; 10 11 12 //does the class use the namespace prefix? 13 $len = strlen($prefix); 14 if (strncmp($prefix, $class, $len) !== 0){ 15 // no, move to the next registerd autoloader 16 return; 17 } 18 19 //get the relative class name 20 $relative_class = substr($class, $len); 21 22 //replace the namespace prefix with the base directory, replace namespace 23 //separators with directory separators in the relative class name, append 24 //with .php 25 $file = $base_dir . str_replace(\'\\\',\'/\', $relative_class).\'.php\'; 26 27 //if the file exists, require it 28 if (file_exists($file)) { 29 require $file; 30 } 31 32 }); 33 34 $example = new ikutyexamplePsr4HelloWorld(); 35 $example->say(); 結論 PHP-Figがサンプルとして提供しているspl_autoloader(クロージャ版)をお試し実装してみた。 PSR-4は名前空間プレフィックスのベースディレクトリの関連を記述する仕様であり、ベースディレクトリの物理的な配置が名前空間プレフィックスに直接影響を受けない。 ベースディレクトリが深くならなくて良い

フォームのビジネスロジック（検証や保存）をコントローラに書くと、どうでも良いコードでコントローラが重くなってくる。フォームが複数ある場合、だいたい似たり寄ったりのコードが量産されていく。本エントリでは、Laravel5 の Form Request Validation によってコントローラからバリデーションロジックを完全分離する方法について記述する。 Form Request Validation - バリデーションの分離 流れは以下の通り。 AppHttpRequestsRequestクラスを派生し、ContactRequestクラスを作成する。 コントローラメソッドにて、AppHttpRequestsRequestクラスのインスタンスではなく ContractRequestクラスのインスタンスを受けるようにする。 コントローラメソッドに入ったときには既にContactRequestクラスによるバリデーションが完了していて、データが正しい前提で処理できる。 ContactRequestクラス、ContactRequestTraitクラスの例を以下に示す。 <?php namespace AppHttpRequests; class ContactRequest extends Request { use ConfirmRequestTrait; /** * Determine if the user is authorized to make this request. * * @return bool */ public function authorize() { return true; } /** * Get the validation rules that apply to the request. * * @return array */ public function rules() { return [ \'name\' => \'required\', \'email\' => \'required|email\', \'subject\' => \'required\', \'content\' => \'required\', ]; } /** * Set custom messages for validator errors. * * @return array */ public function messages() { return [ // ]; } /** * Set custom attributes for validator errors. * * @return array */ public function attributes() { return [ \'name\' => \'お名前\', \'email\' => \'メールアドレス\', \'subject\' => \'件名\', \'content\' => \'内容\', ]; } } <?php namespace AppHttpRequests; use IlluminateContractsValidationValidator; trait ConfirmRequestTrait { /** * Set custom messages for validator errors. * * @param IlluminateContractsValidationFactory $factory * * @return IlluminateContractsValidationValidator */ public function validator($factory) { // 値検証前の処理 if (method_exists($this, \'beforeValidate\')) { $this->beforeValidate(); } $validator = $factory->make( $this->all(), $rules, $this->messages(), $this->attributes() ); $validator->after(function ($validator) { $failed = $validator->failed(); // 値検証後の処理 if (method_exists($this, \'afterValidate\')) { $this->afterValidate($validator); } }); return $validator; } /** * Format the errors from the given Validator instance. * * @param IlluminateContractsValidationValidator $validator * * @return array */ protected function formatErrors(Validator $validator) { $errors = parent::formatErrors($validator); return $errors; } } Form Request Validation - コントローラ側 ポイントは、storeメソッドの引数に ContactRequestヒントが渡されていること。sotreメソッドに入る前にContactRequestによりバリデーションが実行され、バリデーションに成功した時に限り、sotre()メソッドに入る。バリデーションが失敗すると、その前のアドレスにリダイレクトされる。コントローラから一切のバリデーションロジックを排除できた。 <?php namespace App¥Http¥Controllers; use App¥Http¥Requests¥ContactRequest; use App¥Repositories¥ContactRepository; class ContactController extends Controller { /** /* @var ContactRepository */ protected $repository; /** /* @constructor /* param ContactRepository $repository */ public function __construct(ContactRepository $repository) { $this->repository = $repository; } /* * */ public function index() { ... } /** * @var ContactRequest $request * */ public function store(ContactRequest $request) { } }

What\'s PSR-4 ? そもそもPSRって何の略だろうと調べたがそこから出てこなかった。 ↓なんじゃないか、という意見あり。 PHP Standard Recommendation PHP Specification Request カテゴリ毎に数字が割り当てられており他にも以下が存在する。 PSR-0 Autoloading PSR-1 Basic Coding Standard PSR-2 Coding Style Guide PSR-3 Logger Interface PSR-4 Improved Autoloading PSR-6 Chaching Interface PSR-7 HTTP Message Interface PHP-FIGという団体で取りまとめられている。http://www.php-fig.org/ PSR-4 それでは早速一次情報から漁ってみる。どのパスにどのクラスを配置するのか仕様を決めたいというのが根っこにある。決まりがあればクラスを使う側が楽だから。楽に使ってもらえるよう配布手段に規約を設ける。PSR-0(等?)と互換性がある。(PSR-0以外にもこういう決まりがあるのか？) This PSR describes a specification for autoloading classes from file paths. It is fully interoperable, and can be used in addition to any other autoloading specification, including PSR-0. This PSR also describes where to place files that will be autoloaded according to the specification. 仕様 言葉遊び ドキュメント内では\"class\"は class,interfaces,traits,それに似た構造を指すそうだ。あくまでも外部から使用する対象と配置に関する仕様だよ、ということだ。対象は何でも良い。 The term \"class\" refers to classes, interfaces, traits, and other similar structures. 完全修飾クラス名 完全修飾クラス名は次のような形式となるそうだ。 A fully qualified class name has the following form: \<NamespaceName>(<SubNamespaceNames>)*<ClassName> いくつか決まり事がある。 The fully qualified class name MUST have a top-level namespace name, also known as a \"vendor namespace\". 完全修飾クラス名にはベンダーを表すユニークな名前空間が入っていないといけない。 NamespaceNameが一意なのか、NamespaceNameとSubNamespaceNamesの合わせ技で一意なのか不明。 GitHubに上がってるのを見るとNamespaceNameだけで表現しているようだ。「トップレベル」って「一番最初=NamespaceName」のことか？？ The fully qualified class name MAY have one or more sub-namespace names. 補助的に名前空間を複数追加しても良い。 階層構造を持った複雑な名前空間も定義できるということ。 The fully qualified class name MUST have a terminating class name. 完全修飾クラス名の最後はクラス名でなければならない。 Underscores have no special meaning in any portion of the fully qualified class name. アンスコは特別な意味を持たない。 アンスコを前後の識別子の接続子のように使うフレームワークが多いからね。 アンスコは単なる文字。 Alphabetic characters in the fully qualified class name MAY be any combination of lower case and upper case. 大文字小文字の任意の組み合わせで良い。 大文字小文字に意味を持たせるフレームワークが多いからね。 All class names MUST be referenced in a case-sensitive fashion. 大文字小文字を区別する。 ファイルをロードする側の決まりごと A contiguous series of one or more leading namespace and sub-namespace names, not including the leading namespace separator, in the fully qualified class name (a \"namespace prefix\") corresponds to at least one \"base directory\". NamespaceNameといくつかのSubNamespaceNameを「名前空間プレフィックス」と呼ぶ SubNamespaceNameが複数個あった場合その全てが「名前空間プレフィックス」になるとは読めない。 完全修飾クラス名とは「名前空間プレフィックス」+(「サブ名前空間」)+「クラス名」となる。 「名前空間プレフィックス」がディレクトリ名と対応している必要がある。と書いてあるがサンプルの「BaseDirectory」が名前空間プレフィックスと全然違う。意味不明。 The contiguous sub-namespace names after the \"namespace prefix\" correspond to a subdirectory within a \"base directory\", in which the namespace separators represent directory separators. The subdirectory name MUST match the case of the sub-namespace names. 名前空間プレフィックスに続くサブ名前空間が、BaseDirectoryに続くサブディレクトリに対応する。 サブ名前空間とサブディレクトリの大文字小文字は一致している必要がある。 The terminating class name corresponds to a file name ending in .php. The file name MUST match the case of the terminating class name. 終端のクラス名は、大文字小文字が一致するphpファイルと対応する。 例 PSR-4の例。やはり、どうも規則性が見えない。 FULLY QUALIFIED CLASS NAME NAMESPACE PREFIX BASE DIRECTORY RESULTING FILE PATH AcmeLogWriterFile_Writer AcmeLogWriter ./acme-log-writer/lib/ ./acme-log-writer/lib/File_Writer.php AuraWebResponseStatus AuraWeb /path/to/aura-web/src/ /path/to/aura-web/src/Response/Status.php SymfonyCoreRequest SymfonyCore ./vendor/Symfony/Core/ ./vendor/Symfony/Core/Request.php ZendAcl Zend /usr/includes/Zend/ /usr/includes/Zend/Acl.php 全然規則性が見えないぞ？ 全然しっくりこないのでさらに調べてみた。COMPOSERがだいぶ前にPSR-4に対応したらしいのでAUTOLOADの補完ルールを色分けした。を参考にさせて頂きました。 FULLY QUALIFIED CLASS NAME NAMESPACE PREFIX BASE DIRECTORY RESULTING FILE PATH AcmeLogWriterFile_Writer AcmeLogWriter ./acme-log-writer/lib/ ./acme-log-writer/lib/File_Writer.php AuraWebResponseStatus AuraWeb /path/to/aura-web/src/ /path/to/aura-web/src/Response/Status.php SymfonyCoreRequest SymfonyCore ./vendor/Symfony/Core/ ./vendor/Symfony/Core/Request.php ZendAcl Zend /usr/includes/Zend/ /usr/includes/Zend/Acl.php 訳にも書いたが、全てのサブ名前空間が名前空間プレフィックスに含まれる訳ではないことに注意。名前空間プレフィックスに含まれなかったサブ名前空間が突然ファイルパスに出現したりする。 サブ名前空間とBaseDirectoryの規則性について、サブ名前空間をハイフンで区切った一つのディレクトリと対応させる場合もあるし、階層構造まで一致させる場合もある。名前空間プレフィックスとBase Directoryの関係性は割と柔軟。

今後も何度か同じことを調べそうなので忘備録としてまとめておく。手順をstep by stepで記述するが、それぞれ分量が多いので以下の通り章立てを行ってエントリを分割する。 VPC構築編 VPCの作成 VPC、NetworkACL、SecurityGroupの確認、タグ付け VPCのDNSホスト名を有効にする サブネットの作成、タグ付け インターネットゲートウェイの作成、タグ付け、VPCにアタッチ パブリックサブネット用RoutingTableの作成 パブリックサブネット用RoutingTableにインターネットゲートウェイの関連付け 作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる RDS構築編 MySQLの設定変更(DBパラメータグループの作成) DBサブネットグループを作成 RDS用セキュリティグループの作成 RDSインスタンスの作成 エンドポイントの確認、疎通確認 Elastic Beanstalk構築編 環境の構築 .ebextensionsによるカスタマイズ Laravel5アプリデプロイ編(本エントリ) gitリポジトリからclone .envの編集 アプリで使うDBのダンプファイルをRDSにコピー Laravelインストーラの準備 Laravel本体のインストール ビルトインサーバでの疎通確認 Elastic Beanstalkへのデプロイ gitリポジトリからclone 通常 Laravel5 にはデフォルトの .gitignore が作られており、Laravel本体は.gitignoreに登録されている。まず、アプリをcloneし、そのあとでLaravel本体をインストールする。 どこか、Laravel5の要件を満たすところでgitリポジトリからcloneする。 $ pwd /home/ikuty/www/ $ git clone ssh://servername/var/git/project.git project .envの編集 アプリケーションの設定を変更する。/config 内に各種設定ファイルが配置されているが、laravelでは.envを変更することで /config内のenv()関数に展開される仕組みになっている。だから、/config 内の各種ファイルを直接変更する必要はない。/config 内も git の構成管理に含めても良い。 cloneした先でenvを編集する。.env_example をリネームすると楽。 APP_KEY= *** 次項で示すようにキーを生成する DB_HOST : RDS編で設定したRDSエンドポイントを指定する DB_DATABASE, USERNAME, PASSWORD : RDS編で設定した各種設定を指定する APP_ENV=local APP_DEBUG=true APP_KEY=**** APP_URL=http://hoge.com/ DB_CONNECTION=mysql DB_HOST=rds-endpoint DB_PORT=3306 DB_DATABASE=hogedb DB_USERNAME=hoge DB_PASSWORD=fuga CACHE_DRIVER=file SESSION_DRIVER=file QUEUE_DRIVER=sync キーを生成する。以下のコマンドで .env の APP_KEY が差し替わる。 $ php artisan key:generate アプリで使うDBのダンプファイルをRDSにコピー 本来は Migration を使うべきだが...。Migration を利用しないでDBを作ってしまった場合は泥臭くやる...;;まず、ダンプ。 $ mysqldump -u hoge -p appdb > appdb.sql RDS側にDBを作成し権限を付与しておく。 $ mysql -h [rds-endpoint] -u hoge -p $ > CREATE DATABSE appdb; $ > GRANT ALL ON appdb.* to hoge@localhost; $ > FLUSH PRIVILEGES; $ > SHOW DATABSES; $ > ... RDS上のDBにダンプしたsqlを流し込む。 $ mysql -h [rds-endpoint] -u hoge -p -D appdb < appdb.sql Laravelインストーラの準備 composerを利用する。パスを通す。本エントリ作成時の最新は version1.3.3。 $ composer global require \"laravel/installer=~1.1\" $ echo \'export PATH=~/.composer/vendor/laravel/installer:$PATH\' >> ~/.bash_profile $ source .bash_profile $ laravel Laravel Installer version 1.3.3 Laravel本体のインストール composerが準備できたらcomposer installでLaravel本体をインストールする。 $ cd project $ composer install ビルトインサーバでの疎通確認 この状態でビルトインサーバを立ち上げ、疎通確認を行う。 $ cd project php artisan serve --host hoge.com Laravel development server started on http://hoge.com:8000/ Elastic Beanstalkへのデプロイ Elastic Beanstalk構築編にて、環境の準備が出来ているものとする。 eb deploy コマンドにより、カレントディレクトリ以下のファイルをデプロイする。また、.ebextension に DocumentRoot を設定する。カレントディレクトリと DocumentRoot の組み合わせを正しく設定する必要がある。 まず、DocumentRootを設定するため、.ebextensionディレクトリを作成し、設定ファイルを作成する。 $ pwd /home/ikuty/www/ $ mkdir .ebextensions $ cd .ebextensions $ vi 01_documentroot.config 01.documentroot_config は以下の通り。YAMLとして記述する必要がある。空白とタブの扱いがシビアなので、タブが入らないように注意する。ファイルの先頭の\"01\" は、ファイルが解釈される順番を表す。.ebextensions 内に、01,02,... のように設定を複数配置できる。 option_settings: - namespace: aws:elasticbeanstalk:container:php:phpini option_name: document_root value: /project/public DocumentRoot を /project/public と設定した場合に正しい構成になるように、カレントディレクトリを移動し、eb deployを実行する。~/www に移動して、/project 以下をデプロイすれば良い。 $ cd ~/www/ $ eb deploy Creating application version archive \"app-160630_130423\". Uploading: [##################################################] 100% Done... INFO: Environment update is starting. INFO: Deploying new version to instance(s). INFO: New application version was deployed to running EC2 instances. INFO: Environment update completed successfully. 設定が正しければ2分弱で完了する。

今後も何度か同じことを調べそうなので忘備録としてまとめておく。手順をstep by stepで記述するが、それぞれ分量が多いので以下の通り章立てを行ってエントリを分割する。 VPC構築編 VPCの作成 VPC、NetworkACL、SecurityGroupの確認、タグ付け VPCのDNSホスト名を有効にする サブネットの作成、タグ付け インターネットゲートウェイの作成、タグ付け、VPCにアタッチ パブリックサブネット用RoutingTableの作成 パブリックサブネット用RoutingTableにインターネットゲートウェイの関連付け 作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる RDS構築編 MySQLの設定変更(DBパラメータグループの作成) DBサブネットグループを作成 RDS用セキュリティグループの作成 RDSインスタンスの作成 エンドポイントの確認、疎通確認 Elastic Beanstalk構築編(本エントリ) 環境の構築 .ebextensionsによるカスタマイズ Laravel5アプリデプロイ編 gitリポジトリからclone .envの編集 アプリで使うDBのダンプファイルをRDSにコピー Laravelインストーラの準備 Laravel本体のインストール ビルトインサーバでの疎通確認 Elastic Beanstalkへのデプロイ 環境の構築 Elastic Beanstalk の各インスタンスを収める「環境」を作成する。この「環境」の中に、これまで作ってきたVPCの要素を追加する。 $ eb create hoge-production --sample　# アプリケーションのデプロイは後で行う。今はSampleアプリケーションをデプロイ --cname com-sample-production --instance_type t2.micro --region ap-northeast-1 --tier webserver --vpc.ec2subnets subnet-b71eeac1 #VPCに作成したパブリックサブネット --vpc.elbsubnets subnet-b71eeac1 #VPCに作成したパブリックサブネット(同じにする) --vpc.id vpc-cc2b11a9 --vpc.securitygroups sg-23fe8447 #デフォルトセキュリティグループ --vpc.publicip --vpc.elbpublic 3分から5分程度時間を要する。 作成した環境のURLを開く $eb open http://com-sample-production.ap-northeast-1.elasticbeanstalk.com/ .ebextensionsによるカスタマイズ Laravel5アプリケーションをデプロイするにあたって、環境をカスタマイズする。(qiitaを参考にした） $ pwd /home/ikuty/www $ mkdir .ebextensions $ cd .ebextensions # timezoneを変更する vi 01_settimezone.config 各ファイルは以下の通り。なお、各ファイルは yaml形式であり、空白とタブの扱いがシビア。タブでインデントすると簡単に謎のエラーに悩まされる。空文字はタブではなく半角スペース。 01_settimezone.config command: 01-set_timezone: command: cp /usr/share/zoneinfo/Japan /etc/localtime

今後も何度か同じことを調べそうなので忘備録としてまとめておく。手順をstep by stepで記述するが、それぞれ分量が多いので以下の通り章立てを行ってエントリを分割する。 VPC構築編 VPCの作成 VPC、NetworkACL、SecurityGroupの確認、タグ付け VPCのDNSホスト名を有効にする サブネットの作成、タグ付け インターネットゲートウェイの作成、タグ付け、VPCにアタッチ パブリックサブネット用RoutingTableの作成 パブリックサブネット用RoutingTableにインターネットゲートウェイの関連付け 作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる RDS構築編(本エントリ) MySQLの設定変更(DBパラメータグループの作成) DBサブネットグループを作成 RDS用セキュリティグループの作成 RDSインスタンスの作成 エンドポイントの確認、疎通確認 Elastic Beanstalk構築編 環境の構築 .ebextensionsによるカスタマイズ Laravel5アプリデプロイ編 gitリポジトリからclone .envの編集 アプリで使うDBのダンプファイルをRDSにコピー Laravelインストーラの準備 Laravel本体のインストール ビルトインサーバでの疎通確認 Elastic Beanstalkへのデプロイ MySQLの設定変更 my.cnf等のコンフィグファイルに記述していた内容をRDS風に記述する。RDSでは「DBパラメータ」に設定を記述していく。まず、DBパラメータを作成する。 $ aws rds create-db-parameter-group --db-parameter-group-name mydbparamgroup --db-parameter-group-family mysql5.6 --description \"public rds\" { \"DBParameterGroup\": { \"DBParameterGroupName\": \"mydbparamgroup\", \"DBParameterGroupFamily\": \"mysql5.6\", \"Description\": \"public rds\" } } 文字コード関連の設定 $ aws rds modify-db-parameter-group --db-parameter-group-name --parameters ParameterName=character_set_client,ParameterValue=utf8mb4,ApplyMethod=immediate ParameterName=character_set_connection,ParameterValue=utf8mb4,ApplyMethod=immediate ParameterName=character_set_database,ParameterValue=utf8mb4,ApplyMethod=immediate ParameterName=character_set_results,ParameterValue=utf8mb4,ApplyMethod=immediate ParameterName=character_set_server,ParameterValue=utf8mb4,ApplyMethod=immediate ParameterName=collation_connection,ParameterValue=utf8mb4_general_ci,ApplyMethod=immediate ParameterName=collation_server,ParameterValue=utf8mb4_general_ci,ApplyMethod=immediate ParameterName=skip-character-set-client-handshake,ParameterValue=0,ApplyMethod=pending-reboot init_connectパラメータの設定。デフォルトの設定をファイルに落とし、ファイルを変更する。 $ aws rds modify-db-parameter-group --generate-cli-skeleton > init_connect.json # 変更後 $ cat init_connect.json { \"DBParameterGroupName\": \"\", \"Parameters\": [ { \"ParameterName\": \"\", \"ParameterValue\": \"\", \"Description\": \"\", \"Source\": \"\", \"ApplyType\": \"\", \"DataType\": \"\", \"AllowedValues\": \"\", \"IsModifiable\": true, \"MinimumEngineVersion\": \"\", \"ApplyMethod\": \"\" } ] } # 出力された設定ファイルを変更する $ vi init_connect.json # 変更内容は以下の通り $ cat init_connect.json { \"DBParameterGroupName\": \"mydbparamgroup\", \"Parameters\": [ { \"ParameterName\": \"init_connect\", \"ParameterValue\": \"SET SESSION time_zone = CASE WHEN POSITION(\'rds\' IN CURRENT_USER()) = 1 THEN \'UTC\' ELSE \'Asia/Tokyo\' END;\", \"Description\": \"\", \"Source\": \"\", \"ApplyType\": \"\", \"DataType\": \"\", \"AllowedValues\": \"\", \"IsModifiable\": true, \"MinimumEngineVersion\": \"\", \"ApplyMethod\": \"immediate\" } ] } # 設定ファイルを読み込む $ aws rds modify-db-parameter-group --cli-input-json file://init_connect.json { \"DBParameterGroupName\": \"mydbparamgroup\" } DBサブネットグループを作成 DB構築編にてAvailabilityZoneが異なるDB用サブネットを2個作成した。それぞれID/tagは\"subnet-131feb65\"/\"subnet public db1\"、\"subnet-d6d2d38f\"/\"subnet public db2\"であった。 DB サブネットグループmydbsubnetgroupを作成する。 aws rds create-db-subnet-group --db-subnet-group-name mydbsubnetgroup --db-subnet-group-description \"DB SubnetGroup for RDS Instance\" --subnet-ids subnet-131feb65 subnet-d6d2d38f { \"DBSubnetGroup\": { \"Subnets\": [ { \"SubnetStatus\": \"Active\", \"SubnetIdentifier\": \"subnet-131feb65\", \"SubnetAvailabilityZone\": { \"Name\": \"ap-northeast-1a\" } }, { \"SubnetStatus\": \"Active\", \"SubnetIdentifier\": \"subnet-d6d2d38f\", \"SubnetAvailabilityZone\": { \"Name\": \"ap-northeast-1c\" } } ], \"DBSubnetGroupName\": \"mydbsubnetgroup\", \"VpcId\": \"vpc-cc2b11a9\", \"DBSubnetGroupDescription\": \"DB SubnetGroup for RDS Instance\", \"SubnetGroupStatus\": \"Complete\" } } RDS用セキュリティグループの作成 RDS用セキュリティグループ myrds を作成する。 $ aws ec2 create-security-group --group-name myrds --description \"RDS security group\" --vpc-id vpc-cc2b11a9 { \"GroupId\": \"sg-b50742d1\" } #タグ付け $ aws ec2 create-tags --resources sg-b50742d1 --tags Key=Name,Value=\"sg rds\" RDS MySQLにVPCから接続するために、RDS用セキュリティグループに3306からのInbound許可設定を行う。(作成済のVPCセキュリティグループのIDはsg-73490c17。) $ aws ec2 authorize-security-group-ingress --group-id sg-b50742d1 --protocol tcp --port 3306 --source-group sg-73490c17 [参考] 下記のようにCIDR標記のアドレスを指定するとVPCの外部からも接続可能になる。 $ aws ec2 authorize-security-group-ingress --group-id sg-b50742d1 --protocol tcp --port 3306 --cidr 0.0.0.0/0 RDSインスタンスの作成 DBパラメータグループ、デフォルトセキュリティグループ、RDS用セキュリティグループを指定する。 外部からの接続を許可する場合 -- publicly-accessible　を指定する必要がある。 $ aws rds create-db-instance --db-instance-identifier hogedb --allocated-storage 5 --db-instance-class db.t2.micro --engine MySQL --engine-version 5.6.22 --master-username hoge --master-user-password fuga --db-name hogedb --db-parameter-group-name mydbparamgroup --db-subnet-group-name mydbsubnetgroup --vpc-security-group-ids sg-23fe8447 sg-b50742d1 --storage-type standard --availability-zone ap-northeast-1a --no-multi-az --region ap-northeast-1 --publicly-accessible --no-auto-minor-version-upgrade 疎通確認 エンドポイントを確認する。予めjqコマンドを利用可能にしておくこと。 # jqがない場合 $ sudo yum install jq $ aws rds describe-db-instances --db-instance-identifier hogedb | jq \'.DBInstances[].Endpoint\' { \"Address\": \"hogedb.c3w6*******5990.ap-northeast-1.rds.amazonaws.com\", \"Port\": 3306 } PublicIp、PublicDnsName を確認する。 $ aws ec2 describe-network-interfaces --filters \"Name=description,Values=RDSNetworkInterface\" { .. \"Description\": \"RDSNetworkInterface\", \"Association\": { \"PublicIp\": \"54.95.100.249\", \"PublicDnsName\": \"ec2-54-92-100-249.ap-northeast-1.compute.amazonaws.com\", \"IpOwnerId\": \"amazon-rds\" }, .. } mysql コマンドでエンドポイントに接続してみる。 $ mysql -h 54.95.100.249 -P 3306 -u hoge -p -D hogedb Enter password: fuga Welcome to the MySQL monitor. Commands end with ; or g. Your MySQL connection id is 9 Server version: 5.6.22-log MySQL Community Server (GPL) Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved. ...

今後も何度か同じことを調べそうなので忘備録としてまとめておく。手順をstep by stepで記述するが、それぞれ分量が多いので以下の通り章立てを行ってエントリを分割する。 VPC構築編(本エントリ) VPCの作成 VPC、NetworkACL、SecurityGroupの確認、タグ付け VPCのDNSホスト名を有効にする サブネットの作成、タグ付け インターネットゲートウェイの作成、タグ付け、VPCにアタッチ パブリックサブネット用RoutingTableの作成 パブリックサブネット用RoutingTableにインターネットゲートウェイの関連付け 作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる RDS構築編 MySQLの設定変更(DBパラメータグループの作成) DBサブネットグループを作成 RDS用セキュリティグループの作成 RDSインスタンスの作成 エンドポイントの確認、疎通確認 Elastic Beanstalk構築編 環境の構築 .ebextensionsによるカスタマイズ Laravel5アプリデプロイ編 gitリポジトリからclone .envの編集 アプリで使うDBのダンプファイルをRDSにコピー Laravelインストーラの準備 Laravel本体のインストール ビルトインサーバでの疎通確認 Elastic Beanstalkへのデプロイ 前提 aws cli, eb-cli をインストールしておくこと。 $ pwd /home/ikuty $ aws --version aws-cli/1.10.37 Python/2.6.6 Linux/2.6.32-573.22.1.el6.x86_64 botocore/1.4.27 $ eb --version EB CLI 3.7.6 (Python 2.7.9) Administrator AccessポリシーをもつユーザをIAMで作成し、aws-cli から該当ユーザの権限で操作できるようにしておくこと。 $ aws configure AWS Access Key ID [****************] AWS Secret Key [***********************] Default region name [ap-northeast-1] Default output format [json] VPCの環境構築 VPCを作成する。アドレスの範囲をCIDR標記で記述する。ネットワーク部を16bit取る。 vpc-cc2b11a9というIDのVPCが作成されたという報告がjsonで戻る。 $ aws ec2 create-vpc --cidr-block 10.0.0.0/16 { \"Vpc\": { \"VpcId\": \"vpc-cc2b11a9\", \"InstanceTenancy\": \"default\", \"State\": \"pending\", \"DhcpOptionsId\": \"dopt-fec65c9b\", \"CidrBlock\": \"10.0.0.0/16\", \"IsDefault\": false } } vpc-cc2b11a9というVPCにNameタグを付与する。 $ aws ec2 create-tags --resources vpc-cc2b11a9 --tags Key=Name,Value=\"vpc\" VPCとは、クラウド上に閉じたネットワークを構築する機能であり、VPC作成時に、閉じたネットワークを構成する要素が同時に生成される。構成要素は以下の通り。 Routing Table Subnet Network ACL Security group なお、Network ACL、Security group について AWS のドキュメントでは以下の通り説明している。 Amazon VPCのネットワークACL（アクセスコントロールリスト）は、サブネット内外のトラフィックを制御するファイアウォールとして任意のセキュリティを提供します。セキュリティグループの設定と同じようにACLのルールを適応することによって、VPCに追加のセキュリティ層を提供します。EC2はサブネット指定ができませんのでネットワークACLを利用することはできません。 なんのこっちゃ、だが、図を見ると一目瞭然である。NetworkACLを使ってサブネット毎にファイアウォールを定義できる！ NetworkACL、SecurityGroupいずれもファイアウォールのように見えるが、以下のような違いがある。 セキュリティグループ ネットワーク ACL インスタンスレベルで動作します（第 1 保護レイヤー） サブネットレベルで動作します（第 2 保護レイヤー） ルールの許可のみがサポートされます ルールの許可と拒否がサポートされます ステートフル: ルールに関係なく、返されたトラフィックが自動的に許可されます ステートレス: 返されたトラフィックがルールによって明示的に許可されます トラフィックを許可するかどうかを決める前に、すべてのルールを評価します トラフィックを許可するかどうかを決めるときに、順番にルールを処理します インスタンスの起動時に誰かがセキュリティグループを指定した場合、または後でセキュリティグループをインスタンスに関連付けた場合にのみ、インスタンスに適用されます。 関連付けられたサブネット内のすべてのインスタンスに自動的に適用されます（バックアップの保護レイヤーなので、セキュリティグループを指定する人物に依存する必要はありません） Routing tableにタグをつける vpc-cc2b11a9というIDを持ったVPCのRouting tableを確認する。rtb-964da5f2というIDを持ったRouting tableを確認できる。 $ aws ec2 describe-route-tables --filters \"Name=vpc-id,Values=vpc-cc2b11a9\" { \"RouteTables\": [ { \"Associations\": [ { \"RouteTableAssociationId\": \"rtbassoc-b2fd42d6\", \"Main\": true, \"RouteTableId\": \"rtb-964da5f2\" } ], \"RouteTableId\": \"rtb-964da5f2\", \"VpcId\": \"vpc-cc2b11a9\", \"PropagatingVgws\": [], \"Tags\": [], \"Routes\": [ { \"GatewayId\": \"local\", \"DestinationCidrBlock\": \"10.0.0.0/16\", \"State\": \"active\", \"Origin\": \"CreateRouteTable\" } ] } ] } $ aws ec2 create-tags --resources rtb-964da5f2 --tags Key=Name,Value=\"rtb main\" NetworkACLにタグをつける $ aws ec2 describe-network-acls --filters \"Name=vpc-id,Values=vpc-cc2b11a9\" { \"NetworkAcls\": [ { \"Associations\": [], \"NetworkAclId\": \"acl-25fb1a41\", \"VpcId\": \"vpc-cc2b11a9\", \"Tags\": [], \"Entries\": [ { \"CidrBlock\": \"0.0.0.0/0\", \"RuleNumber\": 100, \"Protocol\": \"-1\", \"Egress\": true, \"RuleAction\": \"allow\" }, { \"CidrBlock\": \"0.0.0.0/0\", \"RuleNumber\": 32767, \"Protocol\": \"-1\", \"Egress\": true, \"RuleAction\": \"deny\" }, { \"CidrBlock\": \"0.0.0.0/0\", \"RuleNumber\": 100, \"Protocol\": \"-1\", \"Egress\": false, \"RuleAction\": \"allow\" }, { \"CidrBlock\": \"0.0.0.0/0\", \"RuleNumber\": 32767, \"Protocol\": \"-1\", \"Egress\": false, \"RuleAction\": \"deny\" } ], \"IsDefault\": true } ] } $ aws ec2 create-tags --resources acl-25fb1a41 --tags Key=Name,Value=\"acl main\" SecurityGroupにタグをつける SecurityGroupを確認する。ID=sg-23fe8447というSecurityGroupが存在することがわかる。 $ aws ec2 describe-security-groups --filters \"Name=vpc-id,Values=vpc-cc2b11a9\" { \"SecurityGroups\": [ { \"IpPermissionsEgress\": [ { \"IpProtocol\": \"-1\", \"IpRanges\": [ { \"CidrIp\": \"0.0.0.0/0\" } ], \"UserIdGroupPairs\": [], \"PrefixListIds\": [] } ], \"Description\": \"default VPC security group\", \"IpPermissions\": [ { \"IpProtocol\": \"-1\", \"IpRanges\": [], \"UserIdGroupPairs\": [ { \"UserId\": \"281631559249\", \"GroupId\": \"sg-23fe8447\" } ], \"PrefixListIds\": [] } ], \"GroupName\": \"default\", \"VpcId\": \"vpc-cc2b11a9\", \"OwnerId\": \"281631559249\", \"GroupId\": \"sg-23fe8447\" } ] } $ aws ec2 create-tags --resources sg-23fe8447 --tags Key=Name,Value=\"sg main\" VPCのDNSホスト名を有効にする VPC内のRDSに外部から接続できるようにDNSホスト名を有効にする。 #有効にする $ aws ec2 modify-vpc-attribute --vpc-id vpc-cc2b11a9 --enable-dns-hostnames #確認する $ aws ec2 describe-vpc-attribute --vpc-id vpc-cc2b11a9 --attribute enableDnsHostnames { \"VpcId\": \"vpc-cc2b11a9\", \"EnableDnsHostnames\": { \"Value\": true } } サブネットを作成する 最初のVPC作成時に、16ビットをネットワーク部として使う意図で、CIDR標記で/16を設定した。さらに、8ビットをサブネットとして利用するため、CIDR標記で/24を設定する。8ビット分(第３オクテット分)がサブネットとして利用でき、そのうち .0、.1、.2 のサブネットを作成する。第4オクテットがホスト部となるが、8ビット全て利用することはできず、利用できる最大数がそれぞれ\"AvailableIpAddressCount\"に書かれてる。なお、各サブネットにそれぞれIDが振られる。 RDSをMultiAZで運用しない場合でもDBサブネットグループを作成する際に2つのAvailabilityZoneが必要なので異なるAvailabilityZoneに対応するサブネットを作成する。 $ aws ec2 create-subnet --vpc-id vpc-cc2b11a9 --cidr-block 10.0.0.0/24 --availability-zone ap-northeast-1a { \"Subnet\": { \"VpcId\": \"vpc-cc2b11a9\", \"CidrBlock\": \"10.0.0.0/24\", \"State\": \"pending\", \"AvailabilityZone\": \"ap-northeast-1a\", \"SubnetId\": \"subnet-b71eeac1\", \"AvailableIpAddressCount\": 251 } } # ap-northeast-1a AvailabilityZone $ aws ec2 create-subnet --vpc-id vpc-cc2b11a9 --cidr-block 10.0.1.0/24 --availability-zone ap-northeast-1a { \"Subnet\": { \"VpcId\": \"vpc-cc2b11a9\", \"CidrBlock\": \"10.0.1.0/24\", \"State\": \"pending\", \"AvailabilityZone\": \"ap-northeast-1a\", \"SubnetId\": \"subnet-131feb65\", \"AvailableIpAddressCount\": 251 } } # ap-northeast-1c AvailabitliyZone $ aws ec2 create-subnet --vpc-id vpc-cc2b11a9 --cidr-block 10.0.2.0/24 --availability-zone ap-northeast-1c { \"Subnet\": { \"VpcId\": \"vpc-cc2b11a9\", \"CidrBlock\": \"10.0.2.0/24\", \"State\": \"pending\", \"AvailabilityZone\": \"ap-northeast-1c\", \"SubnetId\": \"subnet-d6d2d38f\", \"AvailableIpAddressCount\": 251 } } サブネットにタグを付与する 作成したサブネットには、それぞれ、subnet-b71eeac1、subnet-131feb65、subnet-d6d2d38f というIDが振られている。それぞれにタグを付与する。 $ aws ec2 create-tags --resources subnet-b71eeac1 --tags Key=Name,Value=\"subnet public web\" $ aws ec2 create-tags --resources subnet-131feb65 --tags Key=Name,Value=\"subnet public db1\" $ aws ec2 create-tags --resources subnet-d6d2d38f --tags Key=Name,Value=\"subnet public db2\" インターネットゲートウェイの作成 インターネットゲートウェイを作成し、タグを付与する。 $ aws ec2 create-internet-gateway { \"InternetGateway\": { \"Tags\": [], \"InternetGatewayId\": \"igw-5bb8203e\", \"Attachments\": [] } } $ aws ec2 create-tags --resources igw-5bb8203e --tags Key=Name,Value=\"igw main\" インターネットゲートウェイをVPCにアタッチする。 #アタッチ $ aws ec2 attach-internet-gateway --internet-gateway-id igw-5bb8203e --vpc-id vpc-cc2b11a9 #確認 $ aws ec2 describe-internet-gateways --internet-gateway-id igw-5bb8203e { \"InternetGateways\": [ { \"Tags\": [ { \"Value\": \"igw main\", \"Key\": \"Name\" } ], \"InternetGatewayId\": \"igw-5bb8203e\", \"Attachments\": [ { \"State\": \"available\", \"VpcId\": \"vpc-cc2b11a9\" } ] } ] } パブリックサブネット用のRoutingTableを作成する VPC作成時に\"rtb-964da5f2\"というIDを持つRoutingTableが作成されていることを確認した。\"rtb-964da5f2\"にはVPC作成時に自動生成されたデフォルトサブネットが紐付いている。 今回、オリジナルのサブネット、インターネットゲートウェイを新たに作成するのに合わせて、RoutingTableを新規作成する。 # RoutingTable の作成 $ aws ec2 create-route-table --vpc-id vpc-cc2b11a9 { \"RouteTable\": { \"Associations\": [], \"RouteTableId\": \"rtb-fe5cb49a\", \"VpcId\": \"vpc-cc2b11a9\", \"PropagatingVgws\": [], \"Tags\": [], \"Routes\": [ { \"GatewayId\": \"local\", \"DestinationCidrBlock\": \"10.0.0.0/16\", \"State\": \"active\", \"Origin\": \"CreateRouteTable\" } ] } } # タグ付け $ aws ec2 create-tags --resources rtb-fe5cb49a --tags Key=Name,Value=\"rtb public\" パブリックサブネット用RoutingTableにインターネットゲートウェイを関連付ける $ aws ec2 create-route --route-table-id rtb-fe5cb49a --destination-cidr-block 0.0.0.0/0 --gateway-id igw-5bb8203e { \"Return\": true } 新たに作成したサブネットをパブリックサブネット用RoutingTableに繋ぎかえる $ aws ec2 associate-route-table --route-table-id rtb-fe5cb49a --subnet-id subnet-b71eeac1 { \"AssociationId\": \"rtbassoc-0ce55a68\" } $ aws ec2 associate-route-table --route-table-id rtb-fe5cb49a --subnet-id subnet-131feb65 { \"AssociationId\": \"rtbassoc-c1e45ba5\" } $ aws ec2 associate-route-table --route-table-id rtb-fe5cb49a --subnet-id subnet-d6d2d38f { \"AssociationId\": \"rtbassoc-76c97612\" }

これまで、OAuth2 Authenticate code grant flow で FitbitAPI の認証をパスしてデータを取得する事例を書いてきた。implicit grant flow では認証をパスできないのか調べてみた。 Fitbit API の認証を implicit grant flowでパスする際の特徴は以下の通り。 implicit grant flow でFitbitAPI の認証をパスするには、アプリケーションタイプを Client として登録する必要がある。 access tokenの消費期限はユーザが決定する。 refresh tokenを使ってaccess tokenを更新する場合、ユーザの承認が必要となる。 本エントリにて、implicit grant flow で FitbitAPI の認証する方法を step by step で追ってみる。 Authenticate code grant flow と implicit grant flow の違いについて、↓が参考になりました。What is the difference between the 2 workflows? When to use Authorization Code flow? Authenticate code grant flow Authenticate code grant flow は以下の流れだった。 ClientID, ClientSecret から認可コードを取得する 認可コードと accessToken を交換する accessTokenを取得するためには ClientID, ClientSecret を保持しておく必要があった。 本家から図を転載する。 implicit grant flow 対して、implicit grant flow は以下のような流れとなる。 まず、本家からの図の転載。 まとめると次の通り。 ClientIDを使って accessToken を取得する https://www.fitbit.com/oauth2/authorize?state=fx2D6zGcbNVltC15sQlxh4wP8U8HH53%2B &scope=activity+heartrate+location+profile+settings+sleep+social+weight &response_type=token &client_id=xxxxxx &redirect_uri=http%3A%2F%2Fhoge.com%3A8002%2Ftest.php ブラウザ上で認証画面が表示される。この画面はブラウザである必要があり埋め込んでスルーしたりすることはできない。 許可すると、指定したコールバックURLがパラメータ付きで呼び出される。（当然伏字です） http://hoge.com:8002/test.php#scope=weight+location+social+settings+heartrate+sleep+activity+profile &state=fx2D6zGcbNVltC15sQlxh4wP8U8HH53%252B &user_id=xxxxx &token_type=Bearer &expires_in=69483 &access_token=eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE0NjY5MzMyMzcsInNjb3BlcyI6InJ3ZWkgc nBybyByaHIgcmxvYyByc2xlIHJzZXQgcmFjdCByc29jIiwic3ViIjoiM1FaVllYIiwiYXVkIjoiMjI3V EZKIiwiaXNzIjoiRml0Yml0IiwidHlwIjoiYWNjZXNzX3Rva2VuIiwiaWF0IjoxNDY2ODYzNzU0fQ.oy 0Px-mEauh5Jgw1yS8PF94U37tUW2Q35fbCHKcDFHU ここで得られたaccess_tokenを使って、データアクセスAPIを呼び出す。その際、クエリに含まれるaccess_tokenをAPIにアクセスする度に利用する。クエリに付けるのではなくBASIC認証のヘッダとして付与する。 URLのクエリからaccess_tokenを取得しBASIC認証で利用する。 GET https://api.fitbit.com/1/user/-/profile.json Authorization: Bearer eyJhbGciOiJIUz******************************* ******BybyByaHIgcmxvYyByc2xlIHJzZXQgcmFjdCByc29jIiwic3ViIjoiM1FaVll YIiwiYXVkIjoiMjI3VEZKIiwiaXNzIjoiRml0Yml0IiwidHlwIjoiYWNjZXNzX3Rva2 V**************************************eLtCF0V6IISPinTxy_ZgCLQl1tB0 rEMeqVk4 access_token を使いまわしていると、いずれ access_token の消費期限に到達する。 消費期限に到達した access_token を使ってデータ取得を行うと、以下のようなレスポンスが返ってくる。 { \"errors\": [ { \"errorType\": \"expired_token\", \"message\": \"Access token expired: eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE0MzAzNDM3MzUsInNjb3BlcyI6Indwcm8gd2xvYyB3bnV0IHdzbGUgd3NldCB3aHIgd3dlaSB3YWN0IHdzb2MiLCJzdWIiOiJBQkNERUYiLCJhdWQiOiJJSktMTU4iLCJpc3MiOiJGaXRiaXQiLCJ0eXAiOiJhY2Nlc3NfdG9rZW4iLCJpYXQiOjE0MzAzNDAxMzV9.z0VHrIEzjsBnjiNMBey6wtu26yHTnSWz_qlqoEpUlpc\" } ] } ここで、Authenticate code grant flow と同様に refresh_token を使って access_token を更新する必要があるのだが、ドキュメントに記述があるように、implicit grant flow では refresh_token を取得するために client_id を使って再度認証する必要がある。 client_id はアプリケーションにストアすべきデータではなく、ユーザによる操作が必要。 Unlike the Authorization Code Grant Flow, the refresh tokens are not issued with the Implicit Grant flow. Refreshing a token requires use of the client secret, which cannot safely be stored in distributed application code. When the access token expires, users will need to re-authorize your app. また、以下に記述があるように、implicit grant flow における access_token の消費期限は Authenticate code grant flow のそれよりも長めに設定される。アプリケーション側で予め消費期限を設定できるが、最終的には認証画面においてユーザが消費機嫌を決めること値が決まる。 Access tokens from the Implicit Grant Flow are longer lived than tokens from the Authorization Code Grant flow. Users may specify the lifetime of the access token from the authorization page when an application uses the Implicit Grant flow. The access token lifetime options are 1 day, 1 week, and 30 days. Applications can pre-select a token lifetime option, but the user ultimately decides.