How I fixed this one weird bug!

I run a small web app for my company, which acts as a CRM + dashboard, using Nuxt + Nhost and hosted on Vercel.

This morning, I pushed a small update and sat back comfortable in the assurance of automatic continuous deployment 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). 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 for authentication!

It turns out that buried in the Vercel changelog is this post:

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:

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:

> 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 or through plain JS 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 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...

  
  // Vercel, Inc : https://vercel.com/
  // Submitted by Connor Davis 
  vercel.app
  vercel.dev
  now.sh
  

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!

☕