Safari + Hapi.js + CORS = 404

So with recent software updated on OS X (including newest Safari 9.0.1) and also updating a project to latest version of hapi.js(v11) CORS requests are broken.

It appears Safari now sends an Access-Control-Request-Headers value of “accept, origin, authorization”, while Hapi has a default configuration for CORS headers doesn’t include “origin”. Chrome meanwhile, was still working only sending “accept, authorization” for the header value.

The solution is to tell Hapi to also accept “origin” as a CORS request header value:

server.connection({
  port: process.env.PORT || 8081,
  routes: {
    cors: {
      additionalHeaders: [
        "Origin"
      ]
    }
  }
});

There have been a few changes in configuration and handling of CORS in Hapi of late, so this may not be needed down the road if changes are made to the default configuration.

Related Issues:

• “CORS: Is 404 on OPTIONS request the right thing to do?”
• “Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.”

React & Redux Tutorial (including testing!)

This article by Tero Parviainen (@teropa) is one of the best full-stack Redux & React examples I’ve come across lately, covering the server-side, thinking about application state, socket.io, and testing react components.

Well worth the read.

Hapi.js & invalid cookies

I love using Hapi.js, but every time I start a new project with it I have this problem where all my requests get 400 responses due to an invalid cookie value.

My new shiny hapi app doesn’t care about cookies. I don’t want it to care about cookies. But it still does. By default, hapi tries to read all the cookies that were sent with the request, including signed cookies set by express. Of course, as I’ve a habit of developing on localhost, and because we have multiple apps on the same domain (java, express, as well as hapi) where some of those apps care about these cookies, these cookies are going to get sent along with the request to an app that doesnt care about them. Hapi does it’s job to try and verify the signed express cookie and fails (it doesn’t have any way to actually verify, i.e. no keys/secrets used in the signing), retuning the 400.

So every new hapi service I start with now I ignore cookie errors:

server.connection({
  port: process.env.PORT || 8000,
  state: {
    ignoreErrors: true
  }
});

Survive.js

Survive.js is a fantastic book on React and Webpack. It’s an open source ebook and is still under development but I’ve found quite a few things I didn’t know and could immediately apply to my current React+Webpack projects. Webpack is an amazing tool but it has a steep learning curve (and the documentation is lacking) so I wish I had this months ago!

Socket.io links

Using hapi.js with socket.io
Matt Harrison (author of the upcoming book “Hapi.js in Action”) has a good post on using hapi.js with socket.io. It’s really simple to set up and he shows a couple of more interesting examples when using hapi when listening on multiple ports.

SocketCluster
SocketCluster is an open-source multi-process clustered framework built to scale across multiple cores and multiple instances. It looks very interesting for taking a lot of the concerns for scaling a socket service and providing a framework for plugging in your own code. I haven’t used this yet but look forward using it.