DEV Community: Ashley Connor

Why the Python Standard Library Needs a run_sync()

Ashley Connor — Thu, 24 Apr 2025 19:53:29 +0000

I recently updated a small script I wrote to automate file uploads to a website with no API. It uses the excellent Playwright project to drive a browser - making the tedious task of filling out forms painless.

But there was one big annoyance: authentication.

The upload forms sit behind a login screen that requires a username, password, and TOTP token. To get around this, I initially used Playwright's launch_persistent_context so that cookies could persist across sessions. This worked fine, but I still had to log in every 7 days when the session expired.

I wanted to fix that.

Enter 1Password

The credentials to this website are stored in my personal 1Password Vault. 1Password also has a Python SDK. Perfect, right?

Well...

For reasons I still don’t fully understand, 1Password provides only an async Python SDK—no synchronous methods at all.

Naively, I installed the SDK and started calling it from my existing (synchronous) Playwright code.

Now the script could fetch credentials including the TOTP from 1Password. That meant I no longer needed persistent context or manual logins. But then I hit this error:

Error: It looks like you are using Playwright Sync API inside the asyncio loop. Please use the Async API instead.

Playwright smartly offers both sync and async APIs. So I switched to using async_playwright and then tediously sprinkled async/await throughout my code.

That fixed the issue. The script now worked.

Wait...But why?

Before committing these changes, I paused. Had I just rewritten a bunch of working code to accommodate one library's decision?

Was there no way to bridge async and sync without a full rewrite?

It turns out there is:

def run_sync(coro):
    try:
        asyncio.get_running_loop()
    except RuntimeError:
        # No running loop
        return asyncio.run(coro)
    else:
        # Already in an event loop (e.g. Jupyter, FastAPI, etc.)
        # Run the coroutine in a new thread
        result_container = {}

        def runner():
            result = asyncio.run(coro)
            result_container["result"] = result

        thread = threading.Thread(target=runner)
        thread.start()
        thread.join()
        return result_container["result"]

This gnarly snippet lets you run an async function and retrieve its result in synchronous code.

How it works:

Attempt to fetch the running async loop
1. If a loop is available we create a container for our async functions result
2. Create an inner function runner to execute our async function and push the result into the container
3. Create a thread to execute our runner function
4. Start the thread
5. Join the thread (this blocks our current thread until the thread is finished)
6. Return the result
If a RuntimeError is raised, no loop is running, we catch the exception and return a call to run which takes care of executing our async function for us

Now I could move all my 1Password interactions to a dedicated async function:

async def get_onepassword_creds():
    # ...
    pass

with sync_playwright() as p:
    # ...
    credentials = run_sync(get_onepassword_creds())

No more full async rewrite.

Why Isn’t This Built-In?

I was happy with this result - but it begs the question. Why is all of this required? Surely this is a common enough problem that a standard library solution is warranted?

Well...

I am unenthusiastic about providing this functionality in the stdlib. This is really not something that a well-behaved async application should do, and having the API would legitimize an idiom that is likely to come back and stab you in the back when you least need it. You would be better off refactoring your application so you don’t need this ugly hack. (Of course, I understand that realistically that’s not always possible, but if your specific app’s transition to an async world requires this hack, well, it’s only 7 lines of code.)

Guido van Rossum

Source

That thread includes a simpler (but less robust) example:

def call(coro):
    try:
        loop = asyncio.get_running_loop()
    except RuntimeError:
        return asyncio.run(coro)
    else:
        return loop.run_until_complete(coro)

But this fails if the current loop is already running—like in Jupyter, FastAPI, or some test environments.

The Mess We’re In

So there you have it.

Want to call async code from sync Python? Just copy-paste these 7 15 lines into every project.

It’s not ideal. And it's brittle: get_running_loop() wasn’t even available before Python 3.7.

There are other real-world use cases too - like debugging with pdb:

# fail
(Pdb) await my_async_func()
*** SyntaxError: 'await' outside function

# works
(Pdb) result = run_sync(my_async_func())
(Pdb) print(result)

A poor developer experience.

Conclusion

As more libraries adopt async-only interfaces and as more developers try to mix async and sync code, this problem will only get worse.

Python needs a standard library solution for this. It’s time the core team reconsiders their position.

Authenticated Server Rendered pages with SvelteKit and Supabase

Ashley Connor — Thu, 24 Jun 2021 20:27:13 +0000

If your SvelteKit web application has an authenticated page that contains private data from Supabase and you want to provide your users with a server rendered page, you'll need a way to make authenticated calls from your SvelteKit endpoints.

In this post I'll explain how you can pass your Supabase JWT to your SvelteKit endpoint and store it as a cookie.

This cookie can then be used to make authenticated calls to Supabase on a users behalf which allows you to generate authenticated server rendered pages.

Why

Server Side Rendering provides a better user experience as it provides the browser with a an immediate response that can be rendered without waiting on Javascript requests.

A user may have Javascript disabled on their browser and SSR will provide a somewhat usable experience.

I personally dislike the "flicker" that is common to web applications that depend on data retrieved after the page has first loaded.

How

In order to make authenticated calls to Supabase within our SvelteKit endpoints we need to send the JWT to the server and respond with a cookie.

We can do this in our auth.onAuthStateChange() callback:

// src/routes/__layout.svelte
import { session } from '$app/stores';
import { supabase } from '$lib/supabaseClient';
import { setAuthCookie, unsetAuthCookie } from '$lib/utils/session';

// this should run on every page so I put this code in my `__layout.svelte` file
supabase.auth.onAuthStateChange(async (event, _session) => {
  if (event !== 'SIGNED_OUT') {
    session.set({ user: _session.user });
    await setAuthCookie(_session);
  } else {
    session.set({ user: { guest: true } });
    await unsetAuthCookie();
  }
});

The setAuthCookie makes a request to an endpoint with the JWT and responds with a cookie and unsetAuthCookie unsets the same cookie:

// src/lib/utils/session.js
export async function setServerSession(event, session) {
  await fetch('/api/auth.json', {
    method: 'POST',
    headers: new Headers({ 'Content-Type': 'application/json' }),
    credentials: 'same-origin',
    body: JSON.stringify({ event, session })
  });
}

export const setAuthCookie = async (session) => await setServerSession('SIGNED_IN', session);
export const unsetAuthCookie = async () => await setServerSession('SIGNED_OUT', null);

It's important to include the event as the supabase-js library expects it.

Our endpoint to set the cookie looks like so:

// src/routes/api/auth.json.js
export async function post(req /*, res: Response (read the notes below) */) {
  // Unlike, Next.js API handlers you don't get the response object in a SvelteKit endpoint. As a result, you cannot invoke the below method to set cookies on the responses.
  // await supabaseClient.auth.api.setAuthCookie(req, res);
  // `supabaseClient.auth.api.setAuthCookie(req, res)` is dependent on both the request and the responses
  // `req` used to perform few validations before setting the cookies
  // `res` is used for setting the cookies
  return {
    status: 200,
    body: null
  };
}

You're probably thinking - "Where is the cookie set?" - that has to be done in our SvelteKit hook because we don't have access to the response object to pass to the supabase.auth.setAuthCookie function.

So our hooks.js file looks like this:

// src/hooks.js
export const handle = async ({ request, resolve }) => {
  // Parses `req.headers.cookie` adding them as attribute `req.cookies, as `auth.api.getUserByCookie` expects parsed cookies on attribute `req.cookies`
  const expressStyleRequest = toExpressRequest(request);
  // We can then fetch the authenticated user using this cookie
  const { user } = await auth.api.getUserByCookie(expressStyleRequest);

  // Add the user and the token to our locals so they are available on all SSR pages
  request.locals.token = expressStyleRequest.cookies['sb:token'] || undefined;
  request.locals.user = user || { guest: true };

  // If we have a token, set the supabase client to use it so we can make authorized requests as that user
  if (request.locals.token) {
    supabase.auth.setAuth(request.locals.token);
  }

  let response = await resolve(request);

  // if auth request - set cookie in response headers
  if (request.method == 'POST' && request.path === '/api/auth.json') {
    auth.api.setAuthCookie(request, toExpressResponse(response));
    response = toSvelteKitResponse(response);
  }

  return response;
};

Our helper functions toExpressRequest, toExpressResponse, toSvelteKitResponse look like this:

// src/lib/utils/expressify.js
import * as cookie from 'cookie';

/**
 * Converts a SvelteKit request to a Express compatible request.
 * Supabase expects the cookies to be parsed.
 * @param {SvelteKit.Request} req
 * @returns Express.Request
 */
export function toExpressRequest(req) {
  return {
    ...req,
    cookies: cookie.parse(req.headers.cookie || '')
  };
}

/**
 * Converts a SvelteKit response into an Express compatible response.
 * @param {SvelteKit.Response} resp
 * @returns Express.Response
 */
export function toExpressResponse(resp) {
  return {
    ...resp,
    getHeader: (header) => resp.headers[header.toLowerCase()],
    setHeader: (header, value) => (resp.headers[header.toLowerCase()] = value),
    status: (_) => ({ json: (_) => {} })
  };
}

/**
 * Converts an Express style response to a SvelteKit compatible response
 * @param {Express.Response} resp
 * @returns SvelteKit.Response
 */
export function toSvelteKitResponse(resp) {
  const { getHeader, setHeader, ...returnAbleResp } = resp;
  return returnAbleResp;
}

Issues

This works but it isn't ideal for the following reasons:

Supabase stores the refresh token in localstorage which makes it vulnerable to XSS. This is done so the supabase-js client library can refresh the token on the users behalf.
There's no refresh mechanism on a SSR request.
It doesn't follow the best practices for JWTs on frontend clients.

Potential improvements

Any improvement will likely make Supbase Auth more difficult to use, so what I'm proposing would be opt-in for users that want to improve their auth security.

Allow configuration of the refresh endpoint so we can proxy the request to Supabase ourselves. This would allow us to set a refresh token in a cookie and remove it from localstorage. There would need to be some extra security work in order to make sure a client wasn't sending the request directly to a Supabase auth endpoint.
Expose a function to generate the cookie using just the token. This would save us having to generate Express-style request/response objects just to get the cookie.

Code

All of the code above and more is available in my repository sveltekit-supabase-demo. If you have any suggestions or feedback feel free to open an issue or PR.

Thanks

A huge thanks to Aftab Alam for providing a SvelteKit template that was a source for much of the code above.

Deploying SvelteKit using Cloudflare Workers

Ashley Connor — Mon, 21 Jun 2021 00:20:44 +0000

Introduction

Recently I've been using SvelteKit as the frontend for a project I've been working on and after some local development I wanted to get it up and
running on the cloud.

I chose Cloudflare Workers as I already have an account with them (this blog is hosted on Cloudflare Pages) however, the documentation on using the adapter-cloudflare-workers is pretty sparse so I'll cover how I got it deployed here.

SvelteKit adapter configuration

If you don't have an existing SvelteKit project you can follow allowing by generating the demo project:

$ npm init svelte@next my-cloudflare-workers-demo
? Which Svelte app template? › - Use arrow-keys. Return to submit.
❯   SvelteKit demo app # select this
    Skeleton project
✔ Use TypeScript? … No / Yes
✔ Add ESLint for code linting? … No / Yes
✔ Add Prettier for code formatting? … No / Yes
✔ Copied project files

$ cd my-cloudflare-workers-demo
$ npm install

Once you're at the root of your project we can install the adapter:

$ npm i @sveltejs/adapter-cloudflare-workers@next

Next, let's configure the adapter in our svelte.config.js:

// first import the adapter
import adapter from '@sveltejs/adapter-cloudflare-workers';

// then in the config object, add an adapter key under kit, and call the imported library
const config = {
    kit: {
        // hydrate the <div id="svelte"> element in src/app.html
        target: '#svelte',
        adapter: adapter()
    }
};
...

That's all that's required from SvelteKit. Now onto the Cloudflare Workers configuration.

Wrangler

Configuration

To deploy to Cloudflare we will install the Wrangler CLI tool and generating an empty configuration:

$ npm i @cloudflare/wrangler -g
$ wrangler init --site my-cloudflare-workers-demo
🕵️  You can find your zone_id in the right sidebar of a zone's overview tab at https://dash.cloudflare.com
🕵️  You can find your account_id in the right sidebar of your account's Workers page
🕵️  You will need to update the following fields in the created wrangler.toml file before continuing:
- account_id
✨  Successfully scaffolded workers site
✨  Successfully created a `wrangler.toml`

Now let's follow the instructions given and login to our Cloudflare dashboard to find our account_id.

Copy your Account ID from the sidebar:

Optionally if you have a domain setup with Cloudflare that you wish to use with your Cloudflare Workers, grab the zone_id from your domain's dashboard.

Now edit your wrangler.toml configuration file with those values:

account_id = '4b05422c8548d995a6132421d4c31bba'
zone_id    = '2ea755fa5c01136f1d07a2013c2d1c6f' # optional, if you don't specify this a workers.dev subdomain will be used.

Finally, we also need to make some adjustments to the site key pointing it to the directories that will be generated by running build stage later on.

site = {bucket = "./build", entry-point = "./workers-site"}

Authorization

Next, let's authorize our Wrangler client so we can deploy our project:

$ wrangler login
Allow Wrangler to open a page in your browser? [y/n]
y
💁  Opened a link in your default browser: https://dash.cloudflare.com/wrangler?key=...
💁  Validating credentials...
✨  Successfully configured. You can find your configuration file at: /Users/ashleyconnor/.wrangler/config/default.toml

Build our project and deploy

First, we need to build our project which we can do using npm run build:

$ npm run build

> my-cloudflare-workers-demo@0.0.1 build
> svelte-kit build

vite v2.3.7 building for production...
✓ 34 modules transformed.
...
✓ 27 modules transformed.
.svelte-kit/output/server/app.js   64.33kb
...
> Using @sveltejs/adapter-cloudflare-workers
  ✔ done

Then run the wrangler publish command:

$ wrangler publish
up to date in 0.729s
found 0 vulnerabilities

✨  Built successfully, built project size is 33 KiB.
🌀  Created namespace for Workers Site "__my-cloudflare-workers-demo-workers_sites_assets"
✨  Success
🌀  Uploading site files
✨  Successfully published your script to
 https://my-cloudflare-workers-demo.ashconnor.workers.dev

Your Server Side Rendered SvelteKit application should be up and running on the URL above.

You can visit the demo SvelteKit application running on Cloudflare Workers here.

Configuring self-signed SSL certificates for local development

Ashley Connor — Thu, 10 Jun 2021 17:04:37 +0000

Sometimes it's preferible to keep your local development environment as close to production as possible.

In this post I'll cover how to configure self-signed SSL certificates using a project called mkcert which makes
creating, installing and removing self-signed certificates easier than ever.

The instructions are slightly different depending on your local environment:

Common
WSL2
Firefox on Windows

Common

The first thing you will need is to install mkcert which can be done via homebrew or homebrew for Linux.

$ brew install mkcert

If you intend to use Firefox, you should also install nss.

$ brew install nss

Next run mkcert and pass in the the domain names and IPs you want the certificate to include:

$ mkcert mywebsite.test localhost 127.0.0.1 ::1

Created a new certificate valid for the following names 📜
 - "mywebsite.test"
 - "localhost"
 - "127.0.0.1"
 - "::1"

The certificate is at "./mywebsite.test+3.pem" and the key at "./mywebsite.test+3-key.pem" ✅

It will expire on 7 September 2023

mkcert also accepts wildcards but some browsers (Firefox) will not accept those certificates.

After the certificates are generated we can install the local CA by running mkcert with the install flag. This only needs to be done once as this CA will be used to sign all future certificates generated with mkcert.

$ mkcert -install

If this is you first time installing certificates using mkcert you should see the following output:

The local CA is now installed in the system trust store! ⚡️
# or...
The local CA is already installed in the system trust store! 👍

At this point your can use your generated certificates with your development server.

Flask

$ flask run --cert=mywebsite.test+3.pem --key=mywebsite.test+3-key.pem

Rails

$ rails s -b 'ssl://127.0.0.1:3000?key=mywebsite.test+3-key.pem&cert=mywebsite.test+3.pem'

WSL2

If you're running the WSL2 then there are few extra steps in order to get the Windows 10 host to accept the validity of the certificates.

First we want to install mkcert on Windows which we can do using chocolatey.

Open a Powershell terminal using the administrator user and run:

$ choco install mkcert

Then run mkcert with the install flag like we did before:

# first set the CAROOT path to point to the root CA we generated on WSL2
# you can get this directory by running mkcert -CAROOT from a WSL2 terminal
# if we don't do this it will install a different root CA and we will get warnings
$CAROOT="\\wsl$\Ubuntu\home\ashley\.local\share\mkcert\"
$ mkcert -install
The local CA is now installed in the system trust store! ⚡️
Note: Firefox support is not available on your platform. ℹ️

You should see a popup like the one below. Click "Yes" to install the CA on the Windows 10 host.

Firefox on Windows

After that's installed let's fix Firefox so it doesn't complain that our certs are invalid.

To do that open the Firefox browser and navigate to the settings and search for certificates:

Click on "View Certificates"

Next click on "Import". We want to locate the root CA from our Linux instance. Mine was located here but yours will be different depending on your WSL2 linux distro:

\\wsl$\Ubuntu\home\ashley\.local\share\mkcert\rootCA.pem

Once installed you will see your local CA in the list of Authorities:

Now if we visit our local development server in Firefox on our Windows host we should see the page load without any warnings.