Have you ever wondered what the real difference is between == and === ?

Coercion

Typecasting. Converting. Coercion. We tend to have many names for the things we love. Coercion in JavaScript is really just about converting one value to another. For example, 5 + '' will convert the number 5 to a string. If we assign this expression to a variable (or wrap the expression in parentheses), we will suddenly have available methods from the string prototype. For example, we can retrieve the field .length.

This is an example of implicit type coercion - we do not explicitly write out that we want to convert to a string. All lines below are examples of explicit type coercion to numbers:

However, JavaScript also has more subtle ways of coercion:

Here, the plus sign indicates trying to retrieve the number value representation of the Date object. Read more about this fun and a tad confusing unary operator in Kristofer's article from earlier this fall.

My favourite way of do explicit coercion in JavaScript is with !:

The ! is actually coercing the statement to a boolean and turning the sign in the same operation. Hence, we may use the operator to check the truthyness or falsiness of all values in JS: !!foo. Tada, double negation has never been more fun! 🎉

Or, you can go for the exam way of understanding truthyness/falsiness by memorizing the following list of all falsy values in JS (the rest are truthy):

Equality checks

Equality checks have for many been an annoying affair to understand well. But fear not, the difference between == and === is best explained by JS evangelist Kyle Simpson:

The correct description is: "== allows coercion in the equality comparison and === disallows coercion."

With this rule of thumb in mind, the following results should be expected:

Coercion and equality checks

By introducing Typescript to your Redux code and implementing it properly, Typescript can help you write better and less error prone code. In this article we will take a look at a simple Redux example and explore the benefits of introducing Typescript.

When using redux in JS your typical implementation often looks like this:

The reducer can look like this:

Now imagine that you want to introduce a new action, but forget to change your reducer. In small applications this is rarely an issue, but as complexity grows faults like these can often sneak in. The reverse example is also relevant. An action is removed since it's no longer needed, but you're unsure if it can be removed from the reducer. This is where Typescript comes to the rescue.

Actions look like this:

Here we define three new interfaces for our actions. The main upside so far it that the code is more explicit and we have a concrete definition of every action, however the main benefit becomes clear when we change our reducer to Typescript.

Say we now introduce a new action, registerPerson, like this:

If we forget to update our reducer Typescript will automatically complain, because of the assertNever(action).

One other benefit of introducing Typescript to Redux is that we now only have access to the properties defined in our interface in each switch case. Typescript (and the IDE, if configured correctly) is smart enough to understand which property belongs to which action type, hence the compiler can validate that only the ‘age’ property within the switch case SUBMIT_AGE is allowed.

Introducing Typescript to your Redux code

You have been told that two-factor authentication is important, but why, and what is it really?

For most people, their greatest security interaction in their everyday life is with passwords. Most internet users have grown accustomed to handling a multitude of passwords for different services. Unfortunately, we humans are bad at remembering stuff, and this causes most of us to reuse passwords. This is bad!

In the last year, a service from Troy Hunt called HaveIBeenPwned has become much more widely known, and has shone a light on the issue of password leaks. When a service is hacked, or otherwise lose their data, your password can be among the information that is suddenly available to anyone. If you have used the same combination of username/email and password anywhere else, that account has also become compromised. While the obviously best solution to this problem is to not reuse passwords, this may not be feasible to everyone, and it still does not protect your account should your unique password be leaked.

Two-factor authentication to the rescue! As the name implies, this sets up a second "factor" that must be known or accessible in order to log in. Most used is a SMS-message to a known phone number containing a 6-digit code. Even if an attacker knows your username and password, they would still need access to your phone, greatly reducing the chance of them being able to log in.

Unfortunately, text messages are not the most secure form of communication. They are sent unencrypted on the network of the carrier, and several attacks exists to gain access to two-factor SMS codes. One involves porting the phone number in question to another carrier using social engineering. Therefore, better options should be considered.

The most accessible solution that greatly increases security is the use of Time based One Time Passwords, known as TOTP. When you sign up for a service offering this, you will be shown a QR-code that can be scanned with e.g. Googles "Authenticator"-app, Twilios "Authy", or any other app implementing the open TOTP-standard.

When you need to log in after this, you will be asked to provide a 6 digit code generated by the app. The code changes every 30 seconds. The reason this can work is because you and the service you are logging into share a secret, and you both know what time it is. Through some clever calculations, you can both compute the same token, but be sure that no one without the secret can do the same.

Better yet is the use of a physical device such as a YubiKey. It looks like a USB-stick and can either be permanently installed at the machine you usually use, or it can be kept on your keychain to be available wherever you go. When you log in to a service where the YubiKey is enabled, the physical presence of the device is checked, providing a strong likelihood that the log in attempt is legit. The barrier to entry can be quite high for YubiKey, as you would have to get accustomed to carrying it with you wherever you go, should you wish to use a certain service.

The biggest downside to using two-factor solutions is the need for storage of recovery codes. Should you lose access to the two-factor device, that being your phone or your YubiKey, you will need the recovery codes to regain access to your accounts. These must be stored in a safe location. The best option is simply to store them in a safe place in your house, or sync them to an encrypted cloud service. The worst mistake you can do is to ignore the message when you activate two-factor authentication that implores you to save your recovery codes. Without these, your accounts may be lost for ever!

All in all, two-factor authentication provides a huge improvement in security for your accounts, and you should activate this on every service that offers it. For more sensitive services like finances or systems containing a lot of personal information, you should consider using a hardware two-factor device like YubiKey for maximum protection. Just remember to store your recovery codes in a safe location!

6-Dec

Today's posts

Coercion and equality checks

Introducing Typescript to your Redux code

Two-factor authentication