kit
kit copied to clipboard
feat: make `handleFetch` a shared hook
Hello Svelte Team,
I send you this PR to make handleFetch a shared hook that can be used on both client and server side.
Motivation
I'm working a hybrid client/server administration portal where authentication is done using OAuth/OIDC + JWT tokens. I'm trying to create a secure and performant authentication process and I noticed that we could create something very powerful with SvelteKit by improving some features.
Indeed, a good practice when working on a SSR environment is:
- Make all requests to auth server on the server side
- Transmit
access tokenandrefresh tokento client - Keep only the
refresh tokenon a cookie (not the access token) - When a new request is done using the server, refresh the token and transmit the new refresh token to the client.
However, on a very hybrid scenarios where requests are done sometimes on the client, sometimes on the server, it multiplies the numbers of refresh token requests and create a bottleneck on the auth server.
So a good improvement would be to constantly pass the access token from the client to the server to allow reusing during the session. I noticed that we can take control of fetch requests on the server side but not on the client side.
Other use cases
I see some scenarios where controling the client-side fetch would be useful:
- Automatically exchange token information (like explained above)
- Automatically exchange headers with server-side
loadandactionfunctions - Automatically includes credentials to requests to API
- Logging and monitoring fetch requests
Implementation
This PR replicates the behavior of the server-side handleFetch hook with one difference: the hook does not have access to event.
Notes
I wanted to include a test similar to the server-side handleFetch. However I did not find any tests for server-side handleFetch.
I'm open to any idea to create tests for both hooks.
Edit : I finally found my way and included some tests, do not hesitate to review them!
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
- [ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
- [x] This message body should clearly illustrate what problems it solves.
- [x] Ideally, include a test that fails without this PR but passes with it.
Tests
- [x] Run the tests with
pnpm testand lint the project withpnpm lintandpnpm check
Changesets
- [x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.
Edits
- [x] Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.