Sentry

Drop in authentication including route protection and redirects for SvelteKit apps.

Why?

Adding authentication to front end is one of the most time consuming tasks. Building apps in Svelte is great but there is no standard way to implement authentication. There are multiple libraries that allow us to add authentication for multiple providers. However, switching from one to another is not easy. The UI components for all the providers also need to meet the provider guidelines for the final app to be approved.

This is an attempt to make adding authentication to SvelteKit apps as simple as possible. This framework has been designed for Svelte.

Features

• Configuration driven
• Secrets using environment variables
• Unit tests
• Route protection
  • Public pages
  • Protected routes
  • Role based protection for route
  • Caching blocked routes to be redirected on login
• Different auth libraries
  • Supabase
  • Firebase
  • Auth0
  • Amplify
• Multiple providers
  • Magic Link
  • Google
  • Microsoft
  • Github
  • Twitter
  • Facebook
• Examples with protected routes and data operations
  • Supabase
  • Firebase
• Emulator tests where available

Getting started

Get started quickly using degit. Select the library you want to use and run degit to get a sample app.

• Supabase

degit jerrythomas/sentry/examples/supabase my-app

• Firebase
• Auth0
• Amplify

Take a look at the following files/folders in the sample to understand how it works.

• config
• hooks.js
• login/index.svelte
• logout.svelte
• data
• todos
• auth

WindiCSS

This library uses WindiCSS and the components will not render properly if the required classes are not included in the final bundle. Ensure that the sentry library is included in the extract configuration of windi.config.js

extract: {
  include: [
    './src/**/*.{html,js,svelte,ts}',
    'node_modules/@jerrythomas/sentry/src/**/*.{html,js,svelte,ts,css}}'
  ]
}

Route Configuration

Routes are configurable as shown in the example config/routes.js file. Sentry assumes that all routes are private by default. Public routes need to be listed so that they can be accessed without logging in.

Components

This library consists of the following components.

• UI component with buttons for different OAuth providers
• Utility functions for various stages of auth lifecycle
• Store for managing the user session
• Route protection for pages & endpoints
• Logged in session details available in load function

References

Cookie parsing and serializing is required to support server side auth guard. The original npm library jshttp/cookie ran into problems on SvelteKit v1.0.0-next.218. The code has been converted from CJS to ESM.

License

MIT © Jerry Thomas