OTOBANK Engineering Blog

オトバンクはコンテンツが大好きなエンジニアを募集しています!

必要な PHP拡張/パッケージをCIで検出し、インストール漏れエラーを防ぐ。 GitHub Actions と composer-require-checker で

composer での require と require-dev キー

PHPで広く使われている依存性マネージャの composer には、昨今の他の言語で用いられているツール同様に、依存性を設定するキーとして requirerequire-dev が存在します。

このキー欄にはそれぞれプロジェクトが依存する、PHPのバージョン・個々のPHP拡張・ベンダーパッケージとそのバージョン が指定できます。 普段PHPを利用する開発者のみなさんは、以下の通り依存性の追加コマンドを追加されてるかと思います。

composer require monolog/monolog # ロガーとしてmonologが必要
composer require --dev phpunit/phpunit # 開発時にテイスティングツールとしてPHPUnitが必要

require-dev の特徴として、

  • composer install --no-dev にてプロジェクトでのインストール時に対象外となる。
  • 依存指定するパッケージの require 指定時に、そのパッケージ先の require-dev は対象外となる。

が挙げられます。

本番リリース時のデプロイケース

開発用パッケージについては、本番の実行環境については必要ありませんので、デプロイパイプラインでは本番のみ --no-dev と指定しているプロジェクトも多いかと思います。

例えば、Google App Engine flex の実行Dockerイメージを作成する php-docker は、composer.jsonがプロジェクトルートに含まれていれば、指定されたPHP拡張のインストールも含め行ってくれますが、デフォルトでは、

'COMPOSER_FLAGS' => '--no-dev --prefer-dist',

--no-dev でのインストールになります。

require-dev が依存するパッケージの問題

この 本番と開発環境でインストールされるパッケージが異なる点について問題となるのが、dev指定のパッケージが依存するパッケージをプロダクションコードにて利用している場合です。 例えば、friendsofphp/php-cs-fixer を利用している場合 symfony/process がdev依存性でありますが、それに気づかず、Symfony\Component\Process\Process クラスを用いる改修を行い、require 設定をsymfony/processに行っていない場合にクラスが見つからずエラーとなってしまいます。

composer-require-checker による検出

昨年のPHPカンファレンス 2019 でも紹介しましたが、maglnet/composer-require-checker を用いると、composer.jsonでrequire定義されていないシンボル(クラスやPHP拡張の関数) を検出することができます。

github.com

実行方法としては、インストール後プロジェクトのルートディレクトリにて、

composer-require-checker check composer.json

とすることで、以下のような出力を得ることができます。

ComposerRequireChecker 2.1.0@0c66698d487fcb5c66cf07108e2180c818fb2e72
The following unknown symbols were found:
+------------------------------------------------------------+--------------------+
| unknown symbol                                             | guessed dependency |
+------------------------------------------------------------+--------------------+
| Aura\Router\Router                                         |                    |
| Aura\SqlQuery\Common\InsertInterface                       |                    |
| Aura\SqlQuery\Common\SelectInterface                       |                    |
| Aura\Sql\ExtendedPdoInterface                              |                    |
| BEAR\AppMeta\AbstractAppMeta                               |                    |
| BEAR\AppMeta\AppMeta                                       |                    |
| BEAR\AppMeta\Meta                                          |                    |
| ctype_digit                                                | ext-ctype          |
| Doctrine\Common\Cache\Cache                                |                    |

それぞれのクラス名については、対応するパッケージを追加し、guessed dependency 欄にext-○○○ と記載されている場合はPHP拡張がrequireセクションに足りないので追加します。

CIでの検出

このcomposer-require-checker check コマンドでのunknown symbolsがなにも検出されなかった場合と検出時のexitコードは分かれてますので、CIに組み込むができます。 弊社では GitHub Actionに composer-require-checker のセットアップを行いました。

GitHub Actions での設定例

最近では shivammathur/setup-php@v2 にて、7月21日リリースの2.4.0でtoolsにcomposer-require-checker が追加されたのでそちらを使うと良いかと思います。 https://github.com/shivammathur/setup-php/releases/tag/2.4.0

設定例としては、.github/workflows/composer-require-checker.yml に以下の設定を行います。

name: "Composer Require Checker"

on:
    pull_request:
    push:
        branches:
            - "master"
jobs:
    composer-require-checker:
        name: composer-require-checker check
        runs-on: ubuntu-latest
        steps:
            - name: "Checkout"
              uses: actions/checkout@v2

            - name: "Install PHP"
              uses: shivammathur/setup-php@v2
              with:
                  tools: composer-require-checker

            - name: "Get composer cache directory"
              id: composercache
              run: echo "::set-output name=dir::$(composer config cache-files-dir)"

            - name: "Cache composer dependencies"
              uses: actions/cache@v2
              with:
                  path: ${{ steps.composercache.outputs.dir }}
                  key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
                  restore-keys: ${{ runner.os }}-composer-

            - name: "Install dependencies"
              run: |
                  composer install --no-progress --no-scripts --no-dev

            - name: "Run composer-require-checker check"
              run: composer-require-checker check composer.json

余談ですが、 GitHub Actionsの場合は、 「Create Status badge」から以下のようなステータスバッジのマークダウンがコピーできますので、

![Composer Require Checker](https://github.com/{ベンダー}/{リポジトリ}/workflows/Composer%20Require%20Checker/badge.svg)

f:id:sasezaki:20200911112310p:plain
Github Actions composer require checker badge setting

README.md に追加して確認できるようにすると、ちょっとだけ安心感が増えるかも知れません。

f:id:sasezaki:20200911112423p:plain
composer-require-check-badge

利用/導入しての感想

composer-require-checkerの利用目的としては、上述に上げました--no-dev な本番環境へのリリース事後防止が上げらえますが、それ以外にも

  • extの指定漏れがなくなるので、途中からの参画メンバには composer install で必要な開発環境を確認してもらうことができる。
  • 依存パッケージが大多数の場合での、個別のパッケージupdate作業にて依存の確認が分かりやすくなった。

という良かった点があります。

利用されてないパッケージの削除? ~ composer-unused

composer-require-checker の"逆"なツールとして、コードベースでは未使用なrequireパッケージを検出する composer-unused が存在します。

github.com

現状では class-string なクラス名指定箇所に(Foo::class指定ではなく) 文字スカラー値そのままでの指定の場合にもunusedと検出されてしまうので、 現在、弊社のメインプロジェクトではCIには取り組めてないのですが、将来的にはこの点も解消した上で過不足無いパッケージにしていきたいです。

FlatListとセーフエリアの表示を考える

こんにちは、アプリ開発担当のエモトです。田舎からリモートワークで働いているのですが、どうも家のインターネット回線が不安定。今年前半の緊急事態宣言でリモートワークが広まった時期から明白に不安定になりだし、騙し騙し使ってましたが、流石に支障が出るため、ネットワーク環境の更新を計画中です。これを機に、IPoEで本当のインターネットを始めたい。

私の React Native 開発あるあるの1つとして、実装が終わったと安堵して確認したら、セーフエリア対応が不十分だったことがしばしばあります。ネイティブ開発なら勝手に動いていたことを忘れてしまい、後で SafeAreaView タグで囲って修正します。

今回、FlatList でセーフエリア対応したときに気づいたこと、その対応方法を紹介したいと思います。なお、以降に提示するコード例は簡易的にしています。

単純に以下のコードのように FlatList のみで画面を構成した場合、セーフエリアは考慮されません。

<FlatList />

f:id:mitsuharu_e:20200829111340g:plain

表示したい内容はすべて表示されていますが、リスト底部がセーフエリア(ホームバー)と重なっており、よいインタフェースであるとは言えません。

React Native でセーフエリアを考慮する場合は、SafeAreaView タグを用いてば良いです。早速やってみましょう。

<SafeAreaView>
  <FlatList />
</SafeAreaView>

f:id:mitsuharu_e:20200829111419g:plain

セーフエリアに重ならずに表示できましたが、違うそうじゃない。ユーザーのホームバー操作の保護が目的なら十分ですが、セーフエリアでの表示が無くなっています。これもよいインタフェースではありません。

なら、どうすればいいのか。この解決は、SafeAreaViewFlatList ではなく、 FlatList を構成する要素、例えば renderItem で指定する item などに対して行えば、うまく表示されます。

// renderItem に渡す関数など
import { SafeAreaView } from 'react-navigation'

<SafeAreaView forceInset={{ bottom: 'always' }}>
  <View />
</SafeAreaView>

f:id:mitsuharu_e:20200829111439g:plain

セーフエリアでも表示され、リスト底部がセーフエリアに重なることなく十分な余白を持ったので、今回こそ良いインタフェースと呼べるでしょう。なお、forceInset を設定するために、react-navigation を使用してました。なお、item それぞれに行うと、item 間にセーフエリア分の余白が生まれてしまうので、最下部の item のみに行う、または ListFooterComponent を使用していればそれに対して行うなどの手間があります。

まとめ

ノッチありスマホが発売されたとき、なんてキワモノなと思ってたこともありますが、昨今はノッチありがスタンダードの1つになりました。また、ディスプレイの湾曲や角丸で、セーフエリア設定は必須になったと言えます。実装した後に「あっ、セーフエリアを忘れてた」とならないように、良いインタフェースを持つアプリを開発していきたいです。

最後に、オトバンクではエンジニアを募集中です。日々良いユーザーインタフェースとは何なのかと考えている方、オーディオブック・React Native 開発(Swift や Kotlinのネイティブコードも書いてます)にご興味があれば、是非どうぞ。

お待ちしております。

APIが不必要にセンシティブなデータを返していないことをCIで担保する

暑い日が続きますね。こんにちは @kalibora です。

よその会社であったとしても、セキュリティ関連の事故を見聞きするたびにプログラマーとしては胃が痛くなるのではないでしょうか。

はたして自分のところは大丈夫だろうかと。完璧なんてありえないし、どこかでうっかりミスをして大事故を起こさないだろうかと。

さて、最近では noteでのIPアドレス漏れ のようなことがありましたし、過去には 狙われた7pay「外部ID連携」の脆弱性の全貌。急遽“遮断”した理由 | Business Insider Japan のような問題もありました。

どちらも詳細な原因は外部の私からは知ることはできませんが、APIから不必要なレスポンスを返してしまうことによって起きるセキュリティ関連の事故というのは、わりとよくあるケースなのかもしれません。

私の担当するシステムとしてもこのようなことが起きないか、なにか今以上に対策できることはないか考えてみました。

そもそも何が問題か?

認証のない公開されたAPI(ここでいう公開とは一般に広く仕様を公開しているか否かではなく、認証がなく誰からでもアクセスされる可能性のあるものを指します)というのはWebサーバーがhtmlを返すことと同じなので、 Webページで表示できるものと同じものしか返してはいけない。というのが大前提です。

ですので、公開APIで不必要にセンシティブなデータを返してはいないか?をチェックできればよさそうです。

弊社システムの場合

弊社システムではAPIの仕様(ドキュメント)の生成にOpenAPI(Swagger)を使っています。

この仕様にはAPIのパスごとに認証の有無や返却するレスポンスの定義が含まれているので、 これをしっかりとレビューしていれば問題なさそうです。

また、このOpenAPIの仕様を書くにあたって、Swagger Editor 等のエディターを使うのではなく、 zircote/swagger-php: A php swagger annotation and parsing library を用いて、 ソースコード中のエンティティやバリューオブジェクトへ annotation を付与することで、OpenAPIの仕様を書いています。

さらに、独自実装したシリアライザーを用い、これと同じ annotation を読み取ってレスポンスのjsonを返す。 といったこともしています。

これにより、OpenAPIで記述した仕様と実際に返却されるAPIのレスポンスに乖離が起きることがないため、 やはりOpenAPIの仕様をきちんとレビューすればこのような事故を防ぐことができそうです。

このあたりの詳細については下記のスライドを参照ください。 speakerdeck.com

仕様をチェックするだけなら機械的にレビューできる

OpenAPIの仕様はyamlかjsonで記述されています。ということは、これをプログラムで読み取ることで機械的にレビューできそうです。

例示してみます。

下記のOpenAPI仕様には、オーディオブック取得と自分自身のユーザー情報を取得する2つのAPIがあります。(分かりやすいようにyaml中にコメントを入れています)

paths:
  /audiobooks/{audiobookId}:
    get:
      summary: "オーディオブック取得API"
      parameters:
      - name: "audiobookId"
        in: "path"
        required: true
        type: "integer"
        format: "int64"
      # レスポンスはdefinitionsに定義したAudiobookを返すということが分かる
      responses:
        "200":
          schema:
            $ref: "#/definitions/Audiobook"
  /users/me:
    get:
      summary: "自分自身のユーザー情報取得API"
      # レスポンスはdefinitionsに定義したUserを返すということが分かる
      responses:
        "200":
          schema:
            $ref: "#/definitions/User"
      # OAuth認証のあるAPIだということが分かる
      security:
      - oauth: ['dummy']

definitions:
  # オーディオブック情報の定義(タイトルや説明文は公開情報なので、これらは一般公開してよい)
  Audiobook:
    type: "object"
    properties:
      id:
        type: "integer"
        format: "int64"
      title:
        type: "string"
        description: "オーディオブックのタイトル"
      description:
        type: "string"
        description: "説明文"
  # ユーザー情報の定義(メールアドレスがあったり、基本的に他人からは知られたくない情報)
  User:
    type: "object"
    properties:
      id:
        type: "integer"
        format: "int64"
      name:
        type: "string"
        description: "ユーザー名"
      email:
        type: "string"
        description: "メールアドレス"

/audiobooks/{audiobookId} のオーディオブック取得APIは、認証がないので公開APIですが、レスポンスのAudiobookが公開できる情報なので問題ありません。

対して、

/users/me のユーザー情報取得APIが返すレスポンスはメールアドレスがあったりと、一般公開するものではないですが、OAuth認証によって自分自身しか取得できないようになっているため、これもまた問題ありません。(メールアドレスなどの個人情報といえども、APIとして返せないとWebやアプリで表示することは出来ないので、レスポンスに露出していること自体がダメなわけではなく、認証せずに他人の情報が見れることが問題)

ここで、オーディオブック取得APIの仕様が拡張され、下記のようになったらどうでしょうか?

paths:
  /audiobooks/{audiobookId}:
    get:
      summary: "オーディオブック取得API"
      parameters:
      - name: "audiobookId"
        in: "path"
        required: true
        type: "integer"
        format: "int64"
      responses:
        "200":
          schema:
            $ref: "#/definitions/Audiobook"
definitions:
  Audiobook:
    type: "object"
    properties:
      id:
        type: "integer"
        format: "int64"
      title:
        type: "string"
        description: "オーディオブックのタイトル"
      description:
        type: "string"
        description: "説明文"
      # このオーディオブックを最後に購入したユーザーを返すようになった
      latestPurchasedUser:
        $ref: "#/definitions/User"

オーディオブック取得APIは公開APIであるにも関わらず、レスポンスのオーディオブック内の latestPurchasedUser がユーザーを返すようになったので、ユーザーのメールアドレスや名前などが露出してしまいます。これは問題です。

レビューで仕様をじっくり確認していればこのようなことは防げますが、プログラムで簡単にチェックすることもできます。

今回の場合はそもそも definitions に定義された User が公開APIのレスポンスに現れること自体がまずそうなので、

このyamlファイルをパースし、 $ref は適宜再帰などを用いて解決し、認証のないAPIで User がレスポンスに現れることがないかをチェックすれば問題なさそうです。

他にも properties に特定のキー(passwordなど)が含まれていたらエラーにすることも簡単にできそうです。

ということで、弊社でも早速その様なスクリプトを書いてCIに組み込むことにしました。

汎用性のないソースコードなので特に公開はしませんが、200行くらいの簡易なスクリプトでチェックすることができるようになりました。

まとめ

  • 認証のない公開されたAPIはWebと同じ様に扱い、センシティブなデータが返却されないようにすること
  • オトバンクではAPIの仕様と実装に乖離がないように保たれているので、APIの仕様をきちんとレビューすればよかった
  • APIの仕様をレビューするだけであればすべてのAPIに対しテストを書かずとも、機械的にレビューすることができ、CIに組み込むことが出来た

GraphQLなど他の形式であってもAPIのスキーマを定義しているシステムなら同じようなことができると思うので、みなさまもちょっとしたスクリプトを書いて安心感を増やしてみてはいかがでしょうか。