A Quick CORS Primer for Frontend Folks

Pearl Latteier — Sun, 08 Nov 2020 19:56:11 +0000

Photo by Michael Geiger on Unsplash

You've made some requests on Postman. You understand which endpoints will deliver what payloads. Contented, you start developing on localhost. Enter the villain — CORS Error!

What is CORS?

Cross-Origin Resource Sharing (CORS) is a web standard designed to let servers on different domains share resources (HTML or JSON documents, images, fonts, etc.) in a safe way.

CORS comes into play when a web application on one origin (https://some-domain.com) requests a resource from another origin (https://some-other-domain.com). To protect both the server receiving and the browser sending the request, CORS manages these cross-origin interactions.

How does CORS work?

The CORS standard manages cross-origin interactions via HTTP headers. The server hosting the desired resource can use Access-Control-Allow-Origin and other headers to specify how it will respond to cross-origin requests.

Simple requests

For example, when I send a GET request to Dog.ceo for a random dog pic, the response includes this header: Access-Control-Allow-Origin: * The * means that the sever will deliver the the resource in response to any request, whatever domain it comes from.

If, for some reason, Dog.ceo decided to make its resources available only to requests from https://example.com, it could change the header to Access-Control-Allow-Origin: https://example.com.

Or Dog.ceo might want to limit its resources to a handful of origins. In that case, it could set the allow-origin header to whatever the request origin is, but then inspect the request to make sure it's on the list of allowed origins before responding.

If the allow-origin header is anything more specific than * , the server should also send a [Vary: Origin header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary), telling caches that the content of the response will vary depending where the request is coming from.

Preflight requests

My GET request to Dog.ceo is very simple. Many requests are more complicated, and the CORS standard requires additional work from browsers whenever a request isn't a GET, HEAD, or POST, when it's content type isn't a form or plain text, or when it meets several other conditions.

In these cases, before it sends the cross-origin request, the browser sends a "preflight request" using the OPTIONS method. The purpose of the pre-flight request is to figure out if the real request is actually allowed by the responding domain. The response from the server to the OPTIONS request will indicate which origins are allowed, which request methods are allowed, if cookies Authorization headers are allowed, or required, or forbidden, and other things along those lines.

(Note: the reason your cross-origin Postman request worked fine is because Postman is not a browser. It does not send a preflight request.)

If you're not sure if your request is simple enough to avoid preflight, a nice tool called Will it CORS? can help you figure it out.

Once the browser had received the response to the preflight request and determined that your request is OK, it will send the request. If your request is not OK, you'll get the infuriating CORS error.

Troubleshooting CORS errors

What about that error? When you run into a CORS error, what can you do?

If you're a frontend person, you can start by inspecting your request. Are you using the right method, sending the right credentials (or not sending credentials if they are not accepted by the responding domain), and sending the appropriate content type? The MDN article about what triggers a preflight request could be helpful here, along with the Will it CORS? tool.

If you have access to the responding server, you're in luck. You can examine the server's CORS configuration and make sure that it is correct. MDN has an article about specifically for server developers that may assist you in this. Alternatively, if you have access to a person who has access to the server, supplicate yourself and humbly, kindly, gratefully ask for help.

Whatever the case, I hope this quick primer helps keep you brave in the face of your next CORS error.

Special thanks to Abraham Williams (@abraham) for talking me through more than one CORS crisis and introducing me to Will it CORS?.

Originally published in the Propeller Health Tech Blog.

References

https://httptoolkit.tech/will-it-cors/

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

https://fetch.spec.whatwg.org/#cors-protocol

https://www.w3.org/wiki/CORS

Lost in SPA(ce): Helping screen readers navigate React applications

Pearl Latteier — Wed, 25 Mar 2020 18:39:58 +0000

Originally published in the Propeller Health Tech Blog.

When the front-end team at Propeller Health recently set out to make our websites accessible, I thought I was in familiar territory. I’m a fan of semantic html, alt tags and input labels, I’m proud of my perfect scores on Lighthouse accessibility audits and I’m fluent in aria attributes.

But I learned pretty quickly that web accessibility is more complicated than I’d thought. To make our site friendly to all users, the team had to start asking new questions. Does it work without a mouse or when the screen is zoomed to 300%? Is the structure of information clear to assistive technologies? Can all users navigate, find content and determine where they are?

The last question raised a particularly tricky problem for us. We work on a single-page React application that involves a “multi-page” form. A user fills out some form fields, clicks “next”, sees a new view with new form fields, fills them out, and clicks “next” again. How would we keep users of screen readers oriented when the page content changed without a browser refresh?

The Problem

In a server-rendered website, each time the page changes, the browser refreshes. The old page is gone, and screen readers start reading the new page from the top. The first thing the screen reader articulates is the page title in the HTML header. This lets the user know immediately where they are. If they are in the right place, they can start tabbing forward to explore the page.

Single page applications don’t work the same way. When the page changes, the browser does not refresh and the screen reader doesn’t know that anything has happened. The focus doesn’t automatically move to the top of the screen. There is nothing to orient the reader.

Our Solution

At the time of this writing, there was no standard, codified way to make single page applications navigable by screen readers. Nor could we find any well-tested NPM package that would solve the problem for us. So we rolled our own solution. It’s not perfect, but it works.

Our solution was inspired by a pattern employed in server-rendered websites called a “skip link” (and by Mary Sutton’s discussion of skip links in her Frontend Masters course ). The goal of the skip link is to give users of screen readers a way to skip past the top navigation that is usually found at the beginning of every web page. Without a skip link, these users have to wade through many links, icons, and search boxes on every page before they can get to the page’s main content.

The skip link is generally the first item on a page. When the user clicks the skip link they are brought to the main section of the page.

In HTML, it would look something like this:

We repurposed the skip-link pattern as a way to let users know when the content of our single page application had changed. It’s implemented as a lightweight component that wraps each of our page-level components. The component moves the focus to the top of the page and prompts the screen reader to say the page title, imitating what would happen when the browser refreshes. Here’s more or less the whole thing:

We create a ref to the skip link and move focus to the link as soon as the component has loaded. The screen reader reads the link, which includes the title of the page and a message about skipping to the main content. This way, the user knows what page they are on and what to do to move forward.
There are likely better implementations out there (share yours in the comments!). We hoped that by following the skip-link pattern ours would at least be familiar and easy to understand.

We at Propeller and the frontend community at large have more work to do to make our single page applications accessible to everyone. Our recent accessibility initiative has increased our empathy for users who use the web differently than we do. We embrace the challenge.

DEV Community: Pearl Latteier