Business goals are the driving force behind any organization, and they are crucial in the process of creating an IT solution.
Without a clear understanding of a company’s goals, it is difficult to determine how an IT solution will fit into the overall strategy and what it needs to accomplish.

A business goal is a target that an organization aims to achieve, whether it be increasing profits, improving efficiency, or expanding into new markets. These goals are usually defined by the leadership of the organization.

The importance of business goals in the process of creating an IT solution lies in the fact that they provide direction and focus for the project. They help to determine the scope of the solution, the resources needed, and the timeline for completion.

For example, let’s say a company’s goal is to increase efficiency in its sales department. In this case, an IT solution could be developed to streamline the sales process, such as by automating the tracking of leads and customer interactions. This solution would be tailored to the specific needs of the sales department and would be designed to help the company achieve its efficiency goal.

Another important aspect of business goals is that they can help to align an IT solution with the overall strategy of the organization. By understanding the direction that a company is heading in, it is possible to create an IT solution that supports and enhances that direction.

Project without a business goal

When a project does not have a clear business goal, it can lead to several problems. Here are a few examples:

• Lack of direction: Without a specific target to aim for, it can be difficult to determine the direction of the project and what needs to be done. This can lead to wasted time and resources as the team tries to figure out the purpose of the project.
• Misalignment with company strategy: Without a business goal, it is harder to align the project with the overall strategy of the organization. This can lead to the IT solution not being integrated into the company’s operations or not supporting its long-term goals.
• Difficulty measuring success: Without a business goal, it is harder to determine if the project has been successful. This can make it difficult to justify the investment in the IT solution and can lead to a lack of support for future projects.
• Limited scope: Without a business goal, the scope of the project may be too broad or too narrow. This can lead to the IT solution being overly complex or not providing enough value to the organization.

Conclusion

Not having a clear business goal can lead to a lack of direction, misalignment with company strategy, difficulty measuring success, and limited scope.
It is important to define business goals at the outset of a project to ensure that the IT solution meets the needs of the organization and helps to achieve its goals.

JSON Web Token (JWT) is the compact, URL-safe means of representing claims to be transferred between two parties.

JWT is a string, that consists of three parts: a header, a payload, and a signature.

The header of a JWT

The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.

Example of JWT header which specifies that the HMAC SHA-256 algorithm will be used to sign the JWT:

{
  "alg": "HS256",
  "typ": "JWT"
}

The payload of a JWT

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. The claims in the JWT are encoded as a JSON object.
There are three types of claims: registered, public, and private claims. Registered claims are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims.
Some examples of registered claims include “iss” (issuer), “exp” (expiration time), and “sub” (subject).
Public claims are claims that are defined by the user but are not registered. Private claims are claims that are used only in the context of the user and the application.

Example of JWT claims set with registered exp and custom name headers:

{
  "exp": 2218239022,
  "name": "Tomasz Zwierzchoń"
}

The signature of a JWT

The third part of the token is the signature, which is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn’t changed along the way.

Example of JWT signature:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

In this example, the signature is created by taking the base64Url-encoded header, concatenating it with the base64Url-encoded payload, and then signing it with a secret using the HMAC SHA-256 algorithm. The resulting signature is then appended to the header and payload to create the complete JWT.

What is the use of JWT?

JWTs are often used to authenticate users. When a user logs in, the user’s credentials are sent to the server. If the credentials are correct, the server sends a JWT back to the user. The user can then use this JWT to authenticate subsequent requests to the server. This allows the server to trust that the requests are coming from an authenticated user, without requiring the server to maintain a session or ask the user to authenticate again for every request.

Overall, JWTs provide a simple, compact, and secure way to transmit information between parties, and are commonly used in modern web applications.

This is a follow-up to my article about JWT.
It became clear that many developers do not fully understand what MAC and HMAC are and how they work. Therefore, I wanted to provide a follow-up discussing these concepts in more detail.

Message Authentication Code (MAC) is a cryptographic technique that is used to verify the authenticity and integrity of a message.
It involves the use of a secret key to generate a MAC value, which is appended to the message. The recipient of the message can then use the same key to recalculate the MAC value and compare it to the one received with the message. If the values match, the authenticity and integrity of the message can be verified.

HMAC (Hash-based Message Authentication Code) is a specific type of MAC that uses a cryptographic hash function (e.g., SHA-256) in combination with a secret key to generate the MAC value. This makes it more secure than MAC, as it is more resistant to attacks that try to break the key.

Here is an example of how HMAC could be used in a RESTful API:

1. The client sends a request to the server to retrieve some data.
2. The server calculates the HMAC of the request using the secret key and a hash function (e.g. SHA-256).
3. The server includes the HMAC value in the response to the client.
4. The client calculates the HMAC of the response using the same secret key and hash function.
5. The client compares the calculated HMAC value to the one received from the server. If they match, the client can trust that the response has not been tampered with and is authentic.

This example assumes that the secret key is shared between the client and server and is not transmitted over the network.
For example, Shopify apps should validate HMAC to ensure that the request received by them has actually originated from the Shopify platform.

Working for some time with JSON Web Signature (JWS) I came to the conclusion that many developers do not understand what it is and how it works.

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.

There are two defined serializations for JWSs: a compact (described in this article) and a JSON.

The compact serialised JWS is a string containing three parts (in order) joined with a dot (“.”):

• Header,
• Payload,
• Signature.

Example of the compact serialised JWS string: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjIyMTgyMzkwMjIsIm5hbWUiOiJUb21hc3ogWndpZXJ6Y2hvxYQifQ.t3VhQ7QsILDuV_HNFSMI-Fb2FoT7fuzalpS5AH8A9c0
Each part is BASE64URL encoded.

The Header describe the digital signature or message authentication code (MAC) applied to the the Payload and optionally additional properties of the JWS.

Header part before encoding is a JSON structure (example below):

{
  "alg": "HS256",
  "typ": "JWT"
}

The Header parameter names (object keys) within the Header must be unique. There are registered Header parameter names:

• “alg” (required) — algorithm, which identifies the cryptographic
  algorithm used to secure the JWS;
  It can be set to ‘none’, which indicates that the Signature must be an empty string!
• “jku” — (optional) JWK Set URL is a URI that refers to a resource for a set of JSON-encoded public keys, one of which corresponds to the key used to digitally sign the JWS;
• “jwk” — (optional) JSON Web Key is the public key that corresponds to the private key used to digitally sign the JWS. This public key is represented as a JSON Web Key [JWK];
• “kid” — (optional) key ID is a hint indicating which key was used to secure the JWS. It can be used to inform recipient that key is changed;
• “x5u” — (optional) X.509 URL is a URI that points to a resource for the X.509 public key certificate or certificate chain corresponding to the private key used to digitally sign the JWS;
• “x5c” — (optional) X.509 certificate chain contains the X.509 public key certificate or certificate chain corresponding to the private key used to digitally sign the JWS;
• “x5t” — (optional) X.509 certificate SHA-1 thumbprint (fingerprint) is a
  base64url-encoded SHA-1 thumbprint (a.k.a. digest) of the DER
  encoding of the X.509 public certificate [RFC5280] corresponding to the private key used to digitally sign the JWS;
• “x5t#S256” — (optional) X.509 certificate SHA-256 thumbprint (fingerprint) is a base64url-encoded SHA-256 thumbprint (a.k.a. digest)
  of the DER encoding of the X.509 public certificate corresponding
  to the private key used to digitally sign the JWS;
• “typ” — (optional) type is used by JWS applications to declare the media type of the complete JWS;
• “cty” — (optional) content type is used by JWS applications
  to declare the media type of the Payload.

In our example header, we can see that JWS type is JSON Web Token (JWT) and that Payload is secured by HS256 (HMAC with SHA-256) cryptographic algorithm.

The payload can be any content. It can be JSON but it is not needed.

The signature is computed in the manner defined for the particular algorithm being used (and declared in the Header) from ASCII(BASE64URL(UTF8(JWS Protected Header)) || ‘.’ ||BASE64URL(JWS Payload)).

Important note: Do not confuse BASE64URL with BASE64!
In BASE64URL:

• all trailing ‘=’ are removed
• ‘+’ is replaced by ‘-’
• ‘/’ is replaced by ‘_’.

JWS Detached is a variation of JWS that allows you to sign content (body) of HTTP request or response without its modification.

The HTTP header “x-jws signature” is added, which contains data allowing to check whether the message has not been changed on way from the sender to the recipient.

JWS Detached generation algorithm is very simple:
a) Generate a standard JWS using compact serialization using HTTP body as a payload,
b) Turn the middle part (Payload) into an empty string,
c) Put final string in the HTTP header “x-jws signature”

Example of the JWS Detached string: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..t3VhQ7QsILDuV_HNFSMI-Fb2FoT7fuzalpS5AH8A9c0

Validation HTTP message with JWS Detached is simple too:
a) Get the HTTP header “x-jws signature”,
b) Get BASE64URL HTTP body
c) Put generate string b) into the Payload section
d) Validate JWS

JWS is often found in tandem with JSON Web Token (JWT), JSON Web Encryption (JWE) or JSON Object Signing and Encryption (JOSE). Many similar shortcuts may lead to confusion.

JSON Web Signature (JWS) and JWS Detached for a five-year-old was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

It is easy with node-jose library when you know how to do it.
It took me some time to learn, because this information is missing in the documentation. Luckily it was in tests.

The missing example (creates a JWT with an embedded ‘jwk’):

// {input} is a String
// {key} is from jwk keystore

jose.JWS.createSign(
  {
    fields: {
      typ: 'JWT',
    },
    format: 'compact',
    opts: { protect: false },
  },
  {
    key,
    reference: 'jwk', // MISSING in documentation
  },
).update(input, 'utf-8')
  .final()
  .then((result) => {
  // {result} is a JSON object -- JWT using the JSON General Serialization
  });

I hope I saved you some time.

Today I would like to share small hint about how to get licenses from all packages, used in your javascript project. It’s very useful to make Bill Of Materials for your legal department.

Assuming you are using yarn (if no — start right now), go to your project directory and paste this command:

yarn licenses list

To get only licensees use (for yarn 1.7.x):

yarn licenses list | awk '/^├─/ {$1=""; print $0}'

That’s all folks. I hope you will find it handy.

This has proven to be a challenge. We cannot find any working example. Documentation did not cover our use case.

So for all of you with this problem I’ve created a boilerplate. I hope it will save you a couple of hours.

In the part #3 of my guide we were discovering Sets. Now it’s time for maps.

Maps are ordered lists of key-value pairs. The key and the value can have any type. This is the main difference between objects keys and maps.

Try this code:

const log = x => console.log(x);
const objectMap = Object.create(null);

objectMap[123] = 'abc';
log(objectMap['123']);
log(objectMap[123]);

const map = new Map();
map.set(123, 'abc');
map.set('123', 'cba');

log(map.get(123));
log(map.get('123'));

We can even use objects as a keys:

const log = x => console.log(x);
const object1 = {};
const map = new Map();

map.set(object1, 'some value');
log(map.get(object1));

We can use it to store addtional data in objects without a need of a jQuery data method:

const log = x => console.log(x);
const el = document.querySelector('html');
const map = new Map();

map.set(el, 'some value');
log(map.get(el));

This approach has one problem. When we delete a node from DOM it is still present in the map. But we can fix it easily. Weak maps to the help!

In weak maps every key must be an object and when key reference outside map is deleted, the key-value pair is removed from it.

Try this code:

const log = x => console.log(x);
const query = x => document.querySelector(x);
const body = query('body');
const map = new WeakMap();

body.innerHTML = '<div id="div1"></div><div id="div2"></div>';

let el = query('#div1');
map.set(el, 'some value');
log(`Before delete: ${map.get(el)}`);

el = null;
log(`After delete: ${map.get(el)}`);

More about Maps here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map

Forward Thinking — a never-complete guide to modern JavaScript #5 Maps was originally published in Orba on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous post we’ve met magic three dots „…” alias spread operator. Those dots are worth exploring before we will go to maps.

Main objective of the spread operator is to spread the elements of an array or an iterable object.

Try this code:

const log = x => console.log(x);
const myFunction = (a, b, c) => {
  log(`a: ${a}, b: ${b}, c: ${c}`)
};
const myArr1 = [1, 2, 3];

myFunction(...myArr1);

As you can see each element in the array is passed as the argument to the function. But we can do more! A few examples below.

Any argument in the list can use spread syntax:

const log = x => console.log(x);
const myFunction = (a, b, c) => {
  log(`a: ${a}, b: ${b}, c: ${c}`)
};
const myArr2 = [1, 2];

myFunction(...myArr2,69);

Coping one array to the second or combining them:

const log = x => console.log(x);
const myArr3 = ['Lorem', 'Ipsum', 'Sit', 'Amet'];

const myArr4 = [...myArr3];
log(myArr4);

const myArr5 = [2, 3, 5, 7, 11, ...myArr3];
log(myArr5);

myArr5.unshift(...myArr3);
log(myArr5);

Or we can use it to deconstructions:

const log = x => console.log(x);
const [a, b, ...rest] = [1, 2, 3, 4, 5, 6, 7];
log(`a: ${a}, b: ${b}, rest: ${rest}`);

I hope you will like those dots as much as I do.

Forward Thinking — a never-complete guide to modern JavaScript #4 Spread Operator was originally published in Orba on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve discovered that many of us JavasScript programers haven’t noticed that ECMAScript6 introduced two new types of collections: sets and maps.

Let’s start today with a set. What is it, you may ask? The set is a collection of unique elements.

Try this code:

const log = x => console.log(x);

const mySet = new Set();
mySet.add(123);
mySet.add('123');
mySet.add(123);
log(mySet);

As you can see, we have only 2 elements in our set, as expected.

We can initialize our set using an array:

const log = x => console.log(x);

const mySecondSet = new Set([123,"123",123]);
mySecondSet.add("123");
log(mySecondSet);

And convert it to an array (with a little help from a spread operator):

const log = x => console.log(x);

const myThirdSet = new Set([123,"123",123]);
const myArray = [...myThirdSet];

log(myArray);

With this knowledge we can quickly build functions which removes duplicates from an array :)

const log = x => console.log(x);

const removeDuplicates = items => [...new Set(items)];
const arrayWithDuplicates = [1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 5, 6];
log(removeDuplicates(arrayWithDuplicates));

More about Sets here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set

Forward Thinking — a never-complete guide to modern JavaScript #3 — Sets was originally published in Orba on Medium, where people are continuing the conversation by highlighting and responding to this story.