Most developers will sooner or later have to deal with certificates. But what is a certificate, really? It's got something to do with authentication, right..? In this post we will try to explain what a certificate actually is!

Usually we come across certificates when we want our application to communicate with some new API that we haven't used before. As a responsible and security aware developer you of course use HTTPS for all communication, and the first time you try to connect to this new API you may get an error: "Certificate not trusted".

A certificate is one of the parts of a public key infrastructure (PKI). Public key cryptography, like RSA, allows two parties to set up an encrypted connection without having to share a secret encryption key in advance. In public key cryptography all communicating parties will have a public key and a private key. If Alice wants to send an encrypted message to Bob, Alice will encrypt the message using Bob's public key. This message can now be decrypted only if you have Bob's private key (and as the private key should never be shared this means only Bob should be able to decrypt the message).

But how can Alice know that a public key belongs to Bob, and not to someone else who wants her to think that they are Bob? Enter certificates! A certificate is something that contains Bob's public key and says that "this is Bob's public key". But, to make this claim trustworthy, we need some trusted third party that can guarantee that this actually is Bob's public key. This is what a certificate authority (CA), like Buypass, Let's Encrypt and DigiCert, is meant to be, and their job is to verify that the public key actually belongs to the claimed owner, and then issue the certificate that says so. If we trust the CA that has issued the certificate, then we can trust that this actually is Bob's public key and that it really is Bob we are talking to if he is able to decrypt messages that are encrypted with his public key.

Public key cryptography is unfortunately very resource consuming. TLS (or HTTPS, which simply means HTTP encrypted with TLS/SSL) use public key cryptography only during the initial handshake for agreeing on a secret symmetrical encryption key and for authenticating who they are talking to. The authentication in the handshake is based on the parties being able to decrypt messages that was encrypted with their public key, not in their ability to present valid certificates (the certificates are public information).

The solution to the "Certificate not trusted" problem mentioned initially is, as you may already know, to add the CA certificate that has issued the certificate presented by the API to your application's truststore, if this is a CA that you trust.

Public key certificates

Is this the last reducer you'll ever write?

I don't know about you, but most of my Redux reducers look like this:

The usecase is pretty simple - it's dealing with an asynchronous action that either returns some data or some error. Like purchasing something. Or logging in. Don't you think this is a lot of boilerplate for a pretty common use case?

This article will show you how to stop writing boiler plate, while still having a maintainable code base.

Step 1: Standardizing async actions

We ask our server for stuff every once in a while - and we bet you do too. A typical work flow when you're doing this is creating three actions with matching action creators:

This gets tedious after a while, especially when it creates a matching amount of work in the reducer, and in its maticulous test suite.

Let's create a function that makes these for us:

Now, instead of writing those 15 lines above for each server call you want to do, you can call createNetworkAction('SOME_ACTION'). Pretty neat, eh? 🇨🇦

Step 2: Create a metadata reducer

Since all async actions now follow the same strict naming standard, we can do even more cool stuff. Let's create a shared reducer that deals with all our metadata!

What I'm going to how you next is basically a generalized version of my first example - a "typical reducer":

It might look a bit overwhelming at first, but what is says is basically:

If the action ends with _REQUEST, set the state of that request to loading

If the action ends with _RESPONSE, set the state of that request to successful

If the action ends with _ERROR, set the state of that request to erroneous.

The great thing about this is that you only need to implement this once (hey, copy and paste if you want), and you're done!

Step 3: Create selectors!

The biggest downside with this approach is that you have to add a lot of checks for whether or not the request has been made (the request isn't reflected in the reducer before you have requested it). Luckily, we can get around that by following the selector pattern, with a few clever tricks:

This way, we make sure we always have sane default values!

Use it!

Now, you got a reducer that keeps track of all of your network metadata! It's simple to write selectors for (isCustomerFetching, isPurchasingProduct etc), and more importantly, even simpler to deal with the actual data you're fetching!

I created a simple project implementing this.

I hope this article inspired you to simplifying your redux code quite a bit. Thanks for reading!

Handling metadata in Redux

Did you know that you can reload the current webpage in over 500 different ways?

Many years have passed since your (grand) parents surfed the web with Netscape Navigator, or Internet Explorer was actually used by the people of the web. Browsers have not always had the same version, and neither have the various web standards.

Reloading the window in JS

In order to NOT break existing websites, old syntax has never been removed when new features are added. This makes JavaScript extra exotic for experienced developers, but quirky and cumbersome for new ones.

For example, did you know that JavaScript has at least 500 different ways to reload a window?!

10 randomly picked examples

This is simply insane!

Or, you could go for the even crazier approach:

(hint: run it in the console)

As you can see, these quirks are caused by the fact that the JavaScript language allows for different ways to write essentially equivalent code. Here’s an example:

location.href = location versus location['href'] = location

where both snippets in practice does the exact same thing.

Discussing which one of the 500+ ways to reload is the best is like discussing wheter you should use Emacs or Vim, or Flow or TypeScript. The most important thing, I guess, is readabiliy - making sure you and all co-developers understand.

So perhaps not the self['location']['assign'](window['location']) part.

Oh, by the way. Almost forgot. Caused by the fresh off-the-shelf history API, we now got even more ways to reload a window in JavaScript. After all, we don't want to break the web?

Tomorrow, choose one of the 500+ ways to reload the window to get the latest hatch of the JavaScript advent calendar.

window.history.go(0), JavaScript !

2-Dec

Today's posts

Public key certificates

Handling metadata in Redux

Don't break the web