sveltekit-firebase-helpers 0.0.1 → 0.0.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +10 -6
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -24,7 +24,7 @@ Oh, and one other issue - SvelteKit is often very opinionated but sometimes thos
|
|
|
24
24
|
|
|
25
25
|
How to use the features of the package. Of course, you need to install it using the package manager of your choice (which should be `pnpm`):
|
|
26
26
|
|
|
27
|
-
pnpm i
|
|
27
|
+
pnpm i sveltekit-firebase-helpers
|
|
28
28
|
|
|
29
29
|
### Server Hooks
|
|
30
30
|
|
|
@@ -35,7 +35,7 @@ The server-side helpers are added as handlers in your app [server hooks](https:/
|
|
|
35
35
|
To decode any http `Authorization` header added by the service-worker use `createAuthHandle` passing in the `firebase-admin/auth` instance it needs to decode the firebase ID token:
|
|
36
36
|
|
|
37
37
|
```ts
|
|
38
|
-
import { createAuthHandle } from "
|
|
38
|
+
import { createAuthHandle } from "sveltekit-firebase-helpers";
|
|
39
39
|
import { auth } from './firebase.server'
|
|
40
40
|
|
|
41
41
|
export const handle = createAuthHandle(auth)
|
|
@@ -48,7 +48,7 @@ Any requests with an `Authorication Bearer [token]` header will now be decoded a
|
|
|
48
48
|
The service-worker needs access to the firebase config, but SveleKit conspires to make that difficult to import. To get around this we provide our own server-endpoint that the service-worker can request it from.
|
|
49
49
|
|
|
50
50
|
```ts
|
|
51
|
-
import { createOptionsHandle } from "
|
|
51
|
+
import { createOptionsHandle } from "sveltekit-firebase-helpers";
|
|
52
52
|
import { options } from './firebase'
|
|
53
53
|
|
|
54
54
|
export const handle = createOptionsHandle(options)
|
|
@@ -88,7 +88,7 @@ You can test the handle is working correctly by requesting the `/__/firebase/ini
|
|
|
88
88
|
To proxy auth requests so you can use `signInWithRedirect` on browsers that block 3rd party cookies (now all of them) use `createAuthHandle` passing in the `application-id.firebaseapp.com` domain name from you Firebase app config, e.g. `captaincodeman-experiment.firebaseapp.com`.
|
|
89
89
|
|
|
90
90
|
```ts
|
|
91
|
-
import { createOptionsHandle } from "
|
|
91
|
+
import { createOptionsHandle } from "sveltekit-firebase-helpers";
|
|
92
92
|
import { env } from '$env/dynamic/public'
|
|
93
93
|
|
|
94
94
|
const auth_domain = env.PUBLIC_FIREBASE_AUTH_DOMAIN
|
|
@@ -106,7 +106,7 @@ So pass the `auth` instance (`firebase-admin/auth`) and it will add the Auth Han
|
|
|
106
106
|
|
|
107
107
|
```ts
|
|
108
108
|
import { env } from '$env/dynamic/public'
|
|
109
|
-
import { createHandle } from '
|
|
109
|
+
import { createHandle } from 'sveltekit-firebase-helpers'
|
|
110
110
|
import { options } from './routes/firebase'
|
|
111
111
|
import { auth } from './routes/firebase-server'
|
|
112
112
|
|
|
@@ -125,7 +125,7 @@ To automatically add the `Authentication Bearer [idToken]` http header to each s
|
|
|
125
125
|
/// <reference lib="esnext" />
|
|
126
126
|
/// <reference lib="webworker" />
|
|
127
127
|
|
|
128
|
-
import { addFirebaseAuth } from '
|
|
128
|
+
import { addFirebaseAuth } from 'sveltekit-firebase-helpers'
|
|
129
129
|
|
|
130
130
|
addFirebaseAuth({
|
|
131
131
|
auth_emulator: 'http://localhost:9099' // if using the Firebase Auth Emulator
|
|
@@ -156,3 +156,7 @@ export const auth = browser
|
|
|
156
156
|
The `browser` check is to avoid an error if using SSR.
|
|
157
157
|
|
|
158
158
|
One additional advantage of this is that your client-side auth dependencies are reduced so your app should start faster (you can also avoid loading the `popupRedirectResolver` for initialization and pass it to methods like `signInWithRedirect` when called for even greater savings).
|
|
159
|
+
|
|
160
|
+
When using `signInWithRedirect` your page loads and will automatically handle the redirect token or you may call `getRedirectResult` to get the result yourself. At this point, your SvelteKit `load` functions will have already run with an unauthenticated user so to update your app data you may need to call `invalidateAll` to re-run the load functions. But because of the polling delay, the service-worker may not have the auth token yet so we've provided a `syncAuthToken` method that will send it to the client - call it before the `invalidateAll`.
|
|
161
|
+
|
|
162
|
+
The same situation happens if you update the auth claims on the server inside any endpoint or form action. You can use `syncAuthToken` to ensure that any `invalidateAll` call will include the latest token when data is refreshed from the server.
|