Forem: marcellothearcane

How I fixed this one weird bug!

marcellothearcane — Mon, 22 Feb 2021 16:39:49 +0000

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!

☕

Get code coverage reports with Github Actions and Codecov

marcellothearcane — Thu, 08 Oct 2020 09:23:35 +0000

TLDR: Show me the money

So, you've spent some time getting tests set up on your project. How do you show the world?

A popular service is Codecov, and you'll probably recognise their badges from Github repositories:

However

Codecov is a static analysis tool, which means you have to upload reports that have already been tested. One option is to commit your coverage folder, but this is a bad idea:

You have to run your tests before every commit. Chances are you'll forget, and your coverage will be out of date.
You won't be able to edit away from your main computer (i.e. you can't update the tests from your phone).
It isn't automated enough, and everyone knows more automation is better.
Probably loads of bad things.

Github Actions to the rescue!

Github Actions is a fairly new (I think?) feature that allows you to add CI to your project.

There's a few default templates, but unfortunately none that I could find for running tests and sending the reports over to Codecov.

Set up a Github Action

Github actions are stored in .github/workflows, and are YAML files that specify how the job should run. Check out the docs to find out more.

We'll set up a simple task by adding a file called codecov-test-suites.yml and adding the following:

# .github/workflows/codecov-test-suites.yml

name: Run Test Suites

on: [push]

This sets up a new workflow that triggers for every push.

Now we need to make it do things! You need to add a job to this file, which does the following:

Fetches the files
Installs the dependencies
Runs the test
Uploads the test to Codecov

This is easy. Add this to the codecov-test-suites.yml file:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2 # Check out your repository
    - run: yarn # Install dependencies
    - run: yarn test --coverage # Run test
    - run: bash <(curl -s https://codecov.io/bash) # Upload to Codecov

Your test should run, but apparently you have 0% coverage. What?

It turns out the tests are run in a weird folder, and this doesn't tie up with your repository structure, so Codecov gets confused.

To fix this, you need to add a codecov.yml file to your project root. In here, we'll specify how to fix the file paths:

# codecov.yml

fixes:
  - "/home/runner/work/<project name>/<project name>/::" # Correct paths

Edit <project name> to your repository name from Github, and commit this.

Huzzah! Github Actions should now be automagically running tests every time you push and sending to Codecov!

Be sure to head to Codecov's badge settings and get that sweet SVG goodness:

Remember that 100% badge from earlier?

The money

// package.json

{
  // Make sure jest creates lcov reports
  "jest": {
    "collectCoverage": true,
    "coverageReporters": ["html", "lcov"]
  }
}

# .github/workflows/codecov-test-suites.yml

name: Run Test Suites

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2 # Check out your repository
    - run: yarn # Install dependencies
    - run: yarn test --coverage # Run test
    - run: bash <(curl -s https://codecov.io/bash) # Upload to Codecov

# codecov.yml

fixes:
  - "/home/runner/work/<project name>/<project name>/::" # Correct paths

How to CSP your Netlify projects

marcellothearcane — Wed, 23 Sep 2020 09:48:37 +0000

TLDR: I made this Netlify plugin for CSP. You should give it a try.

Have you ever seen the full fury of dev tools spitting blood/blocked:csp at you?

No? Well you should have. Because that means you have at least tried to set up a Content-Security-Policy on your website before.

Setting up a content security policy is essential for preventing XSS attacks - which is a big deal, because XSS was responsible for 40% cyber attacks in 2019.

However, it's not always fun to set up. If you're using something like Gridsome on Netlify, you will come across two key issues that you can't solve just by adding a Content-Security-Policy key to the headers in your netlify.toml.

Gridsome (and Gatsby) inline the initial state, which is a big <script></script> block.
Vue uses inline styles for v-show, like style="display:none;"

Both of these things are blocked by CSP rules, which is good because you don't want random scripts being added into your website or your styles being messed up (someone styling another link as a 'pay now' button for example).

To fix this, you need to generate a cryptographic hash of the inline script, so the browser knows this is okay and hasn't been tampered with. If you search online, you might find some bad advice, like using unsafe-inline. (Bad! Bad! saith the buyer...)

If you're using Netlify, you can use this amazing package I made earlier to generate sha256 hashes of inline scripts and styles for your Content-Security-Policy headers. Head over to the Github repo, and try it out on your Netlify project.

MarcelloTheArcane / netlify-plugin-csp-generator

Generate CSP headers from inline script hashes

netlify-plugin-csp-generator

Generate Content-Security-Policy headers from inline script and style hashes

When running things like Gatsby or Gridsome, the initial state is stored inside a <script> tag Modern browser content security policies don't like inline scripts or styles, so to get around it you need to add either a cryptographic nonce or a cryptographic hash of each script A nonce is out of the question, because you can't update it for each load.

This package generates a crypographic hash (SHA-256) of all inline scripts and styles in each HTML file, and adds it to the _headers file along with other policies of your choice.

Note
Netlify lets you add a Content-Security-Policy header in your netlify.toml. This will overwrite values inside _headers, so don't do that.

If you have an existing _headers file, this will append to the existing file. Just make sure the file ends on…

View on GitHub

If you're not using Netlify, you're on your own. Sorry about that.

Want to check your website for XSS vulnerabilities? Just run this in your browser console:

const script = document.createElement('script')
script.innerHTML = 'alert("hacked!")'
document.body.appendChild(script)

😱

QlockTwo in your browser!

marcellothearcane — Thu, 06 Feb 2020 16:33:01 +0000

Have you seen the QlockTwo? It's pretty cool. Here's a version with HTML and Javascript.

I made a Nuxt template for Nhost!

marcellothearcane — Thu, 16 Jan 2020 07:22:09 +0000

If you haven't heard, Nhost is a really cool preconfigured Hasura instance, with authentication / file storage built in!

Think Firebase on GraphQL, with the plus of all being open source.

So if you're looking for the next backend for your Nuxt project, give Nhost a try!

You can use my template to get started:

MarcelloTheArcane / nhost-template

NHost Template for Nuxt

For detailed explanation on how things work, check out Nuxt.js docs.

NHost is cool. It's a PostgreSQL database with GraphQL, file storage, and authentication built in. You should check it out.

Preconfiguration

GraphQL support from @nuxtjs/apollo
Authentication support from @nuxtjs/auth

Apollo configuration

There is a configuration for apollo in plugins/apollo.js which adds the bearer token to websocket requests (for subscriptions).

Auth configuration

The authentication has a custom configuration provided by plugins/refreshScheme.js. This adds support for the JWT refresh scheme used by NHost.

There is also an auth configuration in plugins/auth.js which handles whether a user should be able to access a page.

Style configuration

This project is preconfigured with Tailwind. It's pretty awesome, but if you want to use something else, remove the tailwind dependencies and add something new.

Template setup

From Github, you can click on Use this template to create…

View on GitHub

I've written my first blog post!

marcellothearcane — Sat, 23 Nov 2019 16:56:58 +0000

Nearly two weeks ago (how time flies) I asked for suggestions on what to write blog posts about for Nhost a GraphQL-based backend as a service.

Here's the first one! I'm new to all this, so your feedback is appreciated - as well as any suggestions for more blogs:

https://blog.nhost.io/building-a-photo-app-with-nhost/

What should I write blog posts about?

marcellothearcane — Sun, 10 Nov 2019 15:15:14 +0000

I've been given a writer account for the blogging platform of the startup Nhost.

Nhost is a hosted, GraphQL-based, Hasura-backed altermative to databases-as-a-service, like Google Firebase.

It's really new, and really awesome, and I think it would be cool to make some examples demonstrating what you can do with it, but I need project ideas!

Everything seems to have a 'todo app' example, but that doesn't always help people in the real world.

What are some simple projects I could make that would be useful to you, if you were going to get started with Nhost?

Discussion: What is the best way to get users to refresh a web app?

marcellothearcane — Tue, 10 Sep 2019 20:35:09 +0000

I'm currently developing a Nuxt web app for our staff to use for processing orders.

At the moment, there are a lot of bugs being fixed or new features implemented.

The trouble is, the users generally keep the tab open for days on end, since they are using it constantly - and since it's Nuxt, they don't ever hard-refresh.

This means they don't get the bug fixes they asked for as soon as they have been deployed.

What is the simplest notification system for me to quickly post a 'Refresh this page to see the latest version' popup?

I'm using Nuxt, GraphQL, and Zeit deployment, so if it could trigger from a successful deploy on Zeit that would be awesome.