NgSysV.A Serious Svelte InfoSys: A Client-Server Version

This post series is indexed at NgateSystems.com. You'll find a super-useful keyword search facility there too.

Last reviewed: Nov '24

1. Introduction

Post 3.3 delivered some bad news - the Firestore auth object used client-side to supply information about a logged-in user isn't available server-side. This has the following consequences:

• Server-side database code must use the Firestore Admin API. This is because Firestore Client API code that makes calls subject to database "rules" that reference auth fails when auth isn't available. By contrast, Admin API calls don't care about database rules. If you dropped the rules, client API calls would work server-side, but this would leave your database open to cyber attack (you've been working into your live Firestore database ever since you started using your local VSCode terminal - think about it).

• Server-side code that uses data items such as userName and userEmail derived from auth must find another way of getting this information.

This post describes how you overcome these problems to produce a high-performance webapp that runs securely and efficiently server-side.

2. Authenticated Svelte server-side code in practice

If you've already got used to the Client call signatures, the requirement to switch to the Firestore Admin API is a nuisance. But you'll soon get used to this so it shouldn't hold you up significantly.

Getting user data, however, is a different matter. For many applications, access to user properties such as uId is critical to their design. For example, a webapp may need to ensure that users can only see their own data. Unfortunately, arranging this is quite a struggle. Here we go:

1. First, on the client, you need to find a way to create an "idToken" package containing everything your server-side code might need to know about a user. Google provides a getIdToken() mechanism to construct this from the user's auth session data.
2. Then you need to find a way of passing this package to the server. The mechanism used here registers this in a "header" that gets added to client calls to the server.
3. Then you need to obtain a Google "Service Account" that enables you to authenticate your use of the Firestore Admin API on a Google server. The keys that define this need to be embedded securely in your project files (recall the firebaseConfig.env discussion in Post 3.3.
4. And finally, your server-side code must present these Service Account keys wherever you need to use a Firestore database.

2.1 Getting an idToken

Have a look at the following code from the