DEV Community: pilcrowOnPaper

Your "GDPR compliant" analytics is probably violating GDPR

pilcrowOnPaper — Wed, 10 May 2023 11:10:01 +0000

This article is a cross-post of my blog post.

For the past few days, I've been working on my next open source project: a dead-simple, self-host analytics library (don't worry, this blog post isn't for promoting it). I just want something simple and lightweight for my blogs and library docs that doesn't require those annoying banners. Daily views, countries, OS/device - that's pretty much all I need. The one metric I considered adding but hadn't was unique visitors; I wasn't really sure how to make it GDPR compliant. No worries, let me just ask Google... and that led me down a rabbit hole of EU law.

Here's a short summary of what I found after reading tons of legal documents. This is more a "what not to do" article than a "what you should do" one. Specifically, it won't explain how you should write your privacy policy and get consent - that's for another time.

I also looked through how other analytics provider were counting visitors - a lot of them, at best, are misunderstanding the law, and at worst, violating GDPR. This was especially the case for those that claim that they were GDPR complaint and don't use cookies. And yes, that includes Plausible, Vercel Web Analytics, Umami, Matomo, PostHog, and Fathom. I also assume many people don't really understand GDPR either. Did you know that GDPR isn't about cookies, and in fact, by itself, you're allowed to set cookies without user consent?

It should be obvious but I'm not a lawyer, and this is not legal advice. However, you may want to reconsider if you're using such services.

Related laws

GDPR

Full text. The General Data Protection Regulation (GDPR - Regulation 2016/679), is an EU law on data protection and privacy enacted in 2016, effective since 2018. It protects consumers from unwanted data collection from services, and gives them control over how it's handled.

This regulation does not directly mention or prohibit cookies, and is only intended to protect user privacy.

The ePrivacy Directive

Full text. Directive 2002/58/EC, more commonly known as the ePrivacy Directive, regulates how data traffic is handled and aims to protect user privacy. It also includes provision to limit spam and tracking, including the use of cookies.

While "directives" are not laws and rather more of a goal for each member state to reach by enacting laws individually, every member state has adopted this directive.

Scope

Both of these apply to all 27 member states of the EU, as well as counties in the European Economic Area (Norway, Liechtenstein, Iceland). You must comply if you are either an entity operating in the Union, or providing a service to its population. Since GDPR is an EU law, it applies to non-citizens living its territory, but not to citizens living abroad.

The UK has its own version of GDPR, and the ePrivacy Directive is called the Privacy and Electronic Communications Regulations (PECR). They're nearly identical to their European counterparts.

If a user from Europe visits your site, you must comply.

Personal data

'Personal data' in the context of GDPR is defined in Article 4(1):

(...) any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

Any data that is linked to a single, or just a handful of users, is considered personal data. Names and home addresses are obvious examples, but it also includes online identifiers such as IP addresses, emails, usernames, and session ids. This is mentioned in recital 30:

Natural persons may be associated with online identifiers (...) such as internet protocol addresses, cookie identifiers (...)

It does not matter whether you can extract meaningful personal info or not. If you can (re)identify the user, it's considered personal data. I think this is obvious with "cookie identifiers" being mentioned. This means user ids and id used for pixel tags are included as well.

Unique identifiers, regardless of the method used to generate it (including fingerprinting), are personal data. Encrypting or hashing the data, a process referred to as 'pseudonymization,' may affect the fines when there's a data breach, but the resulting output is still considered personal data.

The user should be informed what personal data are processed and for what purpose.

IP address

Sending requests to third party APIs may be a violation of GDPR as the user's IP address was unknowingly shared with a third party, especially if you had the option to self-host or proxy the request. This includes using Google Fonts and embedding social media posts.

EUCJ: Fashon ID case
German regional court: Google Fonts case

Handling personal data

Personal data may not be processed, including its storage and transmission, without a legal basis (Article 6). These legal bases are not applicable to cookies.

Consent: The user has given clear consent for a specific purpose with an affirmative action.
Contractual obligation: 'Contract' in this case may include terms of service.
Legal obligation
Vital interests: Saving one's life.
Public task
Legitimate interests

Consent

Consent must be opt-in. A pre-ticked checkbox or any other default consent are not allowed. The choice must be presented in a way clearly distinguishable from other matters, and must be written in a clear and concise language. Finally, the user must be given a choice to withdraw.

Legitimate interests

While (6) is purposefully broad and is the most flexible out of the six, there must be a specific interest, be it commercial or security, for it to apply. Users' personal rights override your own interests as well, and it cannot be used if you have more unintrusive way to achieve your "interests". Security related interests, such as DDOS protection, are explicitly stated to be considered proper legitimate interest in recital 49:

This [a legitimate interest of the data controller concerned] could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems.

Your users have a right to object to their personal data being processed, as stated in Article 21(1):

The data subject shall have the right to object, on grounds relating to his or her particular situation, at any time to processing of personal data concerning him or her which is based on point (e) or (f) [legitimate interests] of Article 6(1), (...)

While you don't need to comply if you have "compelling legitimate grounds" that override your users' objection, it is generally recommended that there an option to opt-out of the processing is present. You must list your "interests" in clear manner as well (e.g. privacy policy).

Analytics for the sake of analytics will likely not be considered "legitimate interests." "I was just curious" is, at best, a weak argument.

Anonymous data

Anonymous data, data that cannot be used to identify the user directly or indirectly, are not considered personal data and can be processed without the user's consent (recital 26):

The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.

This may include initials, gender, country, and device. Masked IP addresses are considered anonymous under French regulators, though a clear EU wide decision has not been made.

type	requirement	before	masked
IPv4	Remove last octet	`128.128.128.128`	`128.128.128.0`
IPv6	Remove last 80 bit	`0123:4567:89ab:cdef:0123:4567:89ab:cdef`	`0123:4567:89ab:0:0:0:0:0`

However, the combination of such anonymous data may be considered personal data, such as a masked IP address and device type.

Statistical purpose

Processing personal data for statistical purposes fall within the initial purpose/legal basis of processing, and you may do so without an additional legal basis (Article 5(1)):

(...) further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);

However, processing data for the sole reason of producing statistics is not a legitimate legal basis of collecting personal data.

The ePrivacy Directive

While the directive is relevant to many aspects of privacy, the one we're interested in is Article 5(3):

(...) the use of electronic communications networks to store information or to gain access to information stored in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned is provided with clear and comprehensive information (...), and is offered the right to refuse such processing by the data controller.

In other words, you are not allowed to store any data onto the user's device (cookies, local storage, cache) without their consent, unless it is strictly required to provide the content/service the user has requested. Said exception is stated in the next part:

This shall not prevent any technical storage or access for the sole purpose of carrying out or facilitating the transmission of a communication over an electronic communications network, or as strictly necessary in order to provide an information society service explicitly requested by the subscriber or user.

GDPR's 6 legal bases for processing personal data (including legitimate interests), do not apply in regards to cookies. Auth cookies (session id or JWT) can be considered "strictly required."

Personal data

Does the Article mentioned above (Article 5) applies to cookies that don't store personal data? Article 3 states on "Services concerned":

This directive shall apply to the processing of personal data in connection with the provision of publicly available electronic communications services in public communications networks in the Community.

This seems as if the directive only applies to processing personal data. However, recital 24 states:

Terminal equipment of users of electronic communications networks and any information stored on such equipment are part of the private sphere of the users requiring protection under the European Convention for the Protection of Human Rights and Fundamental Freedoms.

Using the device (= storing data) without the user's consent violates their private sphere and, as such, their fundamental freedom. So to answer the question, yes, it applies to non-personal data. The highest court in Germany agrees in the case of Planet49, where it attempted to answer the same question (referred to as "Question 1(b)"):

(...) the answer to Question 1(b) is that Article 2(f) and Article 5(3) of Directive 2002/58, read in conjunction with Article 2(h) of Directive 95/46 and Article 4(11) and Article 6(1)(a) of Regulation 2016/679, are not to be interpreted differently according to whether or not the information stored or accessed on a website user’s terminal equipment is personal data within the meaning of Directive 95/46 and Regulation 2016/679.

Counting unique visitors

The issue with counting unique visitors is that you have to distinguish new users from returning users. There's only 2 ways to do that:

Assign every user an id and store it on initial request.
Store some flag to users who visit your site.

The first option violates GDPR as it requires you to process personal data (a unique identifier), and the second option violates the ePrivacy Directive as you're storing data onto the user's device if you don't show a cookie banner.

service	possible violation	relevant legislation
Phantom	assigns unique id: hash from ip, user agent	GDPR
Plausible	assigns unique id: hash from ip, user agent	GDPR
PostHog	assigns unique id + storage before consent	GDPR, ePrivacy
Umami	assigns unique id: hash from ip, user agent	GDPR
Vercel	assigns unique id: hash from ip, user agent	GDPR

It's also possible sending requests to third party APIs, so just using third party analytics, may be a violation of GDPR as you're exposing the user's IP address without their consent.

The only leeway here is legitimate interests, as mentioned before. Do you have legitimate interests in tracking unique visitors, and solely that? It's likely you just want to see the number of visitors to your site, and since you can already track interests and traffic via page views, I do not think it applies here.

Matomo

Matomo claims its no-consent cookie based configuration is approved by CNIL, France's data privacy regulatory body. While this is true, as CNIL considers some analytics cookies exempt from requiring consent under certain conditions, this is only applicable to France.

Fathom

Fanthom claims its customers use legitimate interests as their basis for handling IP addresses (personal data):

Processing personal data (IP address & User-Agent as per the GDPR) is not an issue, and the GDPR offers six lawful bases for doing so. Our customers rely on legitimate interest, and there is no risk to the data subject, and we ensure their data is anonymized.

However, as stated above, I do not think legitimate interests apply here, and Fanthom does not elaborate further. It also wrongly claims that hashing counts as anonymization and that GDPR may not apply, when it should be considered pseudonymization and the resulting data is still considered personal data.

Now what?

So, what options are left? Well, not a lot to be honest. For me, I intend to only "track" users from non-EU users and guesstimate total unique visitors by comparing it with total views. You can use "legitimate interests" if you want, but is it really worth thinking about and writing legal stuff?

There is hope though. The European Commission is considering replacing the old ePrivacy Directive, the directive prohibiting all non-essential cookies. Among the many planned changes, it'll allow some cookies for analytics purposes. Unfortunately, it might a take while...

Other things to consider

Here are some important things from GDPR that isn't related to analytics.

Responsibility

The responsibility to ensure the user's personal data is protected is placed on the controller, not the processor. The controller is the one who controls what data is processed by itself and processors, who process the data on behalf of the controller. If you're using Google Analytics, for example, you are the controller while Google is the processor.

Data transfer

Personal data must not be transferred to third countries unless certain conditions are met. Data can be transferred to countries that the EU has deemed to have adequate level of protection, including the United Kingdom and Canada (Article 45). Notably, the United States is not included. Alternatively, individual corporation are required to implement Standard Contractual Clauses (SCC) and/or an adequate safe guard as an alternative (Article 47). Those should be already covered if you host on Cloudflare and Vercel.

You may be allowed in the absence of the requirement above if they meet certain conditions, including consent, contractual obligation, and legitimate interest (Article 49).

Users should be informed of any international data transfer.

Announcing Lucia 1.0 - A simple and flexible auth library with support for multiple databases and frameworks

pilcrowOnPaper — Sun, 09 Apr 2023 14:38:44 +0000

I'm super excited to announce Lucia 1.0! This has been a long time coming and I still can't believe how much support the project had over the development. It now has over 800 Github stars and nearly 3,000 NPM weekly downloads!

Lucia is a server-side authentication library for TypeScript that aims to be unintrusive, straightforward, and flexible. At its core, it’s a library for managing users and sessions, providing the building blocks for setting up auth just how you want. Database adapters allow Lucia to be used with any modern ORMs/databases and integration packages make it easy to implement things like OAuth. Unlike Auth.js, it's much more low-level and simple, giving you full control of auth.

Key features:

Session based auth
Support for popular databases/ORMs
OAuth support
Multiple auth methods with keys
Email verification links and OTPs with tokens

Docs (I've worked super hard on this!): https://lucia-auth.com/?framework=sveltekit
Repo: https://github.com/pilcrowOnPaper/lucia

Working with Lucia

A simple example for email/password auth:

const user = await auth.createUser({
    // how to identify user for authentication?
    primaryKey: {
        providerId: "email", // using email
        providerUserId: "user@example.com", // email to use
        password: "123456"
    },
    // custom attributes
    attributes: {
        email: "user@example.com"
    }
});
const session = await auth.createSession(user.userId);
const sessionCookie = auth.createSessionCookie(session);

You can see that Lucia provides basic primitives that you can use however you want to implement your own auth.

Concepts of Lucia

Aside from users (which should be obvious), there's 2 other key concepts: Sessions and keys. One you understand the 3 concepts of Lucia, it should be pretty easy to use it.

Sessions

Sessions are how you validate and keep track of users. You create new sessions for a user and store the id of the session to the user’s browser or device. To validate a session, you can compare the session id stored in the client and the database.

Keys

When authenticating users (log in), you get the user data from an external provider, such as the email from the user’s input or the Github user id for social login. Keys allow you to link such external data from a provider with Lucia users stored in your database. This type of key can hold a password, which will be hashed and can be validated with Lucia’s API. This is mainly for implementing password logins.

For example, for email/password, “email” can be the provider id, the user’s email can be the provider user id, and the user’s password can be stored as the key’s password. For Github OAuth, “github” can be the provider id and the user’s GitHub user id can be the provider user id.

Preloading Google Fonts

pilcrowOnPaper — Wed, 22 Mar 2023 08:22:35 +0000

Google Fonts is one of the easiest way to customize your website. Pick your fonts, add few lines of html, and boom, you're done:

<head>
    <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin />
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
    <link
        href="https://fonts.googleapis.com/css2?family=Roboto&display=swap"
        rel="stylesheet"
    />
</head>

Well, until you realize that your fonts aren't getting applied immediately, only happening after the whole page has been loaded. That improves page speed but isn't the best design wise (and to some extent, UX wise).

We can tell the browser to load assets before load with rel="preload":

<head>
    <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin />
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
     <link
        href="https://fonts.googleapis.com/css2?family=Roboto&display=swap"
        rel="preload"
        as="style"
        crossorigin
    />
    <link
        href="https://fonts.googleapis.com/css2?family=Roboto&display=swap"
        rel="stylesheet"
    />
</head>

Make sure to add both of the <link/> tag.

But this doesn't solve our problem just yet. We're preloading a stylesheet, but that stylesheet also imports fonts. We have to preload those as well.

If you visit https://fonts.googleapis.com/css2?family=Roboto&display=swap (the stylesheet location), you'll see a list of font-face declaration:

/* latin */
@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/roboto/v30/KFOmCnqEu92Fr1Mu4mxKKTU1Kg.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

That url inside url(https://fonts.gstatic.com/s/roboto/v30/KFOmCnqEu92Fr1Mu4mxKKTU1Kg.woff2) is the actual font and we can preload those as well:

<head>
      <!-- previous stuff -->
     <link
          rel="preload"
         href="https://fonts.gstatic.com/s/roboto/v30/KFOmCnqEu92Fr1Mu4mxKKTU1Kg.woff2"
         crossorigin
         as="font"
         type="font/woff2"
    />
</head>

You only have to do this for @font-face with a /* latin */ or /* latin-ext */ comment since those are the font files for the English alphabet.

This won't be perfect but it should work 95% of the time.

Cheers!

Introducing Lucia: A simple, flexible, and type-safe authentication library for Next.js, SvelteKit, and beyond

pilcrowOnPaper — Mon, 07 Nov 2022 11:50:30 +0000

Hi!

Over the past few months, I've been working on a library called Lucia. At its core, it's a user and session management library that provides an abstraction layer between your app and your database. Using it, you can create users, creates sessions for those users, and validate those sessions. But, it doesn't try to do more than that; you have to create your own sign-in forms and APIs, and handle things like email verification by yourself. But, because of that, how you use Lucia is totally up to you.

That said though, we do provide integration packages to make it easier to use with your favorite frameworks. Right now, we directly support Next.js, SvelteKit, and Astro SSR. We also have a package for handling OAuth. I think it's important to keep the core package simple and focused, and give you the option to trade some flexibility for an easier experience. It shouldn't be the other way around.

And this is what makes it different from existing solutions like Supabase auth, SuperTokens, or NextAuth. It isn't a complete solution, and it never tries to be so. It allows you to make something that fits your app's need and build on top of it. There's no hidden configurations or callbacks that forces you to use jank solutions.

Repo: https://github.com/pilcrowOnPaper/lucia-auth

Docs: https://lucia-auth.vercel.app

Features!

Aside from the obvious (own your data, secure, MIT license, etc):

Supports any databases

We take a similar approach to NextAuth, where we provide database adapters. We currently provide adapters for Prisma, Supabase, MongoDB, and Redis. We also have an extensive documentation on creating your own adapters and provide a package for testing them.

Custom user attributes

Similar to Firebase custom claims, you can set any user attributes to the user. By default, only the user id is required to be stored in your database, and you can add additional columns to it (like username, is_verified, etc).

Low-level control

Since Lucia is the layer between your database and app, it provides everything you need to interact with user and session data. Just a single method to update user data and password, invalidate sessions, create session cookies, etc.

Session ids

This is less a feature but more of the inner-workings. To not over-complicate the APIs, we only support session ids (and not JWTs). While JWT + access/refresh tokens may be a better fit in some use cases, we think you can't go wrong using session ids.

Code samples

Create user and session

// create a user using "email" auth method
const user = await auth.createUser("email", userEmail, {
  password: userPassword, // will hash it for you
  attributes: {
    username: userUsername
  }
});
const session = await auth.createSession(user.userId);
const sessionCookies = auth.createSessionCookies(session);

Validate requests

// will also renew sessions if expired
const session = await auth.validateRequest(request, setSession);

Or using Next.js integration:

const authRequest = new AuthRequest(auth, ctx.req, ctx.res);
const session = await authRequest.getSession();

OAuth

const callbackCode = url.searchParams.get("code");
const { existingUser, providerUser, createUser } = await githubAuth.validateCallback(callbackCode);
// create a new user for first-time users
const user = existingUser || (await createUser({
  username: providerUser.login;
});

If you have any questions while using Lucia, feel free to ask us on GitHub or Discord. Cheers!

SvelteKit + Lucia: Email and password authentication

pilcrowOnPaper — Fri, 22 Jul 2022 14:09:00 +0000

I recently released Lucia, an authentication library for SvelteKit. It handles the bulk of the authentication process and makes it easier to implement authentication to your SvelteKit project. Unlike other libraries, it isn't an out-of-the-box authentication library and requires a bit more time to start, but can be fully customized once you know the basics. It doesn't just create tokens, it uses short-lived access tokens with refresh tokens, auto-refreshes them, implements rotating refresh token, and detects refresh token theft.

This guide will cover how to implement email and password authentication, at least the sign in part of it. I'm going to gloss over some parts that are better explained in the documentation.

Setup

The basic set up is explained here.

Database

Refer to adapters for database-specific explanation. Add a new column called email (text/varchar) where the values are unique.

Frontend

Send a POST request to the signup or login endpoint with a JSON body.

const signup = async () => {
    await fetch("/api/signup", {
        method: "POST",
        body: JSON.stringify({
            email,
            password,
        }),
    });
};

Sign up

Create routes/api/signup.ts and accept a POST request. Get the email and password from the body data.

import type { RequestHandler } from "@sveltejs/kit";
import { auth } from "$lib/lucia";

export const POST: RequestHandler = async ({ request }) => {
    const { email, password } = await request.json();
    if (!email || !password) {
        return {
            status: 400,
        };
    }
};

Create a new user

Create a new user using createUser using the auth id of email and an identifier of email. Auth ids represent the authentication method used (for Github OAuth, "github"), and identifier represents the user within that method (usernames or email for GitHub). It's used to identify users and not to store user data (if you need to store the user's email, create a email column in your db).
Refer to the overview page for an explanation on auth ids and identifiers.

Save the user's password using the password options and the user's email using user_data. Set the cookies (refresh, access, and fingerprint token) and redirect the user in the response. The AUTH_DUPLICATE_IDENTIFER_TOKEN error is thrown when a user tries to create a new account using the same auth id and identifer (in this case, email).

try {
    const createUser = await auth.createUser("email", email, {
        password,
        user_data: {
            email,
        },
    });
    return {
        status: 302,
        headers: {
            "set-cookie": createUser.cookies,
            location: "/",
        },
    };
} catch (e) {
    const error = e as Error;
    if (
        error.message === "AUTH_DUPLICATE_IDENTIFER_TOKEN" ||
        error.message === "AUTH_DUPLICATE_USER_DATA"
    ) {
        return {
            status: 400,
            body: JSON.stringify({
                error: "Email already in use.",
            }),
        };
    }
    return {
        status: 500,
        body: JSON.stringify({
            error: "Unknown error.",
        }),
    };
}

Sign in

Create routes/api/login.ts and accept a POST request. Get the user's email and password from the body.

import type { RequestHandler } from "@sveltejs/kit";
import { auth } from "$lib/lucia";

export const POST: RequestHandler = async ({ request }) => {
    const form = await request.formData();
    const email = form.get("email")?.toString();
    const password = form.get("password")?.toString();
    if (!email || !password) {
        return {
            status: 400,
        };
    }
};

Authenticate a user

Authenticate the user using authenticateUser, which will require a password in the third parameter. The auth id should be the same as the one used when creating the user. It's important to NOT tell the user if the email was incorrect or if the password was incorrect.

try {
    const authenticateUser = await auth.authenticateUser(
        "email",
        email,
        password
    );
    return {
        status: 302,
        headers: {
            "set-cookie": createUser.cookies,
            location: "/",
        },
    };
} catch (e) {
    const error = e as Error;
    if (
        error.message === "AUTH_INVALID_IDENTIFIER_TOKEN" ||
        error.message === "AUTH_INVALID_PASSWORD"
    ) {
        return {
            status: 400,
            body: JSON.stringify({
                error: "Incorrect email or password.",
            }),
        };
    }
    // database connection error
    return {
        status: 500,
        body: JSON.stringify({
            error: "Unknown error.",
        }),
    };
}

That's it. Other parts of Lucia and authentication (like token refresh and protected routes) are explained in getting started.

Reddit API is such a mess

pilcrowOnPaper — Sat, 14 May 2022 16:19:59 +0000

I really hate both reddit.com and its mobile app, and was looking for an alternative. I just wanted something minimalistic and lightweight. Apollo, Slide, Narwhal, Comment, BaconReader, photon-reddit... I tried everything I could find and none of them felt nice to use. So, I thought I could make own, how hard can that be? Fetch some data from the API and display it.

Oh, how wrong I was.

First of all, the documentation, uh, leaves a lot to be desired. There's no response body example so I had to call each of them before using them. Some parameters are just left unacknowledged.

My biggest complaint is that there's no easy way to tell if the post is a text, image, GIF, video, embedded video, or embedded image.

is_self means it's a text. is_video means it's a video, but not, since you also have to check post_hint === 'rich:video' and domain === 'v.redd.it'. But even if you know what kind of media it is, getting the media URL is in its self is a hurdle. Sometimes you have check media_embed, maybe media_metadata, or preview.images[0]. Oh, and media.reddit_video.

And the inconsistency.

Sometimes nsfw items are marked as over_18 and other times as over18. Some key-values are missing depending on which endpoint you call, like description from users missing when you search users by a query. Icon URLs are included in either community_icon or icon_img.

And finally, getting the next batch of items.

Reddit API only gives you a max 100 or so items for each API call. If you want to get the next batch of posts, you have you use the after id provided by the previous call. Fine, it works. But, how do you get the next batch of comments in a comment section? Well, the API returns you all the comment ID of comments that weren't included in the first batch. You can get the content of each comment using their ids, but replies to those comments are missing. There's an endpoint that gives you the comment with the replies, but it's missing crucial information like who made them. And don't forget that the object that includes that list of comment ids are inside an array of totally different comment-objects.

There are API wrappers like Snoowrap but I am not willing to see any more response body from reddit.com.

So, my solution?

Create an API wrapper that does all the work for you and returns a clean response body without the fat. Still very much in progress though: https://github.com/pilcrowOnPaper/corsica.

SvelteKit JWT authentication tutorial

pilcrowOnPaper — Thu, 31 Mar 2022 06:58:00 +0000

Update! I created an authentication library called Lucia to solve this problem. It's much more secure than the method use here (but still very flexible) so check it out!

Hello, this article will cover how to implement authentication into your SvelteKit project. This will be a JWT authentication with refresh tokens for added security. We will use Supabase as the database (PostgreSQL) but the basics should be the same.

Github repository

Before we start...

Why?

In my previous post and video, I showed how to implement Firebase authentication. But, at that point, there’s no real advantages of using those services, especially if you don’t need Firestore’s realtime updates. With Supabase offering a generous free tier and a pretty good database, it likely is simpler to create your own.

How will it work?

When a user signs up, we will save the user’s info and password into our database. We will also generate a refresh token and save it both locally and in the database. We will create a JWT token with user info and save it as a cookie. This JWT token will expire in 15 minutes. When it expires, we will check if a refresh token exists, and compare it with the one saved inside our database. If it matches, we can create a new JWT token. With this system, you can revoke a user’s access to your website by changing the refresh token saved in the database (though it may take up to 15 minutes).

Finally, why Supabase and not Firebase? Personally, I felt the unlimited read/writes were much more important than storage size when working with a free tier. But, any database should work.

I. Set up

This project will have 3 pages:

index.svelte : Protected page
signin.svelte : Sign in page
signup.svelte : Sign up page

And here’s the packages we’ll be using:

supabase
bcrypt : For hashing passwords
crypto : For generating user ids (UUID)
jsonwebtoken : For creating JWT
cookie : For parsing cookies in the server

II. Supabase

Create a new project. Now, create a new table called users (All non-null) :

id : int8, unique, isIdentity
email : varchar, unique
password : text
username : varchar, unique
user_id : uuid, unique
refresh_token : text

Go to settings > api. Copy your service_role and URL. Create supabase-admin.ts :

import { createClient } from '@supabase/supabase-js';

export const admin = createClient(
    'URL',
    'service_role'
);

If you’re using Supabase in your front end, DO NOT use this client (admin) for it. Create a new client using your anon key.

III. Creating an account

Create a new endpoint (/api/create-user.ts). This will be for a POST request and will require email, password, and username as its body.

export const post: RequestHandler = async (event) => {
    const body = (await event.request.json()) as Body;
    if (!body.email || !body.password || !body.username) return returnError(400, 'Invalid request');
    if (!validateEmail(body.email) || body.username.length < 4 || body.password.length < 6)
        return returnError(400, 'Bad request');
}

By the way, returnError() is just to make the code cleaner. And validateEmail() just checks if the input string has @ inside it, since (to my limited knowledge) we can’t 100% check if an email is valid using regex.

export const returnError = (status: number, message: string): RequestHandlerOutput => {
    return {
        status,
        body: {
            message
        }
    };
};

Anyway, let’s make sure the email or username isn’t already in use.

const check_user = await admin
    .from('users')
    .select()
    .or(`email.eq.${body.email},username.eq.${body.username}`)
    .maybeSingle()
if (check_user.data) return returnError(405, 'User already exists');

Next, hash the user’s password and create a new user id and refresh token, which will be saved in our database.

const salt = await bcrypt.genSalt(10);
const hash = await bcrypt.hash(body.password, salt);
const user_id = randomUUID();
// import { randomUUID } from 'crypto';
const refresh_token = randomUUID();
const create_user = await admin.from('users').insert([
    {
        email: body.email,
        username: body.username,
        password: hash,
        user_id,
        refresh_token
    }
]);
if (create_user.error) return returnError(500, create_user.statusText);

Finally, generate a new JWT token. Make sure to pick something random for key. Make sure to only set secure if you’re only in production (localhost is http, not https).

const user = {
    username: body.username,
    user_id,
    email: body.email
};
const secure = dev ? '' : ' Secure;';
// import * as jwt from 'jsonwebtoken';
// expires in 15 minutes
const token = jwt.sign(user, key, { expiresIn: `${15 * 60 * 1000}` });
return {
    status: 200,
    headers: {
        // import { dev } from '$app/env';
        // const secure = dev ? '' : ' Secure;';
        'set-cookie': [
            // expires in 90 days
            `refresh_token=${refresh_token}; Max-Age=${30 * 24 * 60 * 60}; Path=/; ${secure} HttpOnly`,
            `token=${token}; Max-Age=${15 * 60}; Path=/;${secure} HttpOnly`
        ]
    }
};

In our signup page, we can call a POST request and redirect our user if it succeeds. Make sure to use window.location.href instead of goto() or else the change (setting the cookie) won’t be implemented.

const signUp = async () => {
    const response = await fetch('/api/create-user', {
        method: 'POST',
        credentials: 'same-origin',
        body: JSON.stringify({
            email,
            username,
            password
        })
    });
    if (response.ok) {
        window.location.href = '/';
    }
};

IV. Signing in

We will handle the sign in in /api/signin.ts. This time, we will allow the user to user either their username or email. To do that, we can check if it is a valid username or email, and check if the same username or email exists.

export const post: RequestHandler = async (event) => {
    const body = (await event.request.json()) as Body;
    if (!body.email_username || !body.password) return returnError(400, 'Invalid request');
    const valid_email = body.email_username.includes('@') && validateEmail(body.email_username);
    const valid_username = !body.email_username.includes('@') && body.email_username.length > 3;
    if ((!valid_email && !valid_username) || body.password.length < 6)
        return returnError(400, 'Bad request');
    const getUser = await admin
        .from('users')
        .select()
        .or(`username.eq.${body.email_username},email.eq.${body.email_username}`)
        .maybeSingle()
    if (!getUser.data) return returnError(405, 'User does not exist');
}

Next, we will compare the input and the saved password.

const user_data = getUser.data as Users_Table;
const authenticated = await bcrypt.compare(body.password, user_data.password);
if (!authenticated) return returnError(401, 'Incorrect password');

And finally, do the same thing as creating a new account.

const refresh_token = user_data.refresh_token;
const user = {
    username: user_data.username,
    user_id: user_data.user_id,
    email: user_data.email
};
const token = jwt.sign(user, key, { expiresIn: `${expiresIn * 60 * 1000}` });
return {
    status: 200,
    headers: {
        'set-cookie': [
            `refresh_token=${refresh_token}; Max-Age=${refresh_token_expiresIn * 24 * 60 * 60}; Path=/; ${secure} HttpOnly`,
            `token=${token}; Max-Age=${15 * 60}; Path=/;${secure} HttpOnly`
        ]
    }
};

V. Authenticating users

While we can use hooks to read the JWT token (like in this article I wrote), we can’t generate (and set) a new JWT token with it. So, we will call an endpoint, which will read the cookie and validate it, and return the user’s data if they exist. This endpoint will also handle refreshing sessions. This endpoint will be called /api/auth.ts.

We can get the cookie, if valid, return the user’s data. If it isn’t valid, verify() will throw an error.

export const get: RequestHandler = async (event) => {
    const { token, refresh_token } = cookie.parse(event.request.headers.get('cookie') || '');
    try {
        const user = jwt.verify(token, key) as Record<any, any>;
        return {
            status: 200,
            body: user
        };
    } catch {
        // invalid or expired token
    }
}

If the JWT token has expired, we can validate the refresh token with the one in our database. If it is the same, we can create a new JWT token.

if (!refresh_token) return returnError(401, 'Unauthorized user');
const getUser = await admin.from('users').select().eq("refresh_token", refresh_token).maybeSingle()
if (!getUser.data) {
    // remove invalid refresh token
    return {
        status: 401,
        headers: {
            'set-cookie': [
                `refresh_token=; Max-Age=0; Path=/;${secure} HttpOnly`
            ]
        },
    }
}
const user_data = getUser.data as Users_Table;
const new_user = {
    username: user_data.username,
    user_id: user_data.user_id,
    email: user_data.email
};
const token = jwt.sign(new_user, key, { expiresIn: `${15 * 60 * 1000}` });
return {
    status: 200,
    headers: {
        'set-cookie': [
            `token=${token}; Max-Age=${15 * 60}; Path=/;${secure} HttpOnly`
        ]
    },
};

VI. Authorizing users

To authorize a user, we can check send a request to /api/auth in the load function.

// index.sve;te
// inside <script context="module" lang="ts"/>
export const load: Load = async (input) => {
    const response = await input.fetch('/api/auth');
    const user = (await response.json()) as Session;
    if (!user.user_id) {
        // user doesn't exist
        return {
            status: 302,
            redirect: '/signin'
        };
    }
    return {
        props: {
            user
        }
    };
};

VII. Signing out

To sign out, just delete the user’s JWT and refresh token.

// /api/signout.ts
export const post : RequestHandler = async () => {
    return {
    status: 200,
        headers: {
            'set-cookie': [
                `refresh_token=; Max-Age=0; Path=/; ${secure} HttpOnly`,
                `token=; Max-Age=0; Path=/;${secure} HttpOnly`
            ]
        }
    };
};

VIII. Revoking user access

To revoke a user’s access, simply change the user’s refresh token in the database. Keep in mind that the user will stay logged in for up to 15 minutes (until the JWT expires).

const new_refresh_token = randomUUID();
await admin.from('users').update({ refresh_token: new_refresh_token }).eq("refresh_token", refresh_token);

This is the basics, but if you understood this, implementing profile updates and other features should be pretty straight forward. Maybe an article about email verification could be interesting...

Saving users’ preferences in SvelteKit

pilcrowOnPaper — Wed, 30 Mar 2022 12:19:00 +0000

This is a quick tutorial on saving users preferences in SvelteKit.

There are 2 ways one might approach this. First is implementing an auth system. But, that might be overkill so another way is to save it locally. Let’s go with that.

So something like this... (I’ll be using this package to simplify the code)

let name : string

const saveName = () => {
    Cookie.set("name", name)
}

<input bind:value={name}/>
<button on:click={saveName}>save</button>

Well, that was easy.

But a small problem arises when we want to display it.

onMount(() => {
    name = Cookie.get("name")
})

<p>{name}</p>

This works, but since we have to wait for document to load, we need to use onMount(). That means, there will be a split second after the page loads where name = undefined. This won’t be a big problem in this case, but if it were saving user’s light/dark theme preference, it’ll lead to a quite negative UX. This will also happen if we rely on something like Firebase auth, since it also has a dependency on window/document.

To solve this, we can read the cookie in the server before the page fully loads.

First, let’s read the cookie with hooks. This handle() function runs every time SvelteKit receives a request. We’ll use the cookie package to make cookie-parsing easier.

import * as cookie from 'cookie';

export const handle : Handle = async ({ event, resolve }) => {
    const { name } = cookie.parse(event.request.headers.get('cookie') || '') as Partial<{ name: string }>;
    if (name) {
        event.locals = { name };
    }
    return await resolve(event)
}

Next, we have to send this to the frontend. One way of doing it, is to use the session object, which can be read in the load function. We can set the session object using getSession(). Since event first passed the handle function, it includes name in locals.

export const getSession : GetSession = async (event) => {
    const { name } = event.locals as Partial<{ name: string }>;
    if (!name) return {};
    return { name };
}

Finally, we can get the session object in the load function like below.

export const load : Load = async ({ session }) => {
    const { name } = session as Partial<{ name: string }>
    return {
        props: {
            name
        }
    }
}

Here’s a simple project of mine that implements this:

URL: https://niagara.vercel.app

Github: https://github.com/pilcrowOnPaper/niagara

SvelteKit + Firebase: Authentication, protected routes, and persistent login

pilcrowOnPaper — Sat, 19 Feb 2022 11:06:47 +0000

Hi! I'm new to SvelteKit (and programming in general) but there seems to be a lack of tutorials/guides for SvelteKit so here's my contribution. We will create a server-rendered website with authentication and protected routes using firebase. At the end, we'll deploy to Vercel since many tutorials miss that part. (+Tailwind CSS so it'll look decent)

Before we start...

Why?

Of course there aren’t many resources on SvelteKit but more importantly, there’s even less resource on using Firebase with SSR. More specifically, Firebase’s auth tokens expire after an hour. And while Firebase does refresh them automatically, it only does it in the frontend. Say you have a website with 2 pages:

A login page where authenticated users are redirected to the member-only page
A member-only page where unauthenticated users are redirected to the login page

that has a system that saves the user’s firebase token as a cookie (JWT). If a user comes back after a while, the user will be sent back to the login page, wait a few seconds for the token to be refreshed by Firebase, and sent back to the member-only page. We want to avoid that.

How will it work?

So there will be 3 pages: a login, signup, and member-only page. When a user creates a new account, 2 cookies will be created. The first is an auth token, which will expire in an hour. The second is a refresh token that can be used to create new auth tokens. When a user tries to access a page, we will check the validity of the auth token, and if it’s expired, create a new one with the refresh token.

If you have, for example, set up Firestore security rules, you’ll still need to login the user using client-side Firebase. Fortunately, we can login using the auth token acquired from the backend.

Quick side-note(s)

If you wondered why we can’t just use onAuthStateChanged() , Firebase has a dependency on window. That means it only runs after the page is rendered. We want to check the user and get their data when SvelteKit is rendering the page in the server.

I. Set up

Create a skeleton SvelteKit project and add Tailwind CSS. Run npm run dev to make sure it's working. Add src/lib folder and we will out out js/ts files inside it.

We'll create 3 pages:

src/routes/index.svelte: member-only page
src/routes/login.svelte: login page
src/routes/signup.svelte: for new users

and your src folder should look something like this:



src
|-lib
|-routes
  |-__layout.svelte
  |-index.svelte
  |-login.svelte
  |-signup.svelte
|-app.css
|-app.dts
|-app.html

The login page will take 2 user inputs (email, passwors) and the signup page with take 3 inputs (username, email, password). You can add additional user data if you want. Here’s some screenshots for reference:

After that we will create 3 endpoints:

src/routes/api/auth.json.js: Authenticating the user
src/routes/api/new-user.json.js: Creating a new account
src/routes/api/signout.json.js: Signing out the user

II. Adding Firebase

Install firebase:



npm install firebase

If you haven’t done it yet, create a Firebase account and a new project. Enable Firebase authentication and email/password authentication in ‘Sign-in providers’. Go to (Settings) > ‘Project settings’ and copy your firebaseConfig. In a new folder called src/lib/firebase.js paste it like this:



import { initializeApp } from "firebase/app";
import { getAuth, setPersistence, browserSessionPersistence } from "firebase/auth"

const firebaseConfig = {
  apiKey: [API_KEY],
  authDomain: [AUTH_DOMAIN],
  projectId: [PROJECT_ID],
  storageBucket: [STORAGE_BUCKET],
  messagingSenderId: [MESSAGING_SENDER_ID],
  appId: [APP_ID]
};

const app = initializeApp(firebaseConfig, "CLIENT");
export const auth = getAuth(app)
setPersistence(auth, browserSessionPersistence)

You don’t have to hide it but if you’re worried use env variables. Make sure to name your app CLIENT since we will initialize another app. I also set persistence to browserSessionPersistence just in case to prevent unintended behavior. It makes your client side auth session (the one mentioned in ‘How does it work?’ and not the entire auth session) only last until the user closes their browser.

Next we’ll set up Firebase Admin. (Settings) > ‘Project settings’ > ‘Service accounts’ and click ‘Generate new private key’ to download JSON with you config. Add that JSON file in your project file and initialize it in src/lib/firebase-admin.json.



import admin from "firebase-admin"

import * as credential from "[PATH_TO_JSON_FILE.json]"

admin.initializeApp({
    credential: admin.credential.cert(credential)
});

export const auth = admin.auth

III. Creating a new account

When a user creates a new account, send their username, email, and password in a POST request to ‘/api/new-user.json’. The endpoint will:

Create a new account
Set custom claims of the user (custom claims are user data that you can add)
Sign in as the user
Create a custom token
Set custom token and refresh token as cookie

You’ll need to get an API key from ‘Web API key’ in (Setting) > ‘Project settings’.

src/routes/api/new-user/json.js:



import { dev } from '$app/env';
import { auth } from '$lib/firebase-admin';

const key = [WEB_API_KEY]
const secure = dev ? '' : ' Secure;'

export const post = async (event) => {
    const { email, password, username } = await event.request.json()
    const userRecord = await auth().createUser({
        email,
        password,
        displayName: username
    })
    const uid = userRecord.uid
    await auth().setCustomUserClaims(uid, { 'early_access': true })
    const signIn_res = await fetch(`https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=${key}`, {
        method: 'POST',
        headers: { 'content-type': 'application/json' },
        body: JSON.stringify({ email, password, 'returnSecureToken': true })
    })
    if (!signIn_res.ok) return { status: signIn_res.status}
    const { refreshToken } = await signIn_res.json()
    const customToken = await auth().createCustomToken(uid)
    return {
        status: 200,
        headers: {
            'set-cookie': [
                `customToken=${customToken}; Max-Age=${60 * 55}; Path=/;${secure} HttpOnly`,
                `refreshToken=${refreshToken}; Max-Age=${60 * 60 * 24 * 30}; Path=/;${secure} HttpOnly`,
            ],
            'cache-control': 'no-store'
        }
    }
}

‘identitytoolkit.googleapis.com’ is Firebase/Google’s authentication REST API. There’s 3 token types of tokens:

Custom token (customToken): This is an auth token that can be verified by Firebase to authenticate a user, and can be used to login the user in the client. Can be created from the user’s UID. Expires in an hour.
Id Token (idToken): This is a token that is used to interact with the REST api. This is usually hidden when using Firebase Admin. Can also be used the authenticate the user. This can be acquired from requesting the user’s data using the REST api (eg. signIn_res). Expires in an hour.
Refresh token: This is an auth token that can be exchanged to create a new Id Token (which allows us to create a new custom token). Expires in about a year.

Cookies must be a ‘http-only’ cookie and ‘Secure’ (only in production) for security. This makes sure your servers are the only thing that can read and write your cookie.

In src/routes/signup.svelte :



import { goto } from '$app/navigation';

let username = '';
let email = '';
let password = '';
let error = '';

const signup = async () => {
    if (username.length < 4) return (error = 'username must be at least 4 characters long');
    if (!email.includes('@') || !email.includes('.')) return (error = 'invalid email');
    if (password.length < 6) return (error = 'password must be at least 6 characters long');
    error = '';
    const signUp_res = await fetch(`/api/new-user.json`, {
        method: 'POST',
        headers: new Headers({ 'Content-Type': 'application/json' }),
        credentials: 'same-origin',
        body: JSON.stringify({ email, password, username })
    });
    if (!signUp_res.ok) return (error = 'An error occured; please try again.');
    goto('/');
};

III. Login

To login, send a POST request with the user’s email and password to ‘/api/auth.json’ .

Login
Create a new custom token
Set the custom token and the refresh token as cookies

In the code below, the refresh token is set to expire in 30 days (=

src/routes/api/auth.json.js:



import { dev } from '$app/env';
import { auth } from '$lib/firebase-admin';

import * as cookie from 'cookie'

const key = [WEB_API_KEY]
const secure = dev ? '' : ' Secure;'

export const post = async (event) => {
    const { email, password } = await event.request.json()
    const signIn_res = await fetch(`https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=${key}`, {
        method: 'POST',
        headers: { 'content-type': 'application/json' },
        body: JSON.stringify({ email, password, returnSecureToken: true })
    })
    if (!signIn_res.ok) return { status: signIn_res.status }
    const { refreshToken, localId } = await signIn_res.json()
    const customToken = await auth().createCustomToken(localId)
    return {
        status: 200,
        headers: {
            // Max-age : seconds
            'set-cookie': [
                `refreshToken=${refreshToken}; Max-Age=${60 * 60 * 24 * 30}; Path=/;${secure} HttpOnly`,
                `customToken=${customToken}; Max-Age=${60 * 55}; Path=/;${secure} HttpOnly`,
            ],
            'cache-control': 'no-store'
        },
    }
}

src/routes/api/login.svelte:



import { goto } from '$app/navigation';

let email = '';
let password = '';
let error = '';

const login = async () => {
    if (!email.includes('@') || !email.includes('.')) return (error = 'invalid email');
    if (password.length < 6) return (error = 'password must be at least 6 characters long');
    error = '';
    const signIn_res = await fetch(`/api/auth.json`, {
        method: 'POST',
        headers: new Headers({ 'Content-Type': 'application/json' }),
        credentials: 'same-origin',
        body: JSON.stringify({ email, password })
    });
    if (!signIn_res.ok) return (error = 'User does not exist or incorrect password');
    goto('/');
};

I also added a few lines of code to check for obvious mistakes.

IV. Authenticating users

To authenticate a user, we will send a GET request to ‘/api/auth.json’.

Verify the user’s custom token
If verified, send the user’s data in the body
If not, delete the the user’s refresh token

src/routes/api/auth.json.js:



export const get = async (event) => {
    let { refreshToken, customToken } = cookie.parse(event.request.headers.get('cookie') || '')
    if (!refreshToken) return return401()
    let headers = {}
    let user = {}
    try {
        if (!customToken) throw new Error()
        user = await auth().verifyIdToken(customToken)
    } catch (e) {
        return401()
    }
    return {
        status: 200,
        body: {
            user
        },
        headers
    }
}

const return401 = () => {
    return {
        status: 401,
        headers: {
            'set-cookie': `refreshToken=; Max-Age=0; Path=/;${secure} HttpOnly`,
            'cache-control': 'no-store'
        }
    }
}

But, this is inadequate as this won’t work when the custom token has expired. When the token has expired, auth().verifyIdToken() will throw an error.

Get a new id token from the refresh token using the REST api
Verify the newly acquired id token to get the user’s data
Using the UID acquired from 2, create a new custom token
Override the existing cookie and return the user’s data in the body

We also get a new custom token from step 1, but it will be the same unless it has expired. We send an error (=logout) if it is different because, at the moment, SvelteKit can only set 1 cookie in the load function.

src/routes/api/auth.json.js



export const get = async (event) => {
    let { refreshToken, customToken } = cookie.parse(event.request.headers.get('cookie') || '')
    if (!refreshToken) return return401()
    let headers = {}
    let user = {}
    try {
        if (!customToken) throw new Error()
        user = await auth().verifyIdToken(customToken)
    } catch (e) {
        // if token is expired, exchange refresh token for new token
        const refresh_res = await fetch(`https://identitytoolkit.googleapis.com/v1/token?key=${key}`, {
            method: 'POST',
            headers: { 'content-type': 'application/json' },
            body: JSON.stringify({ grant_type: 'refresh_token', 'refresh_token': refreshToken })
        })
        if (!refresh_res.ok) return return401()
        const tokens = await refresh_res.json()
        const idToken = tokens['id_token']
        if (tokens['refresh_token'] !== refreshToken) return return401()
        try {
            user = await auth().verifyIdToken(idToken)
            customToken = await auth().createCustomToken(user.uid)
            headers = {
                'set-cookie': [
                    `customToken=${customToken}; Max-Age=${60 * 55}; Path=/;${secure} HttpOnly;`,
                ],
                'cache-control': 'no-store'
            }
        } catch (e) {
            return401()
        }
    }
    return {
        status: 200,
        body: {
            user,
                        customToken
        },
        headers
    }
}

V. Authorizing users

To redirect unauthenticated users in ‘/’, we can create a load function that sends a GET request to ‘/api/auth.json’. The load function is a function inside context="module" script and runs before the page renders. We also need to import and use SvelteKit’s fetch() since the usual fetch() doesn’t work as the load function runs before the page loads.

Get the user’s data from ‘/api/auth.json’
If unauthenticated, it will return a 401 status and redirect to ‘/login’ (make sure to add a 300 status!)
Check for custom claims if necessary
return the user’s data as props



<script context="module">
    export const load = async ({ fetch }) => {
        const auth_res = await fetch('/api/auth.json');
        if (!auth_res.ok) return { status: 302, redirect: '/login' };
        const auth = await auth_res.json();
        return {
            props: {
                user: auth.user
                customToken: auth.customToken
            }
        };
    };
</script>

For the login/signup page where you only want unauthenticated users, replace if (!auth_res.ok) {} to (auth_res.ok) {}.

V. Signing out

To sign the user out, we just need to delete the cookies, which is possible setting the Max-Age to 0.

src/routes/api/signout.json.js:



import { dev } from '$app/env';

export const post = async () => {
    const secure = dev ? '' : ' Secure;'
    return {
        status: 200,
        headers: {
            'set-cookie': [
                `customToken=_; Max-Age=0; Path=/;${secure} HttpOnly`,
                `refreshToken=_; Max-Age=0; Path=/;${secure} HttpOnly`,
            ],
            'cache-control': 'no-store'
        },
    }
}

And you can sign out by calling this function:



const logout = async () => {
    await auth.signOut();
    await fetch(`/api/signout.json`, {
        method: 'POST',
        headers: new Headers({ 'Content-Type': 'application/json' }),
        credentials: 'same-origin'
    });
    goto('/login');
};

Using Firestore

If you’re going to use Firestore with security rules, you’ll need to login using the custom token (customToken prop).



export let customToken = ""
import { signInWithCustomToken } from 'firebase/auth';

const initialize = async () => {
        const userCredential = await signInWithCustomToken(auth, customToken)
        // firestore stuff here
};

If a user stays for more than an hour and the token expires, firebase will automatically renew the user’s session. This won’t be an issue as the refresh token won’t change.

Deploying to Vercel

It’s very simple to deploy to Vercel, and while other services like Netlify exists, Vercel is faster (at least where I live). Anyway, they’re both easy to use and SvelteKit supports many other platforms.



npm i @sveltejs/adapter-vercel

Edit your svelte.config.js :



import vercel from '@sveltejs/adapter-vercel';

const config = {
    //...
    kit: {
        adapter: vercel()
    }
};

Upload to Github and connect Vercel to your repository. Remember to add you domain to Firebase Auth (Authentication > Sign in method > Authorized domain). That should work!

Thanks for reading!