Shivam Singhal's Blog

Creating accordions with native HTML

Shivam Singhal — Sat, 12 Dec 2020 14:29:48 GMT

Accordions are one of the most commonly used UI components for any website. For example FAQs section of the website, where only the question is shown, and when clicked the answer just opens up. Generally, we handle this by creating 2 divs and adding some javascript to handle the open and close of the accordion. But recently I stumbled upon this hidden gem in HTML that eliminates the need of all this -

We can simply design a simple FAQ or summary section with

HTML tag without using Javascript!!! 🤯🤯🤯. And the best part... it is supported by all the modern browsers (obviously except IE :( ) - browser compatibility.

Using
tag

There are two elements here:

and

is the wrapper for all the content you want to show and hide, and

contains the — well, the summary and title of the section.

is optional, if you do not add it, the browser will use some default text. For example, in Firefox and Chrome, it is Details. Below is a sample HTML markup:

<details>
  <summary>Detailssummary>
  <p>Something small enough to escape casual notice.p>
details>

And it will render like:

This markup can be designed with CSS as any other HTML element. Now for creating beautiful accordions all you need is just HTML and CSS (and a will to let go of IE).

Demo: https://itsopensource.com/demos/details/

References

MDN: details

Cheers.

Content Security Policy - protect your website from XSS attacks

Shivam Singhal — Tue, 08 Dec 2020 12:48:10 GMT

Problem

It's very common while building any project we use certain third party libraries, in the case of Javascript; npm packages, which recursively use more packages, and eventually your code includes a huge chunk of third party code.
There is nothing wrong with it, there is no point re-inventing the wheel. We include the required library, make our code work, write tests. Deploy to a staging environment, pass through automation and finally deploy to production.

The problem is when a library tries to load remote content on our website. It can be an image, font, style, or even Javascript. This content bypasses all our tests, checks, and is executed directly on production. Even worse we don't know where the content is being served from.

Content Security Policy

Content Security Policy (CSP) is a W3C specification that helps to avoid XSS attacks. CSP enables developers to define rules for fetching the resources(images, javascript, fonts, etc.) on the client browser. Developers can define policies to allow/restrict loading any resource, restrict resources to load only from certain domains, and disallow from any other domain. For example, you can write a CSP to restrict browsers to load images only from example.com, any images from other domains will be not loaded and would throw errors. In addition to resources, CSP also offers control over the embeds.
In the following example, the CSP forces to load images/scripts only from self domain and prevents the loading of images from other domains.

From the W3c specification docs:

One of the CSP goal is to mitigate the risk of content-injection attacks by giving developers fairly granular control over

The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker

The execution of inline script

Dynamic code execution (via eval() and similar constructs)

The application of inline style

How

CSP can be implemented in following two ways:

Specify in HTTP headers
```
Content-Security-Policy: __Policy__
```

Specify in META tags

<meta http-equiv="Content-Security-Policy" content=" __Policy__ ">

Defining a policy

The Policy is the accumulation of directives which defines the allowed location of each resource, no directive means allowed for all. Some of the useful directives are the following:

default-src : This defines the loading policy for all types of resources.
script-src : This defines the loading policy for all javascript, from where javascript can be loaded.
img-src : This defines the loading policy for all images, from where images can be loaded.

List of directives for the other resources is here.

Some examples of policies are:

```
Content-Security-Policy: default-src 'self';
```
This would allow resources only from the same domain, and all other resources will fail to load.
```
Content-Security-Policy: img-src example.com;
```
This would allow images only from example.com, and all other images will fail to load.
```
Content-Security-Policy: default-src 'self'; img-src example.com;
```
This would allow any resources to load only if from the same domain, except images which can be from example.com too.

Reporting

CSP also provides a way to send violation reports, in case any logging is required, via report-uri directive.

`Content-Security-Policy: default-src 'self'; report-uri http://example.com/cspfails`

The reports will be sent as POST request and with following JSON:

{
 "csp-report": {
   "document-uri": "http://example.com/",
   "referrer": "",
   "blocked-uri": "http://example.com/some_malware.js",
   "violated-directive": "default-src self",
   "original-policy": "default-src 'self'; report-uri http://example.com/cspfails"
 }
}

Risks

Before defining a CSP you should be completely aware of all the resources and respective origin required for your webapp, else some vital resources may be blocked and eventually random bugs. In case you are not sure what all resources are being required for running your web page smoothly, you can implement the CSP in reporting mode, in this way the violations will be reported but no resource will be blocked, once you are sure what are the resources really required, you can implement CSP. To do this instead of Content-Security-Policy we need to use Content-Security-Policy-Report-Only header.

Content-Security-Policy-Report-Only: __Policy__ + report-uri

Resources

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://owasp.org/www-community/attacks/Content_Security_Policy

How to call a function on URL change in javascript

Shivam Singhal — Sat, 05 Dec 2020 19:01:27 GMT

Modern JS frameworks tend not to reload the page but manipulate DOM and change URL path for internal navigation, for performance and smooth UX. But since there is no page reload, window.onload event does not get triggered for subsequent navigation. We run into a situation where we need to call a function whenever URL path changes (not the hash).

Problem

The itsopensource.com blog is built using gatsby, we wanted to add google analytics to this, but instead of using google tag manager, we tried to restrict what data is sent to google and in this process, we need to send XHR request on every page load. We created a function sendTelemetry and called it on window.onload. This works as expected (partially), whenever the page is loaded the XHR is sent, but gatsby do not reload the page while changing the URL when any blog link is clicked, so XHR is sent only once per session and not on subsequent page loads.
Javascript does not provide any native listener to path change (not hashchange).

Solution

The history API maintains complete the navigation state. Whenever a new page is navigated history.pushState is called and page is added to the state. That means this event is called whenever the URL changes. We hooked our function on this, and done :)

(function(history){
    var pushState = history.pushState;
    history.pushState = function(state) {
      // YOUR CUSTOM HOOK / FUNCTION
      console.log('I am called from pushStateHook');
      return pushState.apply(history, arguments);
    };
})(window.history);

Demo

A quick demo can be the following:

Open the browser console on this very page.
Paste the above-written code snippet.
Keep console open and navigate various pages on this blog
You should see a message in console on every navigation.

The first choice for the title was how to hook a function on history.pushState.

Reference: stackoverflow 😉

How to Reduce Node Docker Image Size by 10X

Shivam Singhal — Fri, 04 Dec 2020 15:56:06 GMT

Dockerizing an application is simple, effective, but optimizing the size of Docker Image is the tricky part. Docker is easy to use but once the application starts scaling, the image size inflates exponentially. In general, the node docker image size of the applications is over 1 GB most of the time.

Why the Size matters

Large docker image sizes - Bigger image size requires more space means increased expense.
Long build durations - It takes a longer time to push the images over the network and results in CI Pipeline delays.

Let’s Start The Optimization

Here is our demo application built using the VueJS Application.

Here is the initial Dockerfile.

FROM node:10

WORKDIR /app

COPY . /app

EXPOSE 8080

RUN npm install http-server -g

RUN npm install && npm run build

CMD http-server ./dist

The size of this image is:

It is 1.34GB! Whoops!

Let's start optimizing step by step

1) Use Multi-Stage Docker Builds

Multi-stage builds make it easy to optimize Docker images by using multiple intermediate images in a single Dockerfile. Read more about it here. By using multi-stage builds, we can install all dependencies in the build image and copy them to the leaner runtime image.

FROM node:10 AS BUILD_IMAGE

WORKDIR /app

COPY . /app

EXPOSE 8080

RUN npm install && npm run build

FROM node:10

WORKDIR /app

# copy from build image
COPY --from=BUILD_IMAGE /app/dist ./dist
COPY --from=BUILD_IMAGE /app/node_modules ./node_modules

RUN npm i -g http-server

CMD http-server ./dist

Now the size of this image is 1.24GB:

2) Remove Development Dependencies and use Node Prune Tool

node-prune is an open-source tool for removing unnecessary files from the node_modules folder. Test files, markdown files, typing files and *.map files in Npm packages are not required at all in the production environment generally, most of the developers do not remove them from the production package. By using node-prune it can safely be removed.

We can use this to remove Development Dependencies:

npm prune --production

After making these changes Dockerfile will look like:

FROM node:10 AS BUILD_IMAGE

RUN curl -sfL https://install.goreleaser.com/github.com/tj/node-prune.sh | bash -s -- -b /usr/local/bin

WORKDIR /app

COPY . /app

EXPOSE 8080

RUN npm install && npm run build

# remove development dependencies
RUN npm prune --production

# run node prune
RUN /usr/local/bin/node-prune

FROM node:10

WORKDIR /app

# copy from build image
COPY --from=BUILD_IMAGE /app/dist ./dist
COPY --from=BUILD_IMAGE /app/node_modules ./node_modules

RUN npm i -g http-server

CMD http-server ./dist

By using this we reduced the overall size to 1.09GB

3) Choose Smaller Final Base Image

When dockerizing a node application, there are lots of base images available to choose from.

Here we will use alpine image; alpine is a lean docker image with minimum packages but enough to run node applications.

FROM node:10 AS BUILD_IMAGE

RUN curl -sfL https://install.goreleaser.com/github.com/tj/node-prune.sh | bash -s -- -b /usr/local/bin

WORKDIR /app

COPY . /app

EXPOSE 8080

RUN npm install && npm run build

# remove development dependencies
RUN npm prune --production

# run node prune
RUN /usr/local/bin/node-prune

FROM node:10-alpine

WORKDIR /app

# copy from build image
COPY --from=BUILD_IMAGE /app/dist ./dist
COPY --from=BUILD_IMAGE /app/node_modules ./node_modules

RUN npm i -g http-server

CMD http-server ./dist

By using this Dockerfile the image size dropped to 157MB \o/

Conclusion

By applying these 3 simple steps, we reduced our docker image size by 10 times.

Cheers!

Shivam Singhal's Blog

Creating accordions with native HTML

Using tag

References

Content Security Policy - protect your website from XSS attacks

Problem

Content Security Policy

How

Defining a policy

Reporting

Risks

Resources

How to call a function on URL change in javascript

Problem

Solution

Demo

How to Reduce Node Docker Image Size by 10X

Why the Size matters

Let’s Start The Optimization

Conclusion

Using
tag