How I fixed this one weird bug!
Tags: vercel, cookies, bugs
Published: 2021-02-22 16:39:49

---
title: How I fixed this one weird bug!
published: true
description: Vercel changes project domains, and nobody can sign in.  Now what?
tags: vercel, cookies, bugs
//cover_image: https://direct_url_to_image.jpg
---

I run a small web app for my company, which acts as a CRM + dashboard, using [Nuxt](https://nuxtjs.org/) + [Nhost](https://nhost.io/) and hosted on [Vercel](https://vercel.com/).

This morning, I pushed a small update and sat back comfortable in the assurance of [automatic continuous deployment](https://vercel.com/docs/git/vercel-for-github#a-deployment-for-each-push) taking care of everything.

But I wouldn't be writing this if it had all gone smoothly, would I?

The first time I noticed something was wrong, was when the dashboard redirected to the login page.  (It's set up to [auto-refresh on every update](https://dev.to/marcellothearcane/discussion-what-is-the-best-way-to-get-users-to-refresh-a-web-app-3gjf)).  I went to log back in, but I noticed something odd:  **Instead of being `my-site.my-domain.now.sh`, the url was pointing to `my-site-my-domain.vercel.app`.**  Why's that such a big deal?  Because I was using `.my-domain.now.sh` as the [cookie domain](https://stackoverflow.com/questions/1062963/how-do-browser-cookie-domains-work) for authentication!

It turns out that buried in the Vercel changelog is [this post](https://vercel.com/changelog/urls-are-becoming-consistent):

> As part of our strategy for making them simpler, we're starting with applying a consistent format on February 20th 2021:
Custom Domains and Automatic URLs ending in now.sh will instead end in vercel.app.
> - Automatic Deployment URLs like `project-d418mhwf5.vercel.app` will gain the slug of the owner Vercel scope to match Automatic Branch URLs: `project-d418mhwf5-team.vercel.app`.
> - **Automatic Branch URLs like `project-git-update.team.vercel.app` will lose their second subdomain level in favor of a dash: `project-git-update-team.vercel.app`.**
> - Automatic Project URLs like `project.team.vercel.app` and Automatic Team Member URLs like `project-user.team.vercel.app` will be adjusted like Automatic Branch URLs.

*Now* they tell me!

It should be as simple as changing the cookie-setting code to use `.vercel.app` as the domain:

```diff
return this.cookies.set(`${this.options.prefix}.${name}`, value, {
  expires,
-  domain: !this.isDev ? '.my-domain.now.sh' : 'localhost',
+  domain: !this.isDev ? '.vercel.app' : 'localhost',
  path: '/',
  sameSite: false,
})
```

But this didn't work.  What was going on?  I was doing something wrong, but I couldn't work it out because it had been working fine before with `.my-domain.now.sh`.  I set a bunch of breakpoints around where cookies were being set, but they seemed to fail silently to no cookie being set.  I even tried setting cookies manually in the browser console:

```shell
> document.cookie = "my=cookie;"
"my=cookie;"
> document.cookie
"my=cookie"

> document.cookie = "sub=my-site-my-domain.vercel.app; Domain=my-site-my-domain.vercel.app;"
"sub=my-site-my-domain.vercel.app; Domain=my-site-my-domain.vercel.app;"
> document.cookie
"my=cookie; sub=my-site-my-domain.vercel.app"

> document.cookie = "tld=.vercel.app; Domain=.vercel.app;"
"tld=.vercel.app; Domain=.vercel.app;"
> document.cookie
"my=cookie; sub=my-site-my-domain.vercel.app"
```

Very strange - I couldn't set cookies at all, either through [`cookie-universal-nuxt`](https://www.npmjs.com/package/cookie-universal-nuxt) or through plain JS [`document.cookie`](https://developer.mozilla.org/en-US/docs/web/api/document/cookie), if the cookie domain was `.vercel.app`.

I had a niggling feeling that there was something stopping `.vercel.app` being used, because then surely I'd be making a cookie that applied to all Vercel URLs.  Previously, `.my-domain.now.sh` was another level of subdomains, so it might have had some sandboxing.  I knew you can't make cookies that apply to `.com` or `.co.uk`, so maybe I should refresh my understanding of that.  This train of thought led me to this very helpful [Mozilla Wiki](https://wiki.mozilla.org/Public_Suffix_List) page.  I quote:

> Previously, browsers used an algorithm which basically only denied setting wide-ranging cookies for top-level domains with no dots (e.g. com or org). However, this did not work for top-level domains where only third-level registrations are allowed (e.g. co.uk). In these cases, websites could set a cookie for co.uk which will be passed onto every website registered under co.uk.
> Clearly, this was a security risk as it allowed websites other than the one setting the cookie to read it, and therefore potentially extract sensitive information.
> Since there is no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain (the policies differ with each registry), the only method is to create a list of all top-level domains and the level at which domains can be registered. This is the aim of the effective TLD list.

So I wonder if this list has anything interesting in it?  [Sure enough](https://publicsuffix.org/list/public_suffix_list.dat#:~:text=vercel.app)...

<pre>
  <code>
  // Vercel, Inc : https://vercel.com/
  // Submitted by Connor Davis <security@vercel.com>
  <mark>vercel.app</mark>
  vercel.dev
  now.sh
  </code>
</pre>

Great!  That must be what's going on!  Now I had to commission a third-level subdomain `main.internal.mycompany.com` using the `cname.vercel-dns.com` provided.  This would then use auth on `internal.mycompany.com` without polluting anything on the main domain.

Sure enough, with the cookie URL reconfigured, the subdomains all set up, and a bit of luck, I could now log on without problems.  The last step was changing everyone's bookmarks, and updating the dashboard pages!

☕