「SSR」の記事 - Crieit

Nuxt.js+Firestoreの場合に安全にSSRする方法

2018-12-16T23:27:12+09:00

Nuxt.jsをサーバーで動かしてFirestoreを使い、且つサーバーサイドレンダリングしたい時には色々考えることが出てきます。懸念点と対応した方がよさそうな点をまとめてみます。

SSRしない場合との違い

SSRせずクライアント上でFirestoreからデータを取る場合ですが、匿名認証にしろ、SNSアカウントの認証にしろ、認証しているかどうかでセキュリティルールによりデータを守りやすく、他者によるFirebaseプロジェクトの設定を盗用しての勝手な操作を防いだりすることができます。

しかし、asyncData内によるSSRとなると、そのクライアント側の認証情報を利用することはできません。そうなるとデータを守れないどころか、そもそもセキュリティルールが設定されているとデータにアクセスすることすらできません。こういう時にどうすれば良いかを考えます。

どのように解決するか

Cloud Functionsの利用

今回はCloud Functionsを利用する方法を考えました。具体的にどうするかというと、asyncData内ではfunctionsからデータを取るだけにします。例えば下記のような感じです。

  async asyncData({ params }) {
    const response = await axios.get(functionUrl)
    return response.data
  }

呼び出し方はどうであれ、通信が発生するので上記のようにリクエストは１回にした方が良いでしょう。functions側でそのページ専用のアクションを作ってデータを返します。

export const showUser = functions.https.onRequest((req, res) => {
  return cors(req, res, async () => {
    const user = await User.getUserByUsername(req.query.id)
    res.json({
      user,
      posts: await Post.getPosts(user.uid, 5)
    })
  })
})

データの取得方法

しかし、これでは先程のasyncDataと同様、セキュリティルールの関係でデータが取れないのでは？　と思われるかもしれません。ただ、Firebaseにはサーバー用のFirebase Admin SDKというものがあります。これはセキュリティルールに関係なくデータを扱うことができるため、これを利用します。具体的には下記のような形です。

import * as admin from 'firebase-admin'

const firestore = admin.firestore()
const usersCollection = firestore.collection('users')

export async function getUser(uid: string) {
  const querySnapshot = await usersCollection
    .where('uid', '==', uid)
    .get()
    .catch(error => {
      console.error(error)
      return null
    })

  if (!querySnapshot || querySnapshot.size == 0) {
    return null
  }

  const user = querySnapshot.docs[0].data()
  user.id = querySnapshot.docs[0].id
  return user
}

クライアント側とは微妙にcollectionの取り方が違うだけで、基本的にはほぼ同じです。このようにしてサーバーサイドレンダリングのためのデータ取得処理を行うことができます。

セキュリティルールを無視で良いのか？

今回の例のfunctions側でのデータ取得処理に関しては、ルールを無視で問題ありません。

というのも、そもそもSSRの目的としては、クローラに認識してもらうためのSEO対策になるかと思います。つまり、ユーザー認証が必要なデータを取る必要は一切無いということになります。あくまでも誰もが閲覧できるパブリックなデータを取るだけです。そのため基本的には認証に関するセキュリティルールをこの場で考慮する必要はありません。ただ、corsはちゃんと挟んでおきましょう。

まとめ

やってみて思いましたが、これって普通のサーバーを使った開発と同じですよね！？　なんとなく手軽さが失われた感じはありますが、それでもまあサーバーを管理する必要が無いのは大きなメリットではあることに変わりはないでしょう。

他にも色々と方法はあるかもしれませんが、とにかくどの様な方法にしろ、どのようにデータを守るかはしっかり考えて構築が必要となります。

以前認証とセキュリティルールについて書いた考察もありますので、もし気が向いたらそちらもぜひ御覧ください。

Firebaseの匿名認証はなんのためにあるのか - セキュリティ編

Nuxt.jsでSSRかブラウザ上の処理かを判定する方法の一つ

2018-08-26T23:57:05+09:00

Nuxt.jsで開発する場合、書いた処理がサーバーサイドレンダリング（SSR）時と、ブラウザ上での処理時の両方で実行される場合がある。それを判定したい時の方法。

正規の方法

正規の方法として、公式にも書かれているやり方。

window or document undefined?

こんな感じで判定できる。

if (process.browser) {
  require('external_library')
}

TypeScriptの場合

ただし、TypeScriptの場合はprocessの型にbrowserというプロパティが無いため、エラーになってしまう。そのため色々あれこれ型をうまい事設定する方法も可能かもしれないが、とりあえず古式ゆかしい方法でも判定することができる。

    if (typeof window !== "undefined") {

Nuxtでdocument is not definedエラー

2018-08-11T16:55:46+09:00

Nuxt.jsにて、npmで提供されているVueコンポーネントを利用しようとした時に、ReferenceError: document is not definedというエラーが出ることがあるのでそれの解決方法。

とりあえず解決方法は？

例えば僕の愛用しているJohMun/vue-tags-inputでも出るのだが、その場合下記のようにテンプレートを書く。

プラグイン追加で出る場合は、nuxt.config.jsの該当プラグインでssr: falseにすれば解決する場合もある（プラグインの説明に書いてあったりする）

なぜ発生するのか？

エラーと対応内容を見ればだいたい分かると思うが、そもそもSSR（サーバーサイドレンダリング）を考慮していないVueコンポーネントも存在し、そういったライブラリは今回のようにブラウザ上だけで存在している、documentを参照している場合がある。

サーバーサイドレンダリングの場合はブラウザではないため当然documentは存在しないためundefinedとなりエラーになる。そのため、タグで囲ってあげることで、ブラウザ上では表示するが、サーバーサイドレンダリングのタイミングでは動作させないようにすることでエラーを防ぐことができる、という仕組み。

そのため、当然Nuxt.jsに限らずサーバーサイドレンダリングしている場合は発生する場合がある。