This tutorial demonstrates how to build a basic user management app. The app authenticates and identifies the user, stores their profile information in the database, and allows the user to log in, update their profile details, and upload a profile photo. The app uses:
Supabase Database - a Postgres database for storing your user data and Row Level Security so data is protected and users can only access their own information.
Supabase Auth - users log in through magic links sent to their email (without having to set up passwords).
Before we start building we're going to set up our Database and API. This is as simple as starting a new Project in Supabase and then creating a "schema" inside the database.
Now we are going to set up the database schema. We can use the "User Management Starter" quickstart in the SQL Editor, or you can just copy/paste the SQL from below and run it yourself.
You can easily pull the database schema down to your local project by running the db pull command. Read the local development docs for detailed instructions.
supabase link --project-ref <project-id>
# You can get <project-id> from your project's dashboard URL: https://supabase.com/dashboard/project/<project-id>
Now that you've created some database tables, you are ready to insert data using the auto-generated API.
We just need to get the Project URL and anon key from the API settings.
SvelteKit is a highly versatile framework offering pre-rendering at build time (SSG), server-side rendering at request time (SSR), API routes, and more.
It can be challenging to authenticate your users in all these different environments, that's why we've created the Supabase Auth Helpers to make user management and data fetching within SvelteKit as easy as possible.
* A convenience helper so we can just call await getSession() instead const { data: { session } } = await supabase.auth.getSession()
*/
event.locals.getSession = async () => {
const {
data: { session },
} = await event.locals.supabase.auth.getSession()
return session
}
return resolve(event, {
filterSerializedResponseHeaders(name) {
return name === 'content-range'
},
})
}
If you are using TypeScript the compiler might complain about event.locals.supabase and event.locals.getSession, this can be fixed by updating your src/app.d.ts with the content below:
src/app.d.ts
// src/app.d.ts
import { SupabaseClient, Session } from '@supabase/supabase-js'
declare global {
namespace App {
interface Locals {
supabase: SupabaseClient
getSession(): Promise<Session | null>
}
interface PageData {
session: Session | null
}
// interface Error {}
// interface Platform {}
}
}
Create a new src/routes/+layout.server.ts file to handle the session on the server-side.
As we are employing Proof Key for Code Exchange (PKCE) in our authentication flow, it is necessary to create a server endpoint responsible for exchanging the code for a session.
In the following code snippet, we perform the following steps:
Retrieve the code sent back from the Supabase Auth server using the code query parameter.
Exchange this code for a session, which we store in our chosen storage mechanism (in this case, cookies).
Finally, we redirect the user to the account page.
After a user is signed in, they need to be able to edit their profile details and manage their account.
Create a new src/routes/account/+page.svelte file with the content below.
src/routes/account/+page.svelte
<!-- src/routes/account/+page.svelte -->
<script lang="ts">
import { enhance } from '$app/forms';
import type { SubmitFunction } from '@sveltejs/kit';
Now create the associated src/routes/account/+page.server.ts file that will handle loading our data from the server through the load function
and handle all our form actions through the actions object.
Let's create an avatar for the user so that they can upload a profile photo. We can start by creating a new component called Avatar.svelte in the src/routes/account directory:
src/routes/account/Avatar.svelte
<!-- src/routes/account/Avatar.svelte -->
<script lang="ts">
import type { SupabaseClient } from '@supabase/supabase-js'
If you upload additional profile photos, they'll accumulate
in the avatars bucket because of their random names with only the latest being referenced
from public.profiles and the older versions getting orphaned.
To automatically remove obsolete storage objects, extend the database
triggers. Note that it is not sufficient to delete the objects from the
storage.objects table because that would orphan and leak the actual storage objects in
the S3 backend. Instead, invoke the storage API within Postgres via the http extension.
Enable the http extension for the extensions schema in the Dashboard.
Then, define the following SQL functions in the SQL Editor to delete
storage objects via the API:
create or replace function delete_storage_object(bucket text, object text, out status int, out content text)
returns record
language 'plpgsql'
security definer
as $$
declare
project_url text := '<YOURPROJECTURL>';
service_role_key text := '<YOURSERVICEROLEKEY>'; -- full access needed
url text := project_url||'/storage/v1/object/'||bucket||'/'||object;
create or replace function delete_avatar(avatar_url text, out status int, out content text)
returns record
language 'plpgsql'
security definer
as $$
begin
select
into status, content
result.status, result.content
from public.delete_storage_object('avatars', avatar_url) as result;
end;
$$;
Next, add a trigger that removes any obsolete avatar whenever the
profile is updated or deleted:
create or replace function delete_old_avatar()
returns trigger
language 'plpgsql'
security definer
as $$
declare
status int;
content text;
avatar_name text;
begin
if coalesce(old.avatar_url, '') <> ''
and (tg_op = 'DELETE' or (old.avatar_url <> new.avatar_url)) then
-- extract avatar name
avatar_name := old.avatar_url;
select
into status, content
result.status, result.content
from public.delete_avatar(avatar_name) as result;
if status <> 200 then
raise warning 'Could not delete avatar: % %', status, content;
end if;
end if;
if tg_op = 'DELETE' then
return old;
end if;
return new;
end;
$$;
create trigger before_profile_changes
before update of avatar_url or delete on public.profiles
for each row execute function public.delete_old_avatar();
Finally, delete the public.profile row before a user is deleted.
If this step is omitted, you won't be able to delete users without
first manually deleting their avatar image.
create or replace function delete_old_profile()
returns trigger
language 'plpgsql'
security definer
as $$
begin
delete from public.profiles where id = old.id;
return old;
end;
$$;
create trigger before_delete_user
before delete on auth.users
for each row execute function public.delete_old_profile();
At this stage you have a fully functional application!
