DEV Community: TRIGO | We speak human and computer

How to customize Keycloak themes

David Wippel — Thu, 21 Apr 2022 11:55:52 +0000

In this insight, you will learn how Keycloak Themes are structured and how to come up with your own custom theme.

Because we believe that learning is best done when putting everything into practices, we will start off by setting up a development environment. Right after, we will go over the types of themes and the folder structure. Closing with how to add customization and build your own Keycloak theme.

Before we get started with all the details, a quick recap of what Keycloak is and why we care about it.

What is Keycloak?

Keycloak is an open-source identity and access management or IAM solution, that can be used as a third-party authorization server to manage your web or mobile applications' authentication and authorization requirements.

It lifts the heavy weight of implementing a stable and secure user authorization and authentication, from the shoulders of developers.

At TRIGO, we use it for all of our projects. It saved tons of time and money. Kept us staying sane when integrating AuthN/AuthZ into an application. We love Keycloak.

Now let's dive right into it.

Setting up a development environment

You could either download Keycloak and run it natively on your machine, or spin up some container using docker or podman.

We at TRIGO are heavily into containerization. Therefore, we will use the second option for this tutorial.

To make things even simpler for you, we have prepared a fully functional setup as Git repository.

Before proceeding with this tutorial, please take your time to check out the repository and follow the instructions found in the README file. If you got any questions, please feel free to open an issue.

Theme types

With a single theme, you can provide one or more types of customization.

An overview:

Type	Description	Location of the demo repository
Common	Files (resources) shared along all theme types	`themes/keycloak-provided-themes/keycloak/common`
Account	All things related to the Account management (self-service) area.	`themes/keycloak-provided-themes/base/account` and `themes/keycloak-provided-themes/keycloak.v2/account`
Admin	The admin console. Yes, the very extensive area can be customized too.	`themes/keycloak-provided-themes/base/admin` and `themes/keycloak-provided-themes/keycloak.v2/admin`
Emails	Everything you need to customize Emails sent by Keycloak	`themes/keycloak-provided-themes/base/email`
Login	User-facing public pages like login, password reset and so on.	`themes/keycloak-provided-themes/base/login` and `themes/keycloak-provided-themes/keycloak/login`
Welcome	The welcome page shown when spinning up Keycloak and opening its landing page	`themes/keycloak-provided-themes/keycloak/welcome`

Hint: Instructions on how to configure a theme can be found in the Keycloak Documentation.

Structure of a theme folder

Every theme must consist of one or more type related subdirectories.

It's a 1:1 reference to the theme types mentioned above.

Structure of a theme type folder

Every theme type folder must have at least a theme.properties file. It contains basic instructions for Keycloak.

Furthermore, it consists of one or more of the following folders

Folder	Description
messages	Contains one or more messages_XX.properties files. They are part of the i18n mechanism of Keycloak
resources	Every image, CSS or JavaScript file that is required to power the theme type is found here.

Note: The email type is a little different. It contains an HTML and text folder containing the email templates for HTML and text emails. All as FTL files.

Besides that, a theme type folder usually comes with many template files (.ftl file ending). They represent all the different pages Keycloak has.

All your base belongs to me. Theme Inheritance explained

You might have noticed that for most types, there are multiple places where you can find related files. That's because Keycloak themes are built with inheritance in mind. Everything is (or it can be) based on base (phun intended!). You could, theoretically, start from scratch, but we don't recommend that unless you have a special use case. It's just a lot of work to provide everything you need for a fully functional theme.

Theme type entry point: theme.properties

Let's have a look at the entry point of the login type.

This is from themes/keycloak-provided-themes/keycloak/login

The first line of theme.properties is:

parent=base

With this, we instruct Keycloak to inherit our login type from the base theme. We can then focus on the things we like to change instead of starting from zero.

FTL - Faster than light or Freemarker

Freemarker is a template language like Pug, Mustache or EJS. If you are familiar with the primary template language of your ecosystem, you should be familiar with the core concepts of freemarker too.

I still recommend going through the “Template Author Guide”. The Keycloak Login Theme makes heavy use of the FTL inheritance features. So better be prepared to dig in deep.

Data Models for your templates

Keycloak uses numerous data models within their template files. They are - let just put it that way - not very well documented.

To get at least a basic understanding, these two files from the Keycloak Source Code are a good starting point:

For Theme Type: Login

https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java

For Theme Type: Account

https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/forms/account/freemarker/FreeMarkerAccountProvider.java

What other tech is included?

For the time of writing this insight, Keycloak 17 is the newest version available. There are announcements that the current angular1 based admin and account theme is replaced by a React-based solution anytime soon. Keycloak 15 already has an early version of that included. It can be found as keycloak.v2 theme here: themes/keycloak-provided-themes/keycloak.v2

The Login part of the theme uses an earlier version of the Patternfly Framework. Files:

themes/keycloak-provided-themes/keycloak/common/resources/web_modules/@patternfly

Since there is no version information available, it's hard to tell which version of Patternfly it is, but all required resources are included.

v4 of Patternfly is a remarkable framework found here.

How to customize a theme type?

For all of you who, me included, are like: Ok Patternfly is cool and what not , but I want to bring my own stuff to the table. Tailwind, Vue, Svelte, Chakra, ... just a little more patience.

Before we explore how to create a custom theme with your favorite tech stack, I think it's important to understand the structure of the default theme.

For this tutorial, I will focus on the login theme type further on. I assume that that's the type most of you want to customize anyway. Also, when you understand that part of a theme, the e.g. account part is a piece of cake for you.

The first file you should examine closer is template.ftl. It contains the basic HTML page structure and all <#nested> instructions that are used in the various templates. It defines a macro that is used in pages like login, register, login-reset-password, …

Speaking of the different templates. A quick excursion on what files are the more relevant ones:

Login theme type most relevant templates

Folder	Description
login.ftl	Username/Password login
register.ftl	User registration
login-reset-password.ftl	Password Reset
login-update-password.ftl	Password Update
login-otp.ftl	OTP/2FA login
error.ftl	Error page

Back to customizing the login theme type

Within the FTL templates various data-models are used as mentioned above. It's beyond the scope of this tutorial to explain every detail. I strongly recommend to set aside some time to go through ALL the files and explore how the various properties are used and for what purpose.

If you got any questions, please feel free to drop me an email at david@trigodev.com

CSS Classes confusion

Said that, there is one detail I like to explain a bit. How CSS classes are handled. It was a source of confusion for me when starting with Keycloak theme development. CSS Classes are set via properties that are defined in the theme.properties file of the login theme type.

Example:

I don't get the reason behind that decision. I guess the idea was to provide a way to customize the CSS classes in a central way. It was one of the first things I dropped when building the first themes for ourselves.

Included Messages for i18n

Let's assume you have added some new i18n message to one of the message_xx.properties files in the messages' folder. For example, some marketing information you want to include on the login page.

Freemarker provides a msg function to include i18n messages.

Note: It will refer to the language currently selected by the user. Keycloak uses Browser information to determine the language, but only if the language is configured.

Example:

${msg("doForgotPassword")}

Some notes on security

All things you know about web security are relevant for Keycloak themes too. Keep in mind that you are basically building a website (or web application for the account/admin theme type).

Therefore, just a few short notes on security:

Sanitizing all user-generated content

Keycloak provides a kcSanitize function to sanitize HTML content. I highly recommend using that function when including user provided HTML content in any way.

Example:

${kcSanitize(message.summary)?no_esc}

Code found here.

CSRF Protection

According to the OAUTH2 Specification, CSRF Protection is done via a state query parameter. Keycloak handles that for us via the url.loginAction property used as form action

<form id="kc-form-login" onsubmit="login.disabled = true; return true;" action="${url.loginAction}" method="post">

Don't change that unless you know exactly what you are doing here.

A more detailed explanation on how the state parameter helps to prevent CSRF attacks can be found here.

Bring your own stuff

As you might have guessed, besides learning all the details about the tech stack involved and some innards about the data-model used, there is nothing special to a Keycloak theme. It's just web development. So, why not bring your well-known framework of choice to the table? The good news is that, there is no reason not to go down that road.

In fact, we do that by using Tailwind to style our themes.

I've included an example to the Git Repository. You are welcome to use that as a starting point (see themes folder).

Note: The themes are mapped into the docker-compose.yml to make them visible to Keycloak. You have to add your own theme to that by duplicating and adopt this line in the docker-compose.yml

./themes/tailwind-example/:/opt/jboss/keycloak/themes/tailwind-example/

Recap

We have learned how Keycloak themes are structured, what files are important, how inheritance works for themes and how to get started with custom themes.

I've tried to add as many lessons learned as possible. If anything isn't super clear or missing, please point that out.

Again, if you got any questions, please reach out to me.

How to test a Hasura Api with Jest

Thomas Peklak — Fri, 27 Aug 2021 06:51:18 +0000

Hasura provides an easy way to build an API and testing it is as easy as testing any other API. We will focus on the GraphQL API but everything presented here can be applied to the REST API as well.

Use Case

We will model a todo list for different users. Each user should only see her own todo items and none of a different user.

Tools

We will use

Docker: to setup Hasura and PostgreSQL
Jest: as our test runner
graphql-codegen: to generate an SDK including Typescript support to have good autocompletion in the editor
JWT: to set the authenticated user

... to test that the business logic in Hasura works as intended. Business logic can live in Hasura itself (e.g. permissions) or within the database (e.g. views, constraints, et al.). Note that it does not make sense to test that Hasura does its job correctly as it is by itself well tested. If you just create a resource without any logic you probably do not want to test it.

If you want to follow along you can clone the sample repository at trigo/hasura-api-testing.

Hasura and PostgreSQL Setup with Docker Compose

We use a slightly modified version of Hasura's docker compose file.

Changes include:

HASURA_GRAPHQL_JWT_SECRET for user authentication
cli-migrations image so that migrations are automatically applied
graphql-engine/volumes to be able to store migrations and metadata in the repository
exposed port for PostgreSQL to be able to connect directly to PostgreSQL

// docker-compose.yml
version: "3.6"
services:
  postgres:
    image: postgres:12
    restart: always
    ports:
      - "5432:5432"
    volumes:
      - db_data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: password
  graphql-engine:
    image: hasura/graphql-engine:v2.0.3.cli-migrations-v3
    ports:
      - "8080:8080"
    depends_on:
      - "postgres"
    restart: always
    volumes:
      - ${PWD}/migrations:/hasura-migrations
      - ${PWD}/metadata:/hasura-metadata
    environment:
      HASURA_GRAPHQL_METADATA_DATABASE_URL: postgres://postgres:password@postgres:5432/postgres
      PG_DATABASE_URL: postgres://postgres:password@postgres:5432/postgres
      HASURA_GRAPHQL_ENABLE_CONSOLE: "true"
      HASURA_GRAPHQL_DEV_MODE: "true"
      HASURA_GRAPHQL_ENABLED_LOG_TYPES: startup, http-log, webhook-log, websocket-log, query-log
      HASURA_GRAPHQL_ADMIN_SECRET: admin-secret
      HASURA_GRAPHQL_JWT_SECRET: '{"type":"HS256", "key": "3EK6FD+o0+c7tzBNVfjpMkNDi2yARAAKzQlk8O2IKoxQu4nF7EdAh8s3TwpHwrdWT6R", "claims_map": { "x-hasura-allowed-roles": { "path": "$$.roles" }, "x-hasura-default-role": { "path": "$$.roles[0]" }, "x-hasura-client-id": { "path": "$$.clientId", "default": "" }, "x-hasura-user-id": { "path": "$$.userId", "default": "" }, "x-hasura-username": { "path": "$$.username", "default": "" } }}'
volumes:
  db_data:

Start Hasura and PostgreSQL with docker-compose up -d and wait until Hasura is up and running. You can either check via curl localhost:8080/healthz or hasura migrate status --admin-secret admin-secret to see whether all migrations have been applied.

Setup Database and Permissions

When you spin up the compose file within the provided repository you can skip the next steps because migrations and metadata are included and applied automatically when Hasura starts.

Next we create a todo table with properties id, description, is_done, and user:

CREATE TABLE "public"."todo" (
  "id" serial NOT NULL,
  "description" text NOT NULL,
  "is_done" boolean NOT NULL DEFAULT false,
  "user" text NOT NULL, PRIMARY KEY ("id")
);

Permissions

Insert permissions:

When inserting new todos, we do not allow the user to set the user property by herself, instead we use the user-id session variable for the user and only allow the properties description and is_done to be set. id is an autoincrement field and should not be touched by the user either.

Select permissions:

When a user retrieves her todos, we set the custom check user equals x-hasura-user-id to ensure that a user only gets her own todos.

We have now completed our PostgreSQL and Hasura setup and are ready to look into the test setup.

Tests

Code Generation

We leverage @graphql-codegen to generate an SDK for the GraphQL API. It will take all .graphql files under tests, connect to the Hasura GraphQL API and output the SDK in tests/client/graphql.request.ts. This takes over most of the communication between our tests and the GraphQL API and gives us typing information to help us in the editor and in our tests.

You can find detailed information at GraphQL Code Generator on the possibilities to generate code from your GraphQL schema.

First we need a .graphql file that describes how to insert and select todos. It has a query GetTodos that retrieves
all todos and a mutation AddTodo which inserts a new todo item.

// tests/graphql/todo.graphql
query GetTodos {
  todo {
    id
    description
    is_done
  }
}

mutation AddTodo($description: String = "", $is_done: Boolean = false) {
  insert_todo(objects: { description: $description, is_done: $is_done }) {
    returning {
      id
    }
  }
}

graphql-codegen/cli needs a configuration file so it knows where our GraphQL API lives, where to look for source files and where to put the generated SDK. You can also specify plugins which modify the output of SDK. More information can be found in the graphql-codegen plugin index.

We will use

typescript: Generate types for TypeScript - those are usually relevant for both client side and server side code
typescript-operations: Generate client specific TypeScript types (query, mutation, subscription, fragment)
typescript-graphql-request: Generates fully-typed ready-to-use SDK for graphql-request

// codegen.js
module.exports = {
    schema: [
        {
            'http://localhost:8080/v1/graphql': {
                headers: {
                    'x-hasura-admin-secret': 'admin-secret',
                },
            },
        },
    ],
    documents: ['./tests/**/*.graphql'],
    overwrite: true,
    generates: {
        './tests/utils/graphql.request.ts': {
            plugins: [
                'typescript',
                'typescript-operations',
                'typescript-graphql-request',
            ],
        },
    },
};

Now install all necessary npm modules

npm install -D @graphql-codegen/cli @graphql-codegen/typescript @graphql-codegen/typescript-graphql-request @graphql-codegen/typescript-operations

and generate the SDK with npx graphql-codegen --config codegen.js. This should generate an SDK under tests/utils/graphql.request.ts.

Authenticated Requests

The SDK itself does not have an easy way to create authenticated requests with JWT, you need to generate and specify the headers for each request. But we can simply wrap it for our purposes so that authentication headers are automatically sent with each request. The configuration will be sourced from the .env file which should include Hasura and PostgreSQL configuration variables, see .env example

// tests/utils/client.ts

import {GraphQLClient} from 'graphql-request';
import {getSdk} from './graphql.request';
import jwt from 'jsonwebtoken';
import dotenv from 'dotenv';

// source environment variables
dotenv.config();

We have set up the imports and read in the configuration variables. We can now extract the key from the Hasura configuration parameter (see docker-compose.yml above).

let secret = '';
try {
    secret = JSON.parse(process.env.HASURA_GRAPHQL_JWT_SECRET!).key;
} catch (e) {
    console.error(
        'HASURA_GRAPHQL_JWT_SECRET must be parsable json and have property key'
    );
    process.exit(1);
}

The client takes options for either a user or an admin:

User:
- allowedRoles: all roles that a user can have, this will be sent within the JWT
- defaultRole: the role that is currently active, is sent in the x-hasura-role header, but must also be present in the JWT
- userId: the user id
- username: the username
Admin:
- admin: boolean used to make requests with the admin-secret. No other option needs to be present

type UserOptions = {
    allowedRoles?: string[];
    defaultRole: string;
    userId: string;
    username: string;
};

type AdminOptions = {
    admin: boolean;
};

// define the configuration options for the client
type Options = UserOptions | AdminOptions;

If we have a user we map the default role to the x-hasura-role header which corresponds to the role in the Hasura Console permissions tab.

const mapOptionsToHeaders = (options: Options) => ({
    'x-hasura-role': options.defaultRole || '',
});

All other user options are packed into the JWT which will be read by Hasura and provided as variables for permissions.

const generateJwt = (options: Options): string =>
    jwt.sign(
        JSON.stringify({
            roles: options.allowedRoles || [],
            userId: options.userId,
            username: options.username,
        }),
        secret
    );

We can now create the main entry point which takes the options and returns an SDK with a user specific GraphQL client embedded.

export default (options: Options): ReturnType<typeof getSdk> => {
  if (!process.env.GRAPHQL_ENDPOINT) {
    throw new Error("GRAPHQL_ENDPOINT is not defined");
  }
  if (!process.env.HASURA_GRAPHQL_ADMIN_SECRET) {
    throw new Error("HASURA_GRAPHQL_ADMIN_SECRET is not defined");
  }

  // if we do not provide allowedRoles for the client we assume that the defaultRole is an allowed role
  if ('defaultRole' in options && !options.allowedRoles) {
    options.allowedRoles = [options.defaultRole];
  }

We configure a GraphQL client with either an admin user (with an admin secret) or a normal user (with JWT) and pass it to the SDK factory function. This will ensure that all request have the correct headers.

  const client = new GraphQLClient(process.env.GRAPHQL_ENDPOINT, {
    headers: 'admin' in options
      ? { "x-hasura-admin-secret": process.env.HASURA_GRAPHQL_ADMIN_SECRET }
      : {
          Authorization: `Bearer ${generateJwt(options)}`,
          ...mapOptionsToHeaders(options),
        },
  });

  return getSdk(client);
};

Testing Todo Permissions

Recap: We want to ensure that users see only their respective to todos.

Steps:

clear the database before each test
create 2 todos for user Franz
create 1 todo for user Herbert
get todos for user Franz
get todos for user Herbert
test that each user sees only his todos

Import dependencies

import clearDb, {closeConnection} from './utils/clear-db';
import client from './utils/client';

Setup the test and hooks

describe("Todo", () => {
  // reset the database before each run
  beforeEach(clearDb);

  // close PG connection after all tests
  afterAll(closeConnection);

Create an SDK client for each user. We provide the defaultRole (user), a username and a userId all client requests are scoped to the passed in options.

  describe("user: Franz + Herbert", () => {
    it("should only see his todos", async () => {
      const franzClient = client({defaultRole:'user', username:'franz', userId:'1'});
      const herbertClient = client({defaultRole:'user', username:'herbert', userId:'2'});

Insert two todos into the database for user Franz

const franzTodo1 = await franzClient.AddTodo({
    description: "Franz's first todo item",
    is_done: false,
});
const franzTodo2 = await franzClient.AddTodo({
    description: "Franz's second todo item",
    is_done: false,
});

Insert one todo for user Herbert

const herbertTodo1 = await herbertClient.AddTodo({
    description: "Herbert's first todo item",
    is_done: false,
});

Now we have three todos in the database two for Franz and one for Herbert. We retrieve the todos for each user and assert that the user only sees his own todo items.

      // get Franz's todos
      const franzsTodos = await franzClient.GetTodos();

      // Franz should only see his todos
      expect(franzsTodos.todo.map(todo => todo.id).sort())
        .toEqual([
          franzTodo1.insert_todo?.returning[0].id,
          franzTodo2.insert_todo?.returning[0].id]);

      // get Herbert's todos
      const herbertsTodos = await herbertClient.GetTodos();

      // Herbert should only see his todos
      expect(herbertsTodos.todo.map(todo => todo.id).sort())
        .toEqual([herbertTodo1.insert_todo?.returning[0].id]);
    });
  });
});

Conclusion

It is really easy to setup a Hasura API but with this ease we often forget that business logic should be well tested. As soon as the test setup is done it is rather easy to write tests against the API. TypeScript and the tests help to see any breaking API changes that would let your application fail in production.

Notes

Due to the current setup it is not possible to run tests in parallel. The API tests provide no means to isolate a test in a transaction. Keep this in mind as it will increase the time of your test runs.

This is all just a starting point.

Develop Electron in Docker

Thomas Peklak — Wed, 25 Aug 2021 14:30:10 +0000

Why

There are several reasons to develop in Docker and not on your host machine. First, when it comes to backend services, you can guarantee that your development runtime is the same as in production, which can eliminate some scenarios where inconsistencies can lead to problems in production.

Of course, this doesn’t really apply to Electron because their apps are bundled up and shipped to your users — here you don’t have any control over the environment. Even so, you can have build dependencies where you want to have either an easier setup for the whole development team or you want to guarantee that every developer has the same system dependencies as your build servers installed.

My case was different: my colleague had to introduce a new dependency with a native module. It worked well on his machine, but created a segfault on mine. I’m not familiar with debugging segfaults and getting my development setup up and running again was urgent. Before I turned to Docker I tried different versions of Electron and the library but always ended up with the same result: it worked on other machines but not on mine. The library even worked well using the corresponding NodeJS version there only seemed to be a problem with Electron.

As I thought that this was just a temporary issue and would be fixed in future versions of the library or Electron, I was happy to have a temporary solution.

How

Based on this directory structure we can build a Docker image from a Dockerfile which installs all node modules, performs an electron rebuild, and does some other black magic.

Directory Structure

package.json
package-lock.json
Dockerfile
src
- main.js
- index.html

It’s important that your files are not located in the root folder because we want to mount the source directory into the container, so we can continuously work without rebuilding the image. We only need to rebuild the image if there is a change in the npm dependencies.

# use the version that corresponds to your electron version
FROM node:14.16

# install electron dependencies or more if your library has other dependencies
RUN apt-get update && apt-get install \
    git libx11-xcb1 libxcb-dri3-0 libxtst6 libnss3 libatk-bridge2.0-0 libgtk-3-0 libxss1 libasound2 \
    -yq --no-install-suggests --no-install-recommends \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

# copy the source into /app
WORKDIR /app
COPY . .
RUN chown -R node /app

# install node modules and perform an electron rebuild
USER node
RUN npm install
RUN npx electron-rebuild

# Electron needs root for sand boxing
# see https://github.com/electron/electron/issues/17972
USER root
RUN chown root /app/node_modules/electron/dist/chrome-sandbox
RUN chmod 4755 /app/node_modules/electron/dist/chrome-sandbox

# Electron doesn't like to run as root
USER node
CMD bash

Now, we can build the Docker image and start a container. If you have other files and folders in your root directory, you need to mount each single one separately. You can’t mount the root directory as this will also overwrite the node modules.

docker build -t electron-wrapper .
docker run -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY -v`pwd`/src:/app/src --rm -it electron-wrapper bash

This should fire up a bash prompt from which you can start your development workflow, e.g. npm start.

Example `package.json`

{
    "name": "electron-in-docker",
    "version": "1.0.0",
    "description": "",
    "main": "src/main.js",
    "scripts": {
        "start": "electron . --no-sandbox"
    },
    "author": "",
    "license": "ISC",
    "devDependencies": {
        "electron": "^13.1.7",
        "electron-rebuild": "^2.3.5",
        "libxmljs": "^0.19.7"
    }
}

Conclusion

This guide works in Linux and likely in WSL2. For macOS, you can take a look at Jake Donham's blog post in the links below, which helped me a lot to get started. I always find it good to have some backup in my developer's toolbox if things break in unpredictable ways. Running programs in Docker is one of my all-time favorites.

Example repository

If you want to try it out yourself, you can take a look at the electron in docker repository.

DEV Community: TRIGO | We speak human and computer

How to customize Keycloak themes

What is Keycloak?

Setting up a development environment

Theme types

Structure of a theme folder

Structure of a theme type folder

All your base belongs to me. Theme Inheritance explained

Theme type entry point: theme.properties

FTL - Faster than light or Freemarker

Data Models for your templates

For Theme Type: Login

For Theme Type: Account

What other tech is included?

How to customize a theme type?

Login theme type most relevant templates

Back to customizing the login theme type

CSS Classes confusion

Included Messages for i18n

Some notes on security

Sanitizing all user-generated content

CSRF Protection

Bring your own stuff

Recap

How to test a Hasura Api with Jest

Use Case

Tools

Hasura and PostgreSQL Setup with Docker Compose

Setup Database and Permissions

Permissions

Tests

Code Generation

Authenticated Requests

Testing Todo Permissions

Conclusion

Notes

Develop Electron in Docker

Why

How

Example package.json

Conclusion

Further reading

Example repository

Example `package.json`