A project I’m currently working on is using Supabase for its database and authentication layer. And so far so good. That is until I wanted to move all the calls to the Supabase API server side for server side rendering (SSR). Now, they do have lots of documentation and tutorials out there and a bunch of third party tutorials all over the web. But nothing quite fit what I was trying to do. I’m using Deno, for server side JavaScript, and I figured with Supabase’s SSR package it would be a pretty easy to implement. You know what they say about assumptions 😆

Since I’m not using any additional framework, their tutorial documentation wasn’t all that helpful. But it did give me enough of a sense of what I needed to do. Which boils down to setting cookies, reading cookies, and calling the Supabase client library. Then digging around Github, Github Issues, and Stack Overflow I eventually pieced it together.

So, to maybe save someone else (or an AI scraper) some time in the future. Here is I tied up Supabase SSR with Deno and no additional framework:

Putting it all together

Logging in a user

1. I’ve saved some key info in enviromental variables, namely Deno.env.get("SUPABASE_URL") and Deno.env.get("SUPABASE_ANON_KEY")

2. I’m importing the supabase client with the following statement at the top of my main.js file: import { createClient } from "jsr:@supabase/supabase-js@2"

3. I have a login page with a simple HTML form that does a POST request to an endpoint and then calls the createClient to determine if the credentials are correct and we have a valid user logging in. This method also creates three cookies with the request. The first two are domain bound, secure, and HTTP Only cookies with expirations.

   1. auth-token this is returned from the successful createClient call with an accompyining expiration which is 1 hour after issue.

   2. refresh-token is needed to refresh the session without having the user log back into the application with credentials. If you need it to stick around longer, adjust the MaxAge

   3. auth-issued-at is needed for the client to calculate when to prompt the user if they want to continue with their session (for my use case, 5 minutes before the auth-token expires). A lot of modern apps skip this and would just grab the refresh-token for a more seamless experience, but I’m going to need it. Also this cookie is not HTTP only, since I need to access the value on the client.

Here is the code so far (simplified)

import { createClient } from "jsr:@supabase/supabase-js@2";
const _domain = 'my-awesome-app.com';

Deno.serve(async (req) => {
    if (new URLPattern({ pathname: "/sign-in" }).exec(req.url)) {
        if (req.method === "POST") {
            const value = await req.formData();
            const email = value.get('email');
            const password = value.get('password');
            supabase = createClient(Deno.env.get("SUPABASE_URL"), Deno.env.get("SUPABASE_ANON_KEY"));
            const { data, error } = await supabase.auth.signInWithPassword({ email, password });
            if (error || data.session == null || data.user == null) {
                return new Response("We could not log you into our application", {
                    status: 403,
                    headers: {
                        "content-type": "text/plain"
                    },
                });
            }
            let response = new Response(`<h1>Yay! Go to your <a href="/dashboard">dashboard</a></h1>`, {
                status: 200,
                headers: {
                    "content-type": "text/html",
                },
            });
            response.headers.append("set-cookie", `auth-token=${data.session.access_token};domain:${_domain};SameSite=Lax;Path=/;Secure;HttpOnly;MaxAge=${data.session.expires_in}`);
            response.headers.append("set-cookie", `refresh-token=${data.session.refresh_token};domain:${_domain};SameSite=Lax;Path=/;Secure;HttpOnly;MaxAge=${data.session.expires_in}`);
            response.headers.append("set-cookie", `auth-issued-at=${Date.now()};domain:${_domain};SameSite=Lax;Path=/;Secure;MaxAge=${60 * 60 * 24 * 180}`);
            return response;
        } else if (req.method === "GET") {
            const signInTemplate = new TextDecoder().decode(await Deno.readFile("layouts/sign-in.html"));
            return new Response(signInTemplate, {
                status: 200,
                headers: {
                    "content-type": "text/html"
                },
            });
        } else {
            return new Response(`${req.method} is not supported`, { status: 405 });
        }
    }
});

Reading the saved cookies on the server

Cookies are passed along with each request from the browser. I use a simple function that takes in the request, finds the cookie I ask for and then passes back the value.

// req is the request object from Deno.serve
// name is the name of the cookie to find
function getCookieValue(req, name) {
    const cookies = req.headers.get("cookie") ? req.headers.get("cookie").split('; ') : [];
    let cookieValue = cookies.filter(cookie => cookie.includes(`${name}=`));
    cookieValue = cookieValue.length > 0 ? cookieValue[0].split('=')[1] : '';
    return cookieValue;
}

Protecting endpoints

1. Create a user-aware Supabase client. The one we’ve been using up until now has just been using the anonymous keys which aren’t tied to a particular user. However, the database has been set up with a bunch of Row-Level Security (RLS) Policies that do care who the user is. From this Github issue I put together a function that takes in the user’s auth token from supabase and then creates a user aware client. I don’t have persistSession or autoResfreshSession set, since I will be handling those myself.
2. Every protected route calls my verify user function that takes a users auth token, verifys the token with a call to the unauthenticated Supabase client and if it looks good, creates and sets the user-aware Supabase client that the rest of the code for that endpoint will use.
3. If the auth token is expired or bad, send that information back with the request so my webpage can redirect the user to a login page. (NOTE, some may just grab the refresh token now and use it, depends on business requirements)

let _supabase = null;

//https://github.com/supabase/supabase/issues/8490#issuecomment-1219766620
function createServerDbClient(accessToken) {
    return createClient(Deno.env.get("SUPABASE_URL"), Deno.env.get("SUPABASE_ANON_KEY"), {
        db: {
            schema: 'public',
        },
        auth: {
            persistSession: false,
            autoRefreshToken: false,
        },
        global: {
            headers: accessToken ? {
            Authorization: `Bearer ${accessToken}`,
            } : null,
        },
    });
}

// called before any protected endpoint and result checked.
// req is the request object from Deno.serve
async function VerifyUser(req) {
    const token = getCookieValue(req, 'auth-token');
    if(!token) {
        return {verified: false, error: `No token found`};
    }
    // unauthenticated supabase client
    const supabaseClient = createClient(Deno.env.get("SUPABASE_URL"), Deno.env.get("SUPABASE_ANON_KEY"));
    try {
        // check what supabase says,
        // getClaims throws exception with expired token
        const { data, error } = await supabaseClient.auth.getClaims(token);
        if (error) {
            return {verified: false, error: error};
        }
    } catch {
        return {verified: false, error: 'Supabase client exception thrown'};
    }
    // looks good, let the user through and set the supabase client for use
    _supabase = createServerDbClient(token);
    return {verified: true, error: null};
}

This will work… for an hour

Calls to my protected endpoint will work for an hour before that auth token expires. So, I needed to check on the webpage when the token is going to expire so I can alert the user. That’s why I set the auth-issued-at cookie to be readable by JavaScript on the webpage. The basic plan is to figure out the current time, the time the auth code was issued and how long it has left. For my purposes, I do the following:

1. Longer that 5 minutes left? Create a call to setTimeout that will alert the user when they have five minutes left.

2. Less than 5 minutes? Alert the user.

3. Expired? Send the user to the login page.

The alert is a modal that lets the user choose to continue working (i.e. refresh the session) or to log them out. Assuming they want to continue then I call the endpoint to refresh the session. But there is the case to consider that the alert was up and received no input for longer than the time to expire. In that case I show another alert on any interaction that the session expired and kick them back to the login page.

Using the refresh token

I protect the refresh endpoint just like I do other protected endpoints, I make sure the user has a valid and unexpired token before letting a call go through. This is a business requirement I have, others for a more seamless workflow may allow a refresh token to be used after a session has already expired.

The trickest part was figuring out what endpoint to call. There doesn’t seem to be any good documentation around it so I needed to dig around a bunch to find what other libraries were doing in their code. But once the sleuthing was done it was pretty straight forward.

// verify the user can access restricted content
const verify = await VerifyUser(req);
if(!verify.verified) {
  return new Response(`Please log back in: ${verify.error}`, {
    status: 404,
    headers: {
      "content-type": "text/html"
    },
  });
}    

// user requested to refresh the session
  if(new URLPattern({ pathname: "/refresh_session" }).exec(req.url)) {
    if (req.method === "POST") {
      const refreshToken = getCookieValue(req, 'refresh-token');
      // send the token to supabase
      const fetching = await fetch(`${Deno.env.get("SUPABASE_URL")}/auth/v1/token?grant_type=refresh_token`, {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          'apikey': Deno.env.get("SUPABASE_ANON_KEY")
        },
        body: JSON.stringify({
          refresh_token: refreshToken,
        })
      });
      const data = await fetching.json();

    // if we don't get a new token, then the refresh failed
    if(!data.access_token) {
      return new Response('Refresh failed', {
        status: 403,
        headers: {
          "content-type": "text/html",
        },
      });
    }

    // everything worked, refresh the cookies
      let response = new Response('Processed', {
        status: 200,
        headers: {
          "content-type": "text/html",
        },
      }); 

      response.headers.append("set-cookie",`auth-token=${data.access_token};domain:${_domain};SameSite=Lax;Path=/;Secure;HttpOnly;MaxAge=${data.expires_in}`);
      response.headers.append("set-cookie",`refresh-token=${data.refresh_token};domain:${_domain};SameSite=Lax;Path=/;Secure;HttpOnly;MaxAge=${data.expires_in}`);
      response.headers.append("set-cookie",`auth-issued-at=${Date.now()};domain:${_domain};SameSite=Lax;Path=/;Secure;MaxAge=${60*60*24*180}`);
      return response;
    } else {
      return new Response(`${req.method} is not supported`, { status: 405 });
    }
  }

And done!

Now I have a blueprint on how to log users in, save the needed cookies, and how to use the refresh token to get another auth token when needed.

One trick I’ve been using a bunch is a one rule CSS dark theme for simple projects.

html {
  color-scheme:light dark;
  background-color:canvas;
  color:canvastext;
}

This uses the built in browser system colors. When a user has a preference for a dark theme set at the browser level, then canvas is very close to black, otherwise it is white. canvastext is similar. You can see what they look like on your browser here: https://developer.mozilla.org/en-US/docs/Web/CSS/system-color.

Why?

Bytes matter… and once in a while, more then design considerations. This adds very little overhead in a CSS file while respecting and user dark theme preferences. So if you are building a quick personal side project, it’s good. If you are building a website meant for low powered devices with abysmal data connections… it’s a fine tool to have. If you are lazy and only want to write down one CSS rule and be done… perfect 😆

But… it’s ugly?

Yeah, on its own it can be a bit ugly. I’m not a fan of the default link colors (i.e. the default system colors for links) on the browsers I use. So I set out on a quest to find some colors to use instead. Ideally a blueish color for unvisited links and a purplish color for visited ones. I also wanted to keep in mind accessibility considerations. Some color combinations are hard on the eyes and render a website unusable in other cases.

So, high contrast is the name of the game. One tool I use is the webaim contrast checker. But there are a lot of colors and I’m not doing that check manually. JavaScript and Stack Overflow to the rescue! I’m looking for colors that rank equally well on black and white with the highest contrast score possible.

Results

After some trial and error I discovered that you can’t get a contrast score of above 4.58 for a color on both black and white backgrounds. Which only meets AA standards for normal sized text. But they do meet AAA standards for large text. Here were the top 9 results I found:

Another consideration is color blindness. Here are the colors using a color blindness tool

So for me, some of the obvious color combinations would have been awful for someone with color blindness. This is the full list:

And here is what I would have picked without checking first:

Which for those with protanopia or deuteranopia those colors would be hard to distinguish. So in the end I decided my quick side projects would use these colors:

Which look visually different across the three common color blindness types.

That makes my new side project default css the following:

html {
  color-scheme:light dark;
  background-color:canvas;
  color:canvastext;
}
a { color: #6562F2}
a:visited { color: #E20E7B}

Since Color was a prompt for the 2024 Weird Web October challenge and I’m still trying to catch up on that challenge a year later I added it to my collection. Besides list the colors above, it lists 9 additional colors that the contrast on black and white are as far apart as they can be while still retaining a minimum contrast ratio of 3.

Interactive Example

Here is an interactive example that calculates the contrast values on two different background colors. The “JS” tab holds the logic and the “Results” shows the results. Try selecting some different colors on the results tab. A contrast rating above 3.0 is considered AA on large text. If you want to see the calculation I did for the table earlier in the post you can check it out here. I didn’t include it because it iterates over every color combination and it can be a bit slow to load the results tab.

Conclusion

I’m not sure how practical this is for anything other than a quick side project. It doesn’t take to many extra bytes to add in some media queries in CSS to pick separate colors with better contrast for dark and light backgrounds. But I always like to see how simple you can push things so I’m happy to have found some sort of answer.

Blog Theme

Despite how busy everything has been, I’ve managed to squeeze in a couple of updates to my blog. The first one is a bit of a redesign. I’ve toned down the RPG vibe and moved it to a dark mode color scheme and since Halloween is right around the corner I added a little holiday decoration to the top. I love the cute dancing skeleton. I did take a screen shot of the last design and I’ll add it to my change log category soon.

The biggest change is the structure. I decided to de-emphasize the short posts for the time being. They will appear at the top section (one at a time) for a bit and will remain on category pages but I’ve removed them from the archive list.

The second largest change was that I built this theme to be more general, most of my others have been so highly customized that I couldn’t really share the theme. I would tie parts directly to how I named categories or hard-code links. This time I built it with the intent to share, meaning all my personal customizations are in the Custom CSS and Custom footer part of Micro.blog. Now, I do have quite a few updates I want to do before releasing it as a public Micro.blog theme, but I’m happy with the progress I made this weekend. And just to set expectations, I would like to share it before the new year, but… I do have two tai chi and kung fu tournaments I’m prepping for so I won’t have much time to work on it until December.

Code Editor

It has also been on my radar that Glitch shutdown and I had a couple of older blog posts that linked to little projects I had hosted on them. Which is one more reason to host my own code samples. So, I built my own little “lite” code editor this weekend. It can only handle HTML, CSS, and JavaScript and then output the result in a iframe. Using my Fastmail storage I set up a folder to host these code samples as little websites so I can embed them in blog posts. Though I only have one up at the moment for an upcoming blog post you can check them out at code.heyloura.com (Note, this one loops through all RGB color values… so 256 * 256 * 256, which means the result tab takes a couple of seconds to load). It is also interactive so if you make changes to the CSS, HTML, or JS you’ll see updated changes in the “Result” tab.

Now that I have this built out I can create more samples and go back to replace my broken Glitch ones when I have some time. Yay!

Weird Web October

Last year I started strong… for all of two days 😜. My goal is a least three submissions this time around. So to begin prepping I moved my prior submissions off of Micro.blog which I had been building with my theme. They now have a spot here at https://weirdweboctober.heyloura.com/. Then! as an added bonus I completed one more submission for last year’s Day 3 prompt Color. Hence my one current code sample, which I used to do the calculations :)

If I have time, I’d like to fill up all the prompts for last year and this year… but I’m giving myself an unlimited deadline to get it done.

October plans

This is more of a personal todo list to remind me, but I need to go through and

• Update my broken Glitch code samples on blog posts
• Update any Weird Web October links in blog posts
• Write a post on “What colors on a webpage work equally as well on white and black backgrounds while maintaining Web Content Accessibility Guidelines?”
• Write a post about building my little code editor
• Have fun with at least three Weird Web October submissions!