DEV Community: Ahmed Atalla

Dokku the heroku alternative for solo developers

Ahmed Atalla — Sun, 04 Sep 2022 07:28:01 +0000

Heroku and free plan

In a blog post published at August 25, 2022 , Heroku general manager stated that they will stop offering free dynos dyno is heroku computing unit starting November, 28 2022, check the blog post and Remove free products plan

This decision will affect solo developers who use heroku to te st their ideas or host projects at early stage, and regarding to how easy it is to use heroku now we need an alternative

Dokku

what is dokku ?

An open source PAAS alternative to Heroku.
Dokku helps you build and manage the lifecycle of applications from building to scaling.

Dokku is an extensible, open source Platform as a Service that runs on a single server of your choice. Dokku supports building apps on the fly from a git push via either Dockerfile or by auto-detecting the language with Buildpacks, and then starts containers based on your built image. Using technologies such as nginx and cron, Web processes are automatically routed to, while background processes and automated cron tasks are also managed by Dokku.

Getting started

Minimum requirement to run dokku are:

A fresh installation of Ubuntu 18.04/20.04/22.04 or Debian 10+ x64.
At least 1 GB of system memory.
Attaching at least one domain name to your server ip, say example.com.

Installation

First ssh into your remote server.
Download the bootstrap.sh installation script

  wget https://raw.githubusercontent.com/dokku/dokku/v0.28.1/bootstrap.sh

Run the installer script by prefixing with DOKKU_TaG=xxx env variable to specify which version you want, latest is better offcourse

 sudo DOKKU_TAG=v0.28.1 bash bootstrap.sh

This command will automatically use apt to update and install dependecies such as docker, then it will created the required containers, also a new user dokku will be created
Next step is to add your public ssh key to be able to run dokku commands remotly, because dokku doesn't have a cli to install on your local machine like heroku toolbel

To add your key, get the content from your local machine, the key filename usually called id_rsa.pub

cat ~/.ssh/id_rsa.pub

copy the file content and then on the remote server run this last command

echo "your-public-key-contents-here" | dokku ssh-keys:add admin

once this is done, you can execute dokku commands remotly from your locall machine like this

ssh dokku@example.com apps:List
ssh dokku@example.com domains:report --global

Now we need set the domain as a dokku global domain.

ssh dokku@example.com domains:add-global example.com


# check your setup
ssh dokku@example.com domains:report --global

=====> Global domains information
       Domains global enabled:        true
       Domains global vhosts:         example.com

with this done, any app you deploy will be available at app-name.example.com by default unless you add another domain specific to the app

now you can create a new empty app like this

# From remote server shell
dokku apps:create my-first-application

# From your local machine
ssh dokku@<domain> apps:create my-second-app

In the next article i will show you how to deploy a NextJS application to your server

Build saleor dashboard docker image that accept environment variables

Ahmed Atalla — Mon, 25 Apr 2022 23:22:00 +0000

This hack is no longer needed as it is implemented in the official docker images, in this PR

Saleor as mentioned in its landing page is

An open-source, GraphQL-first e-commerce platform delivering ultra-fast, dynamic and personalized shopping experiences.

Saleor is built as separate components

saleor-core which is the graphql api
saleor-dashboard which is the amdin area for the app
saleor-storefront which is the user facing part of the ecommerce platform

Usually, we as developers use the first 2 components as provided by the saleor team and build a custom storefront on top of it

The problem

The saleor-dashboard is a react app that is build as a static site in a docker container but to do that we have to provide the API_URI at the build time
so for example if you have 4 environment development, stagging, test and production then you will need to build 4 different versions of the dashboard

i looked a round to see if someone else asked the same question and i found this issue #1592

My solution

The only answer on the above mentioned issue suggested that modifying the config.ts and index.html file would do the trick, so i will explain how you can do it manually, then feel free to automate the process

Get the dashboard code

clone the repo and checkout the version you need to build

git clone --depth 1 --branch <ref>  https://github.com/saleor/saleor.git

Config file

we will create a bash script env.sh that read the $API_URI env variable and generate a config javascript file, this script will run every time before the docker container started

notice that the docker container will serve the dashboard from a folder called dashboard that is why the script will generate the env file in the same folder

#!/bin/bash
target_file=./dashboard/env-config.js

touch $target_file
rm -rf $target_file

echo "window._env_ = {" >> $target_file
  echo "  API_URI: \"$API_URI\"," >> $target_file
echo "}" >> $target_file

The generated file should look like this

window._env_ = {
    API_URI: "<api-url-from-env>"
}

Modify `src/index.html`

Edit the main html file of the dashboard and add this script tag on the head

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">
    <meta name="robots" content="noindex">
    <title>Saleor e-commerce</title>
    <script src="/dashboard/env-config.js"></script>  <!-- add this line-->
  </head>

  <body>
    <div id="dashboard-app"></div>
  </body>
</html>

Modify `src/config.ts`

now we will read the API_URI from the window object at the runtime instead of reading it from environment at build time

import packageInfo from "../package.json";
import { SearchVariables } from "./hooks/makeSearch";
import { ListSettings, ListViews, Pagination } from "./types";

export const APP_MOUNT_URI = process.env.APP_MOUNT_URI || "/";
export const APP_DEFAULT_URI = "/";
// remove this line
export const API_URI = process.env.API_URI;

// add these 2 lines, typescript build would fail without the @ts-ignore
// @ts-ignore
export const API_URI = window._env_.API_URI;
....
....

Modify `Dockerfile`

for the docker file we need to do 2 things

copy the env.sh script into the docker image root
change the command to run the env.sh before starting the container

FROM node:14 as builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
ARG APP_MOUNT_URI
ARG API_URI
ARG STATIC_URL
ENV API_URI ${API_URI:-http://localhost:8000/graphql/}
ENV APP_MOUNT_URI ${APP_MOUNT_URI:-/dashboard/}
ENV STATIC_URL ${STATIC_URL:-/dashboard/}
RUN STATIC_URL=${STATIC_URL} API_URI=${API_URI} APP_MOUNT_URI=${APP_MOUNT_URI} npm run build

FROM nginx:stable
WORKDIR /app
COPY ./nginx/default.conf /etc/nginx/conf.d/default.conf
COPY --from=builder /app/build/ /app/
# Add the following lines
COPY ./env.sh .
RUN chmod +x env.sh
CMD ["/bin/bash", "-c", "/app/env.sh && nginx -g \"daemon off;\""]

No you can build saleor-dashboard image that take the API_URI from your deployment environment

Note

For me to not repeat the above steps with every new version of the dashboard, i created a gitlab CI/CD pipeline to do this automatically for whatever version/tag/ref i specify but unfortunately this is something i can't share

Getting started with ReScript and parcel

Ahmed Atalla — Fri, 30 Apr 2021 22:14:40 +0000

What is ReScript ?

as mentioned on the website,

The JavaScript-like language you have been waiting for,
Previously known as BuckleScript and Reason

History & Summary

OCaml is a typed FP language compiling to bytecode and native code.

Js_of_ocaml is based on OCaml and compiles to JavaScript for OCaml users.

BuckleScript is a fork of OCaml that also outputs JavaScript, optimized (features, JS interoperability, output, build tools) for JS developers rather than OCaml developers.

Reason is an alternative, JS-looking syntax layer over OCaml, plus extra tools. Reason used 1. BuckleScript to produce JavaScript output and 2. OCaml to produce native output. Most of the community focused on the former usage. Reason and BuckleScript shared most teammates, who wanted to double down on the JS use-case.

ReScript, thus born, is the new branding for BuckleScript that reimplements or cleans up Reason's syntax, tools, ecosystem & docs into a vertically integrated experience. Reason project will continue serving its purpose of a syntax layer for native OCaml. Some folks might use Reason with Js_of_ocaml to output JS code.

There is only one official template to create a new ReScript app ReScript docs

git clone https://github.com/rescript-lang/rescript-project-template my-app
cd my-app
npm install
npm start
node src/Demo.bs.js

npm start script will run bsb -make-world -w to compile the .res code into .bs.js code

as you can see the source code has only a console log statement so we need to add @rescript/react and convert that to a single-page web app, cd into my-app directory and install the other dependencies
also will use parcel bundler to transpile and bundle our front-end code and run the development server

npm install react react-dom  @rescript/react --save
npm install parcel concurrently --save-dev

concurrently will be used to run 2 commands in parallel from npm scripts

The next step is to edit the bucklescript config file bsconfig.json

{
  ...
  "reason": { "react-jsx": 3 },
  "bs-dependencies": ["@rescript/react"],
  "package-specs": {
    ...
    "in-source": false
  },
  ...
}

in-source config is optional, I like to keep the compiled .bs.js files outside the src especially in a new project that is started as ReScript projects, if you set this to false the compiled files will be at ./lib/js/src, if it is true the compiled file will be in the same place as its .res source

next, create a public/index.html and public/global.css directory with the content

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="./global.css">
    <title>Hello ReScript</title>
</head>
<body>
    <div id="app-root"></div>
    <script src="../lib/js/src/App.bs.js"></script>
</body>
</html>

then will add an npm script to start the bucklescript compiler command and the parcel dev server

    "dev": "concurrently \"parcel ./public/index.html\" \"bsb -make-world -w\" ",

finally rename src/Demo.res to src/App.res with this basic ReScript code

module App = {
  @react.component
  let make = () => {
    <div> <p> {React.string("Hello World 123")} </p> </div>
  }
}

switch ReactDOM.querySelector("#app-root") {
  | Some(root) => ReactDOM.render(<App />, root)
  | None => ()
}

this will create a React component App and render it at the div with id app-root

now let us start the dev server and check the result at http://127.0.0.1:1234

npm run dev

Django Rest Framework custom JWT authentication

Ahmed Atalla — Tue, 12 May 2020 15:27:00 +0000

This article is not a tutorial or a guide, it is more like a request for code review and validate the implementation from more experienced Django developers, so please don't use this code unless you are able to review and validate yourself

Introduction

Web application security is critical and doing it on your own in production is a huge responsibility, that is why I love Django because it takes care of most of the security vulnerabilities out there, but my problem shows up when I wanted to build my back-end as a restful API so I can connect all type of clients (SPA, mobile, desktop, ... etc)
Django Rest Framework (DRF) comes with different builtin authentication classes, token authentication or JWT are the way to go for my use case but I still have that worry of how to save the tokens in client-side
everybody says don't save the token in localstorage because of XSS attacks and better to save your token in httponly cookie, but cookies are open to CSRF attack too and DRF disable CSRF protection for all the APIView so what is the best practice to do this.
for a while I kept using it as everybody especially in mobile (i do react-native) we have secure storages and also if the device is not (rooted android or jailbroken ios) then each app is sandboxed and the tokens are safe in most cases
The problem still exists in web clients (SPAs), so I came into an implementation that might be useful and I wanted to document it here so I get feedback from more experienced developers, I can summarize my implementation into the following steps:

the user sends a POST request with username and password to log in, then the server will do 3 things
- generate an access_token which is a short life jwt (maybe 5 mins) and send it in the response body
- generate a refresh_token which is a long life jwt (days) and send it in an httponly cookie, so it won't be accessible from the client javascript
- send a normal cookie that contains a CSRF token
The developer needs to be sure that all unsafe views (POST, UPDATE, PUT, Delete) are protected by the builtin Django CSRF protection because as I mentioned above DRF disables them by default.
in the client-side the developer should take care of:
- In the client-side, every request will contain refresh token in the cookies automatically (be sure that your client domain is whitelisted in the server cors headers settings)
- Send the access_token in the Authorization header.
- Send the CSRF token in the X-CSRFTOKEN header if he is doing POST request
- when he needs a new access_token, he need to send a POST request to refresh token endpoint

enough talking, let us see some code

Project Setup

python3 -m venv .venv
source .venv/bin/activate
pip install django django-cors-headers djangorestframework PyJWT

# create Django project with the venv activates
django-admin startproject project

# create an app 
./manage.py start app accounts

in the project settings enable the apps and add some settings

INSTALLED_APPS = [
    ...
    # 3rd party apps
    'corsheaders',
    'rest_framework',

    # project apps
    'accounts',
]

CORS_ALLOW_CREDENTIALS = True # to accept cookies via ajax request
CORS_ORIGIN_WHITELIST = [
    'http://localhost:3000' # the domain for front-end app(you can add more than 1) 
]

REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated', # make all endpoints private
    )
}

before applying the first migration and as recommended in the official Django docs I like to start my project with a custom user model even if I won't use it now
in accounts.models define the user model

from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    pass

in the project.settings.py define the user model

...
AUTH_USER_MODEL = 'accounts.User'
...

later you can refer to the user model by one of the following

from django.conf import settings
User = settings.AUTH_USER_MODEL

# OR

from django.contrib.auth import get_user_model
User = get_user_model()

and in accounts.admin register the new user model to the admin site

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from accounts.models import User

admin.site.register(User, UserAdmin)

create a super user

./manage.py createsuperuser

and finally, an endpoint to test, as we declare in the above settings all the endpoint will require authentication by default, we can override this in certain views as we will going to do in the login later

we will create the user profile endpoint that will return current authenticated user object as JSON, for that we will need to create a user serializer

# accounts.serializers
from rest_framework import serializers
from accounts.models import User


class UserSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = ['id', 'username', 'email',
                  'first_name', 'last_name', 'is_active']

# project.urls
from accounts import urls as accounts_urls

urlpatterns = [
    path('accounts/', include(accounts_urls)),
]

# accounts.urls
urlpatterns = [
    path('profile', profile, name='profile'),
]

# accounts.views
from rest_framework.decorators import api_view
from rest_framework.response import Response
from .serializers import UserSerializer


@api_view(['GET'])
def profile(request):
    user = request.user
    serialized_user = UserSerializer(user).data
    return Response({'user': serialized_user })

now if you tried to acceess this endpoint you will get 403 error, as described in the introduction we need to login then send the access_token in the request header

Login View

The login endpoint will be a post request with username and password in the request body.
we will make the login view public using the permission class decorator AllowAny, also we will decorate the view with @ensure_csrf_cookie forcing Django to send the CSRF cookie in the response if the login success

if the login success, we will have:

an access_token in the response body.
a refreshtoken in an httponly cookie.
a csrftoken in a normal cookie so we can read it from javascript and resend it when needed

# accounts.views
from django.contrib.auth import get_user_model
from rest_framework.response import Response
from rest_framework import exceptions
from rest_framework.permissions import AllowAny
from rest_framework.decorators import api_view, permission_classes
from django.views.decorators.csrf import ensure_csrf_cookie
from accounts.serializers import UserSerializer
from accounts.utils import generate_access_token, generate_refresh_token


@api_view(['POST'])
@permission_classes([AllowAny])
@ensure_csrf_cookie
def login_view(request):
    User = get_user_model()
    username = request.data.get('username')
    password = request.data.get('password')
    response = Response()
    if (username is None) or (password is None):
        raise exceptions.AuthenticationFailed(
            'username and password required')

    user = User.objects.filter(username=username).first()
    if(user is None):
        raise exceptions.AuthenticationFailed('user not found')
    if (not user.check_password(password)):
        raise exceptions.AuthenticationFailed('wrong password')

    serialized_user = UserSerializer(user).data

    access_token = generate_access_token(user)
    refresh_token = generate_refresh_token(user)

    response.set_cookie(key='refreshtoken', value=refresh_token, httponly=True)
    response.data = {
        'access_token': access_token,
        'user': serialized_user,
    }

    return response

and here are the functions that generate the tokens, notice that I use a different secret to sign refresh token for more security

# accounts.utils
import datetime
import jwt
from django.conf import settings


def generate_access_token(user):

    access_token_payload = {
        'user_id': user.id,
        'exp': datetime.datetime.utcnow() + datetime.timedelta(days=0, minutes=5),
        'iat': datetime.datetime.utcnow(),
    }
    access_token = jwt.encode(access_token_payload,
                              settings.SECRET_KEY, algorithm='HS256').decode('utf-8')
    return access_token


def generate_refresh_token(user):
    refresh_token_payload = {
        'user_id': user.id,
        'exp': datetime.datetime.utcnow() + datetime.timedelta(days=7),
        'iat': datetime.datetime.utcnow()
    }
    refresh_token = jwt.encode(
        refresh_token_payload, settings.REFRESH_TOKEN_SECRET, algorithm='HS256').decode('utf-8')

    return refresh_token

Custom Authentication Class for DRF

Django Rest Framework makes it easy to create a custom authentication scheme, it described in details in the official docs
The following code is originally taken from DRF source code then I add my changes as required.
notice that DRF enforce CSRF only in the session authentication rest_framework/authentication.py

# accounts.authentication

import jwt
from rest_framework.authentication import BaseAuthentication
from django.middleware.csrf import CsrfViewMiddleware
from rest_framework import exceptions
from django.conf import settings
from django.contrib.auth import get_user_model


class CSRFCheck(CsrfViewMiddleware):
    def _reject(self, request, reason):
        # Return the failure reason instead of an HttpResponse
        return reason


class SafeJWTAuthentication(BaseAuthentication):
    '''
        custom authentication class for DRF and JWT
        https://github.com/encode/django-rest-framework/blob/master/rest_framework/authentication.py
    '''

    def authenticate(self, request):

        User = get_user_model()
        authorization_heaader = request.headers.get('Authorization')

        if not authorization_heaader:
            return None
        try:
            # header = 'Token xxxxxxxxxxxxxxxxxxxxxxxx'
            access_token = authorization_heaader.split(' ')[1]
            payload = jwt.decode(
                access_token, settings.SECRET_KEY, algorithms=['HS256'])

        except jwt.ExpiredSignatureError:
            raise exceptions.AuthenticationFailed('access_token expired')
        except IndexError:
            raise exceptions.AuthenticationFailed('Token prefix missing')

        user = User.objects.filter(id=payload['user_id']).first()
        if user is None:
            raise exceptions.AuthenticationFailed('User not found')

        if not user.is_active:
            raise exceptions.AuthenticationFailed('user is inactive')

        self.enforce_csrf(request)
        return (user, None)

    def enforce_csrf(self, request):
        """
        Enforce CSRF validation
        """
        check = CSRFCheck()
        # populates request.META['CSRF_COOKIE'], which is used in process_view()
        check.process_request(request)
        reason = check.process_view(request, None, (), {})
        print(reason)
        if reason:
            # CSRF failed, bail with explicit error message
            raise exceptions.PermissionDenied('CSRF Failed: %s' % reason)

once you create that class, go to the project.settings and activate it in the REST_FRAMEWORK section like this appname.filename.classname


REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'accounts.authentication.SafeJWTAuthentication',
    ),
    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated',
    )
}

Now as we have access_token and set the authentication method we can revisit the profile endpoint but this time we will set the Authorization header

Refresh Token View

Whenever the token is expired or you need a new token for any reason we need a refresh_token endpoint.
this view needs the permission of AlloAny because we don't have an access_token but it will be protected by 2 other things

a valid refresh_token that sent in the httoponly cookie.
the CSRF token so we are sure the above cookie not compromised if the 2 conditions are satisfied then the server will generate a new valid access_token and send it back.

if the refresh_token is invalid or expired, the user will need to re-logion

import jwt
from django.conf import settings
from django.contrib.auth import get_user_model
from django.views.decorators.csrf import csrf_protect
from rest_framework import exceptions
from rest_framework.response import Response
from rest_framework.permissions import AllowAny
from rest_framework.decorators import api_view, permission_classes
from accounts.utils import generate_access_token


@api_view(['POST'])
@permission_classes([AllowAny])
@csrf_protect
def refresh_token_view(request):
    '''
    To obtain a new access_token this view expects 2 important things:
        1. a cookie that contains a valid refresh_token
        2. a header 'X-CSRFTOKEN' with a valid csrf token, client app can get it from cookies "csrftoken"
    '''
    User = get_user_model()
    refresh_token = request.COOKIES.get('refreshtoken')
    if refresh_token is None:
        raise exceptions.AuthenticationFailed(
            'Authentication credentials were not provided.')
    try:
        payload = jwt.decode(
            refresh_token, settings.REFRESH_TOKEN_SECRET, algorithms=['HS256'])
    except jwt.ExpiredSignatureError:
        raise exceptions.AuthenticationFailed(
            'expired refresh token, please login again.')

    user = User.objects.filter(id=payload.get('user_id')).first()
    if user is None:
        raise exceptions.AuthenticationFailed('User not found')

    if not user.is_active:
        raise exceptions.AuthenticationFailed('user is inactive')


    access_token = generate_access_token(user)
    return Response({'access_token': access_token})

Token Revoke

The last piece of the puzzle is a way to revoke the refresh token which has a long lifetime, you might blacklist the token or assign a uuid for the token and put it in the payload then link it to the user and save it in the database, when revoking or logout you just change that uuid in the database to not match the value in the payload, you can pick what suits your application need