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

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

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

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

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

<FlatList />

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

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

<SafeAreaView>
  <FlatList />
</SafeAreaView>

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

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

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

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

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

まとめ

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

最後に、オトバンクではエンジニアを募集中です。日々良いユーザーインタフェースとは何なのかと考えている方、オーディオブック・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のスキーマを定義しているシステムなら同じようなことができると思うので、みなさまもちょっとしたスクリプトを書いて安心感を増やしてみてはいかがでしょうか。

わたしのReact Hooksの使い方

こんにちは、アプリ開発担当のエモトです。Pixel 4a が発表されましたね。私のメイン機は iOS なのですが、Android も多少持っているので興味があります。パンチホール式を採用した広々としたディスプレイに惹かれるモノがありますが、「今は時期が悪い、5Gまで待て」と言い聞かせ、5Gモデルを首長く待ちます。まあ、私が使っている回線はMVNOなので、5Gが使えるのがいつになるかは分かりませんが。5Gの風を浴びたい

初めて React Hooks の存在を知ったとき、まだ React Native もよく分かっていない時期で、「フックス？なにそれ？おいしいの？」な状態でした。開発を幾つかやってきて慣れてきた現在は、Hooks で全部書きたいと、思うようにもなりました。

私の開発内容では、標準の Hooks で十分に開発はできているのですが、ときどき少し足りないと思う時があり、その場合はカスタム Hooks を使っています。今回はそれを少し紹介します。

didMount/didUnmount時のみに呼ばれるuseEffect

カスタム Hook を用意せずとも、useEffect の第二引数に [] を指定すれば、実現できます。追加するほどではないと思っていたのですが、[] を指定するたびに ESLint が反応するのは面倒なため、追加しました。

export function useEffectOnce(effect: EffectCallback) {
  useEffect(effect, [])
}

第二引数を書く必要なくなるので、コードがすっきりしまた。これは有名なカスタム Hook の1つであり、カスタム Hook を扱った技術ブログやライブラリでもしばしば見かけます。

State変数の以前の値を参照したい

これも有名なカスタム Hook です。変数の変化量に応じて処理や表示の場合分けが必要なとき、変数更新のたびに、以前の値を保存するためのコードを挿入する必要がないので、とても便利です。

export function usePrevious<T>(value: T) {
  const ref = useRef<T>(null)
  useEffect(() => {
    ref.current = value
  })
  return ref.current
}

Stateではない変数を Hook で管理したい

変数管理は setState を用いれば、変数の参照や更新もできるので便利です。ただし、対象の変数が component に影響しない（させたくない）場合は、変数更新のたびに起こる不要な再レンダリングでパフォーマンスに影響するため、不向きです。State のためにあるのだから、当然のことです。それでも、setState の変数管理だけができないかと色々と考えました。

すぐ思いつくのは、useRef を使うことです。

const ref = useRef(false)

ref.current = hogehoge

if (ref.current) {
  piyopiyo()
}

しかし、コード中に current が唐突に出てくるのは違和感を感じます。そこで、それを改善する Hook を作成しました。

• カスタム Hook

/**
 * ステートレスな変数を管理する
 */
export function useStateless<T>(value: T): [() => T, (v: T) => void] {
  const ref = useRef<T>(value)
  return [
    () => {
      return ref.current
    },
    (v: T) => {
      ref.current = v
    },
  ]
}

• 使用例

const [getRef, setRef] = useStateless(false)

setRef(hogehoge)

if (getRef()) {
  piyopiyo()
}

setState と異なって、変数参照が関数になってしまったのが、残念なところです。内部に useEffect を入れて、値を更新することができなかいかと試しましたが、うまく行かず、このようになりました。しかしながら、Hook でステートレスな変数を管理できるようになったので、コードが整理されたと思っています。

まとめ

Hooks は公式でカスタマイズが紹介され、またサードライブラリが公開さてします。それらを利用して、より便利に開発しましょう。

• 独自フックの作成 – React
• streamich/react-use

以前は、React Native の開発に躓くことが多かったのですが、function component そして React Hooks を使えるようになってから、自分が書きたいコードを自分で書けるようになってきたと思います（まだまだ知らないことは多いですが）。React Hooks は、私が React Native 開発がより面白いと思った起点の１つでもあるので、React Hooks を見ていくのは React Native の勉強におすすめです。

最後に、オトバンクではエンジニアを募集中です。オーディオブックや、React Native 開発（Swift や Kotlinのネイティブコードも書いてます）にご興味があれば、是非どうぞ。

• 株式会社オトバンク の採用・求人

お待ちしております。