DEV Community

dala00
dala00

Posted on • Originally published at crieit.net

3 3

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

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
  }
Enter fullscreen mode Exit fullscreen mode

呼び出し方はどうであれ、通信が発生するので上記のようにリクエストは1回にした方が良いでしょう。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)
    })
  })
})
Enter fullscreen mode Exit fullscreen mode

データの取得方法

しかし、これでは先程の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
}
Enter fullscreen mode Exit fullscreen mode

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

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

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

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

まとめ

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

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

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

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

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

Top comments (2)

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
dala00 profile image
dala00

Oh, Thank you so much!!

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

AWS GenAI LIVE!

GenAI LIVE! is a dynamic live-streamed show exploring how AWS and our partners are helping organizations unlock real value with generative AI.

Tune in to the full event

DEV is partnering to bring live events to the community. Join us or dismiss this billboard if you're not interested. ❤️