Appinio

appinio

What's wrong with stickers in Telegram? Deanonymize anonymous channels in two clicks

Many of us use Kafka to publish messages, but how do we receive them? In this article, we will write a small application for consuming messages from Kafka. And, of course, e2e tests. Let's First Understand How Kafka Works and What It Is. Kafka is a message broker in which some services generate messages and others receive them. Brokers are primarily used in systems with a microservice architecture to pass messages between services. Messages are stored in topics. When sending a message, the producer indicates the name of the topic, as well as the message itself, which consists of a key and a value. And that’s it; the producer’s work is finished. Then consumers come into play, they subscribe to the desired topic, and start reading messages. Each application has its own queue, reading from which the consumer moves the offset pointer. The distinctive features of Kafka are: Guarantee that all messages will be ordered exactly in the sequence in which they arrived in the topic Kafka stores read messages for a while High throughput Now, let's work with Kafka using the NestJs framework. First, we need to create a controller that will process messages. @Controller()
export class AppController{

    constructor(
        private readonly appService: AppService,
    ) {
    }

    @EventPattern(config.get('kafka.topics.exampleTopic'), Transport.KAFKA)
    handleEvent(
        @Payload() payload: ExamplePayloadDto,
    ): Promise<void> {
        return this.appService.handleExampleEvent(payload.message);
    }
} Pay attention to the attribute, which indicates that our function will receive messages from the topic specified in the configuration file . The attribute helps to get the value from the topic message. @EventPattern handleEvent() config.get('kafka.topics.exampleTopic') @Payload() To connect your application to Kafka brokers, you need to do two things. To begin, connect the microservice in the startup file: app.connectMicroservice({
        transport: Transport.KAFKA,
        options: {
            client: {
                clientId: config.get('kafka.clientId'),
                brokers: config.get('kafka.brokers'),
                retry: {
                    retries: config.get('kafka.retryCount'),
                },
            },
            consumer: {
                groupId: config.get('kafka.consumer.groupId'),
            },
        },
    }); And then run the microservices in the main.ts: async function bootstrap() {
    const app = await NestFactory.create(AppModule, {
        bufferLogs: true,
    });
    appStartup(app);

    await app.startAllMicroservices();
    await app.listen(config.get('app.port'));
};

void bootstrap(); To test the application, I use the @testcontainers/kafka package. With the help of this, I created a zooKeeper container, and then a Kafka container: export async function kafkaSetup(): Promise<StartedTestContainer[]> {
    const network = await new Network().start();

    const zooKeeperHost = "zookeeper";
    const zooKeeperPort = 2181;
    const zookeeperContainer = await new GenericContainer("confluentinc/cp-zookeeper:7.3.2")
        .withNetwork(network)
        .withNetworkAliases(zooKeeperHost)
        .withEnvironment({ ZOOKEEPER_CLIENT_PORT: zooKeeperPort.toString() })
        .withExposedPorts(zooKeeperPort)
        .start();

    const kafkaPort = 9093;
    const kafkaContainer = await new KafkaContainer()
        .withNetwork(network)
        .withZooKeeper(zooKeeperHost, zooKeeperPort)
        .withExposedPorts(kafkaPort)
        .start();

    const externalPort = kafkaContainer.getMappedPort(kafkaPort);

    config.set('kafka.brokers', [`localhost:${externalPort}`]);

    return [
        zookeeperContainer,
        kafkaContainer,
    ];
} Please note that, in this file, I have overridden the broker address to the newly created container. In the test file itself, in the function, I create a Kafka client. With the producer, I also create a topic and launch our application. beforeAll beforeAll(async () => {
        kafkaContainers = await kafkaSetup();

        kafka = new Kafka({
            clientId: 'mock',
            brokers: config.get('kafka.brokers'),
            logLevel: logLevel.NOTHING,
        });
        producer = kafka.producer();
        await producer.connect();

        const admin = kafka.admin();
        await admin.connect();
        await admin.createTopics({
            topics: [{ topic: config.get('kafka.topics.exampleTopic') }],
        });

        appService = mockDeep<AppService>();

        const module: TestingModule = await Test.createTestingModule({
            imports: [AppModule],
        })
            .overrideProvider(AppService)
            .useValue(appService)
            .compile();

        app = module.createNestApplication();
        appStartup(app);
        await app.startAllMicroservices();

        await app.init();

    }, 30 * 1000); Of course, in the function, you need to stop the containers: afterAll afterAll(async () => {
        await app.close();
        await Promise.all(kafkaContainers.map(c => c.stop()));
    }, 15 * 1000); I wrote a test that verifies that when a message arrives in a topic, our handler function from the controller calls the necessary service function. To do this, I override the implementation of the function and wait for it to be called. handleExampleEvent describe('handleEvent', () => {
        it('should call appService', async () => {
            let resolve: (value: unknown) => void;
            const promise = new Promise((res) => {
                resolve = res;
            });
            appService.handleExampleEvent.mockImplementation(async () => {
                resolve(0);
            });

            const event: ExamplePayloadDto = {
                message: 'Hello World!',
            };

            await producer.send({
                topic: config.get('kafka.topics.exampleTopic'),
                messages: [{
                    key: 'key',
                    value: JSON.stringify(event),
                }]
            });

            await promise;

            await kafka.producer().disconnect();
        });
    }); That's all. Working with Kafka is incredibly easy if you use the NestJs framework. I hope my experience will be useful to you. An example application can be seen at https://github.com/waksund/kafka

How to Consume Kafka Messages With NestJS

NestJS এর সাথে কাফকা বার্তাগুলি কীভাবে গ্রহণ করবেন

So konsumieren Sie Kafka-Nachrichten mit NestJS

Cómo consumir mensajes de Kafka con NestJS

Comment consommer des messages Kafka avec NestJS

NestJS के साथ काफ्का संदेशों का उपभोग कैसे करें

NestJS を使用して Kafka メッセージを使用する方法

NestJS로 Kafka 메시지를 사용하는 방법

Como consumir mensagens Kafka com NestJS

Как использовать сообщения Kafka с помощью NestJS

NestJS ile Kafka Mesajları Nasıl Kullanılır?

Cách sử dụng tin nhắn Kafka với NestJS

如何使用 NestJS 消费 Kafka 消息

Serverless NestJS Automation on AWS Lambda

Here is a quick guide on how to Install Gitea with on Debian 11 Postgresql Start with a quick system update: sudo apt-get update -y
sudo apt-get upgrade -y Setup postgresql sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

# Import repo signing key with:
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

sudo apt-get update
sudo apt-get -y install postgresql System setup sudo systemctl start postgresql
sudo systemctl enable postgresql
sudo systemctl status postgresql Next, You need to switch to ’SCRAM-SHA-256’ scheme from md5 encryption scheme for better security. If you want to connect to PostgreSQL remotely, then you need to allow your IP address in the PostgreSQL configuration file. Open the configuration file to make changes using the following command: sudo vim /etc/postgresql/15/main/postgresql.conf

# Inside file uncomment:

listen_addresses = 'localhost, 45.32.225.46'
password_encryption = scram-sha-256 Then, restart the systemd service: sudo systemctl restart postgresql Login into postgresql sudo -u postgres psql Inside psql: postgres=# CREATE ROLE gitea WITH LOGIN PASSWORD 'secure@123';

postgres=# CREATE DATABASE giteadb;

postgres=# GRANT ALL PRIVILEGES ON DATABASE giteadb TO gitea;

postgres=# exit if you receive the error: The database settings are invalid: migrate: sync: pq: permission denied for schema public you might have to do the following in psql after the install is complete, I did: ALTER DATABASE gitea OWNER TO gitea Within /etc/postgresql/15/main/pghba.conf file: host    giteadb        gitea            134.122.38.0/32           scram-sha-256 Install and configure git: sudo apt install git
git --version

git config --global user.name "Your Name"
git config --global user.email "youremail@domain.com”
git config --list Create git user for gitea sudo adduser \
   --system \
   --shell /bin/bash \
   --gecos 'Git Version Control' \
   --group \
   --disabled-password \
   --home /home/git \
   git Install gitea: wget https://dl.gitea.com/gitea/1.20.3/gitea-1.20.3-linux-amd64 -O /usr/local/bin/gitea
sudo chmod +x /usr/local/bin/gitea Make directory structure for gitea: sudo mkdir -p /etc/gitea

sudo mkdir -p /var/lib/gitea/{custom,data,indexers,public,log}

sudo chown -R git:git /var/lib/gitea/

sudo chown root:git /etc/gitea

sudo chmod -R 750 /var/lib/gitea/

sudo chmod 770 /etc/gitea Create systemd service file: sudo vim /etc/systemd/system/gitea.service Inside: [Unit]
Description=Gitea
After=syslog.target
After=network.target
After=postgresql.service

[Service]
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl start gitea
sudo systemctl enable gitea
sudo systemctl status gitea

# Verify running on port 3000:
netstat -tulpan | grep 3000 Navigate to port 3000 on your server and you will see it running! Congrats, you have now dropped GitHub as your Git server. Also published here.

Step-by-Step Guide for Installing Gitea on Debian 11

Hi everyone! Today, I would like to highlight a really interesting topic: how to implement an additional authentication layer over a service that does not offer it out of the box. Namely, how to add Azure AD Authentication on your side over a service-side JWT token authentication. It’s a good exercise in case your third-party service does not support SSO authentication (or you just don’t want to pay much for it) - but you would be happy with a simple solution. All you need is , Docker, and, surely, an understanding of what you are going to do. Don’t use this solution in production as it is :) Python Let’s start! Prerequisites Before coding and deployment, let’s make sure we have everything we may need. Third-party service to authenticate into I assume that a destination service is able to do the following: Generate a JWT secret to create JWT tokens; Validate incoming requests with JWT tokens - and grant access in case the JWT token is valid; If a JWT token is missing/invalid, redirect a user via a pre-defined fallback URL. In my case, the as a part of the URL to the content: . So I simply had to build a redirect URL with a JWT token after all operations on my side. Also, JWT tokens can be passed in different ways, but anyway, it’s not rocket science to figure out how to include them in your resulting request. service required a JWT token https://dest-url.com/content/?jwt_token=<token> Azure To provide authentication, . To control the authentication flow on your side, you will need the following details: create a fresh application in your Azure organization Application ID (in other words, Client ID); Application secret; Directory (tenant) ID; List of application scopes (as a rule, permission will be enough); Read Redirect URI. The first four parameters will be generated when you create your application. As for the redirect URI, you have to provide it in advance: it will be the address of your Python service generating the authorization key for Azure. Python service We are going to connect JWT and AD authentication via a dockerized Python application deployed on our side. It will be and the Microsoft Authentication Library for Python (MSAL). Below, you will find a list of vital Python libraries you will need: based on Flask : overall application architecture and endpoint design; flask : authentication workflow; msal : generating JWT tokens based on third-party service JWT secrets; jwt : additional encryption of a user-side session cookie. fernet Moreover, it would be really useful to get acquainted with the . official Microsoft documentation , you will find a complete and more complicated example of a Flask-based application. Here Authentication Workflow The overall authentication workflow looks as follows: The user goes to our . If they try to access the destination service directly, it will also redirect them for authentication via this fallback URL. https://python-authentication-service.com/ The authentication service initiates the AD authentication flow and invites the user to enter their credentials in the standard Microsoft authentication window. After successful login, the service acquires the authorization code. The authentication flow creates a corresponding JSON object containing the authorization code acquired. The authentication service encrypts this object and saves it on the user side as a session cookie. The authentication service decrypts the flow in the cookie and queries the AD application with the authorization code to generate an AD authentication token. When the token is generated, the authentication service acquires the final authentication result. If authentication is successful, the authentication service generates the JWT token based on a destination service JWT secret and redirects the user to the destination content with this token included. If any of the tokens expire, the user will be redirected to either log in again or get a new destination service JWT token via the authentication service. It is not straightforward why we need session cookies and why we encrypt them in steps 3 and 4. It is required only in case you want to deploy your service in a replicated manner: due to MSAL library constraints, the authentication service initiates the authentication flow and generates the AD tokens on two different endpoints. If you replicate the authentication service, your replicas will not be aware of any authentication flow initiated on another replica - so you need to save the flow object somewhere. The easiest way to achieve this is to use the Flask library and save all the stuff on the user side. In this case, all replicas of the authentication service will retain access to this shared cookie. Flow encryption here is used only to provide an additional security layer: since it’s a user-side cookie, we can rely on lightweight encryption algorithms. session Alternatively, if you deploy the service in a singleton pattern, you would not need session cookies. Moreover, you can play hard and create shared session storage on the server side, e.g., with the or alternative solutions. use of Redis Implementation I guess we’ve covered all theoretical steps and are ready for fun! Now, let’s implement the service. Code First of all, let’s define the overall project structure - it’s simple: /src
├── application.py
└── config.py
Dockerfile
requirements.txt Basically, project requirements should include the following libraries: Flask>=2.3.2,<3
msal>=1.22.0,<2
requests>=2.31.0,<3
fernet>=1.0.1 In the configuration file, specify all required parameters - it’s still simple: MSAL_CLIENT_ID = #Your AD application (client) ID
MSAL_CLIENT_SECRET = #Your AD application secret
MSAL_AUTHORITY = #https://login.microsoftonline.com/your-tenant-id
AD_SCOPES = #List of scopes defined when creating the AD application (for testing purposes, can be empty: '[]')

AUTH_SERVICE_URL = #URL of this authentication service (e.g. https://python-authentication-service.com/ as above)

JWT_SECRET = #JWT secret generated by the destination service
JWT_EXPIRATION_SECONDS = #Desired TTL for the destination service JWT token

FLASK_SECRET = #Built-in Flask cookie secret key to encrypt the session cookie with
FERNET_SECRET = #Additional Fernet secret key to encrypt the flow object

TARGET_URL = #URL of the destination service to redirect into with the resulting JWT token (e.g. https://dest-url.com/content/ as above) You can store the configuration parameters as you wish. But since they are pretty sensitive, consider a secret manager to protect them. Now, all preliminary stuff is done, and we are good to go ahead with the main code. Let’s import all required libraries and declare the Flask application, MSAL, and Fernet objects in use: from flask import Flask, session, request, redirect
import msal
import jwt
from fernet import Fernet
import json
import time
import config

app = Flask(__name__)

msal_app = msal.ConfidentialClientApplication(
    client_id=config.MSAL_CLIENT_ID,
    authority=config.MSAL_AUTHORITY,
    client_credential=config.MSAL_CLIENT_SECRET,
)

fe = Fernet(bytes(config.FERNET_SECRET, encoding='utf8')) Since we are going to use the Flask library to store session cookies, we also have to define the cookie secret we added to the config before: session app.config.update(SECRET_KEY=config.FLASK_SECRET, ENV='development') As I’ve already mentioned before, the application should support two endpoints: - root endpoint to start the authentication flow and create the corresponding object with the authorization key. / - auxiliary authorization endpoint to validate authentication flow and create an AD authentication token. When done, this endpoint proceeds to the core stuff: generates the destination service JWT token, appends it to the destination URL, and redirects the user. /getadtoken That’s all we need here. First, let’s implement the root endpoint: @app.route('/')
def root():
    flow = msal_app.initiate_auth_code_flow(config.AD_SCOPES, redirect_uri=config.AUTH_SERVICE_URL + '/getadtoken')
    
    session['flow'] = fe.encrypt(json.dumps(flow).encode())

    return redirect(flow['auth_uri'], code=302) Here you can see that we create the object and add the encrypted inside. The session will be stored on the user side and shared between the application replicas, as I’ve mentioned before. session flow The object also contains the authentication URI on the Azure side to redirect the user for authentication. flow Proceeding to the endpoint: /getadtoken @app.route('/getadtoken')
def getadtoken():
    if 'flow' not in session:
        return 'Unauthorised', 403

    flow = json.loads(fe.decrypt(session['flow']).decode())
    
    saml_result = msal_app.acquire_token_by_auth_code_flow(flow, request.args)

    if not saml_result or 'error' in saml_result:
        return 'Unauthorised', 403

    jwt_token = jwt.encode({'data': 'empty', 'exp': int(time.time()) + config.JWT_EXPIRATION_SECONDS}, config.JWT_SECRET, algorithm='RS256') #NB: your encoding algorithm may differ.

    return redirect(config.TARGET_URL + '?jwt_token=' + jwt_token, code=302) Here, first of all, we have to check if the object is inside the Flask session to prevent direct access to the endpoint. In other words, if the user does not have any session cookie stored, they are unauthenticated and cannot proceed. flow /getadtoken Then, we decrypt the object and pass it to generate the AD authentication token. The authorization code contained in the flow is validated on the Azure side, so if there are any problems in the resulting object, the application returns . flow 403 If the authentication is successful, we finally proceed to the core stuff: generate the JWT token based on the destination service secret and let the user go ahead. Depending on your destination service, the JWT token may require any data inside, a particular expiration time to define, or a different encoding algorithm. That’s all, folks! You are breathtaking! Containerization Since our application is Flask-based, you can use official Python base images to create yours: FROM python:3.11.3-alpine

RUN apk update

WORKDIR /app

COPY requirements.txt ./

RUN pip install requirements.txt

COPY ./src .

CMD ["python", "./application.py"] As I mentioned before, you can deploy the resulting service in any manner you wish. What’s next? As you can see, I’ve described the simplest possible approach to on your side. It highlights the core principles and can be paired with many third-party services supporting JWT authentication. There are many ways to improve; let me show some to you: implement the Azure AD authentication Server-side session storage for better-replicated deployment; Caching and rotation for both tokens; User-side logout flow and endpoint. Thank you for reading! Hope you’ve enjoyed this article. Thank you in advance for your comments.

JWT and Azure AD Authentication: How to Marry Them?

Using SuperTokens in a VueJS App With Your Own UI

Uso de SuperTokens en una aplicación VueJS con su propia interfaz de usuario

Building your own auth service can be tedious, complex and time-consuming. To save time, developers often resort to using third party auth services for auth. This post will guide you on how to add authentication to a VueJS app with SuperTokens. What is SuperTokens? is an open source project which enables you to add auth to your app quickly. It gives you a pre-built auth UI and backend APIs for an end-to-end integration experience. SuperTokens Before we dive into the code, let’s discuss the overall architecture. Architecture SuperTokens is built out of three components: Frontend SDK Backend SDK Core microservice that talks to a database. We’ll use the SuperTokens frontend SDK in our Vue app to add all the auth forms (login, signup, reset password etc). You can also build your own UI using the helper functions from frontend SDKs, but we will focus on the pre-built UI in this blog. The pre-built UI are ReactJS components (provided by the ). In order to use them, we will have to render React components in our VueJS app. supertokens-auth-react library For the backend, we will use the NodeJS SDK provided by SuperTokens . This SDK exposes all of the auth APIs (like , / etc) via a middleware, for the frontend to call. When these APIs are called, the SDK will talk to the SuperTokens Core microservice to read and write information to the database. supertokens-node library /auth/signin auth/signout The SuperTokens core service can be either self-hosted (and connected to your own db), or be hosted by the team behind SuperTokens (sign up on ). supertokens.com In order to keep the app’s bundle size small, we will limit the use of the SDK to all of the auth related routes ( by default), and use a lighter weight, vanilla JS SDK ( ) for all other routes in our app. Finally, we will then use code splitting and lazy importing to make sure that the SDK is only bundled when visiting the routes. supertokens-auth-react /auth/* supertokens-web-js library supertokens-auth-react /auth/* Frontend Integration 1. Setup and Install Create a new Vue + Typescript app: npm init vue@latest In the prompt, select Typescript and Vue Router: Once that’s done, head inside the project and install the following dependencies: npm i --save cors express npm-run-all react supertokens-auth-react react-dom supertokens-node The library will be used on the frontend to render the login UI, and the library will be used on the backend to expose the auth API routes. supertokens-auth-react supertokens-node 2. Call the and function supertokens-auth-react supertokens-web-js init Start by create the component inside folder. This component will render the SuperTokens React component to handle authentication on the frontend: AuthView /src/views <script lang="ts">
    export default {
        // See next sections
    }
</script>

<template>
    <main>
        <div id="authId" />
    </main>
</template> Notice that we have made a element with the . This is where we will render the react components provided by SuperTokens. <div> id="authId" Next, let’s create a file - which is the actual React component that we will be rendering. Inside this file, we will initialize the SDK and use it in the React function. /src/components/Supertokens.tsx supertokens-auth-react render import * as React from "react";
import * as SuperTokens from "supertokens-auth-react";
import * as ThirdPartyEmailPassword from "supertokens-auth-react/recipe/thirdpartyemailpassword";
import { Github, Google } from "supertokens-auth-react/recipe/thirdpartyemailpassword";
import Session from "supertokens-auth-react/recipe/session";

SuperTokens.init({
   appInfo: {
       appName: "SuperTokens Demo App",
       apiDomain: "http://localhost:3001",
       websiteDomain: "http://localhost:4200",
   },
   recipeList: [
       ThirdPartyEmailPassword.init({
           signInAndUpFeature: {
               providers: [Github.init(), Google.init()],
           }
       }),
       Session.init(),
   ],
});

class SuperTokensReactComponent extends React.Component {
   override render() {
       if (SuperTokens.canHandleRoute()) {
           return SuperTokens.getRoutingComponent();
       }
       return "Route not found";
   }
}

export default SuperTokensReactComponent; The snippet above uses the recipe (social + email / password login). You can choose another recipe as well by following the quick setup section in the . ThirdPartyEmailPassword guides on supertokens.com Next, we will load this inside the component: SuperTokensReactComponent AuthView <script lang="ts">
import * as React from "react";
import * as ReactDOM from "react-dom";
import SuperTokensReactComponent from "../components/Supertokens";

export default{
    mounted(){
        ReactDOM.render(React.createElement(SuperTokensReactComponent),
            document.getElementById('authId'));
    }
    beforeDestroy(){
        ReactDOM.unmountComponentAtNode(document.getElementById('authId') as Element);
    }
}
</script> The above takes care of the related routes. For all the other pages in our app, we want to be able to know if a session exists and extract information from it. To do this, we will use the SDK. We initialize this SDK in our Vue app’s root file / : /auth/* supertokens-web-js src/main.ts import Vue from "vue";
import VueCompositionAPI, { createApp, h } from "@vue/composition-api";
import * as SuperTokens from "supertokens-web-js";
import * as Session from "supertokens-web-js/recipe/session";

import App from "./App.vue";
import router from "./router";

SuperTokens.init({
    appInfo: {
        appName: "SuperTokens Demo",
        apiDomain: "http://localhost:3001",
    },
    recipeList: [Session.init()],
});

Vue.use(VueCompositionAPI);

const app = createApp({
    router,
    render: () => h(App),
});

app.mount("#app"); The config for the call, the and the for both the functions ( and ) should always be the same. Session.init apiDomain appName init supertokens-auth-react supertokens-web-js 3.  Setup Routing to show the Login UI Vue CLI already generates the initial routing for our app inside / . We’ll update this file so that all routes load the component we created earlier: src/router.index.ts /auth/* AuthView import Vue from 'vue'
import VueRouter from 'vue-router'
import HomeView from '../views/HomeView.vue'

Vue.use(VueRouter)

const router = new VueRouter({
    mode: 'history',
    base: import.meta.env.BASE_URL,
    routes: [{
        path:'/auth*',
        name:'auth',
        component: () => import('../views/AuthView.vue'),
    }]
})

export default router The path for the component is . The * indicates that any sub / nested paths with /auth as the parent path should be rendered by the component. The component will in turn render the ReactJS component we created earlier which will use the SDK to show the auth UI. AuthView /auth* AuthView AuthView supertokens-auth-react We lazy load the route because the component loads ReactJS as a dependency. Lazy loading makes sure that these dependencies are only injected in the component when you visit the routes. For all of the other routes, these dependencies are not imported thereby maintaining the overall bundle size of the application. /auth AuthView AuthView /auth/* 4. View the Login UI If you now visit , you should see the login UI as shown below: http://localhost:4200/auth Backend Integration You can see the backend quick setup section in our , or even copy the code from . As a summary: docs on supertokens.com our example app You need to initialize the SDK and provide it the (similar to how you did on the frontend). supertokens-node recipeList Then you need to setup , add the SuperTokens and to your app. The SuperTokens exposes all the auth related API routes (like sign in, sign up, sign out etc) to the frontend. CORS middleware errorHandler middleware Finally, you need to provide the (location) of the SuperTokens core. To get started quickly, you can provide it (this is a core that we host for demo purposes). connectionURI https://try.supertokens.com Once you’ve successfully setup your server, you can now try and sign up on the frontend. Session management Inside file we’ll check if the user is authenticated and conditionally render a template. For authenticated users, we can show them a logout button with information about their session (like their ). For unauthenticated users, we can show them a button to route to the page. /src/views/HomeView.vue userId /auth <script lang="ts">
import * as Session from "supertokens-web-js/recipe/session";
export default {
    data() {
        return {
            session: false,
            userId: "",
        };
    },
    mounted() {
        this.getUserInfo();
    },
    methods: {
        redirectToLogin() {
            window.location.href = "/auth";
        },
        async getUserInfo() {
            this.session = await Session.doesSessionExist();
            if (this.session) {
                this.userId = await Session.getUserId();
            }
        },
        async onLogout() {
            await Session.signOut();
            window.location.reload();
        },
    },
};
</script>

<template>
    <main>
        <div class="body">
            <h1>Hello</h1>

            <div v-if="session">
                <span>UserId:</span>
                <h3>{{ userId }}</h3>

                <button @click="onLogout">Sign Out</button>
            </div>
            <div v-else>
                <p>
                    Visit the <a href="https://supertokens.com">SuperTokens tutorial</a> to learn how to build Auth
                    under a day.
                </p>
                <button @click="redirectToLogin">Sign in</button>
            </div>
        </div>
    </main>
</template> To load the component on / we’ll update the file: HomeView /src/router/index.ts const router = new VueRouter({
    // ...
    routes: [{
        path: "/",
        name: "home",
        component: HomeView,
    }, /*...*/],
}); If you now visit , you should see the following page: http://localhost:4200 SuperTokens Core Setup Whilst doing the backend setup, we are using as the for the core. This is a demo core instance hosted by the team of SuperTokens. You can use this for as long as you like, but when you are committed to using SuperTokens, you should switch to a or a of the core. https://try.supertokens.com connectionURI self hosted managed version Conclusion To summarize, we used the ReactJS SDK provided by SuperTokens to show the pre-built login UI for our Vue app. We also optimized the bundle size so that the ReactJS SDK is only loaded for auth related routes. Useful links: Example Vue app Discord community (to ask questions) List of recipes / auth methods Written by the Folks at — hope you enjoyed! We are always available on our . Join us if you have any questions or need any help. SuperTokens Discord server

How SuperTokens' Pre Built UI Can Be Used With VueJS

Unlike other ecosystems like .NET or Java in which containerizing an application for local development might seem more like a burden than a feature when it comes to PHP this is a necessity as well as a welcome bonus of mirroring the production environment very closely. Some applications might require a PHP extension that is not present on the local system or there might be some specific php.ini configuration that is set on the production server, which is considered as part of the infrastructure rather than the application itself but can cause problems because of the inconsistency (I had this happen to me several years ago). Using Docker can solve these types of problems and has also the added benefit of being a really good way to develop applications, an argument for this being the good support for remote debugging in IDEs. Overview I will go through setting up the entire stack, that is PHP 8.1 with fpm, Nginx, and MySQL as the database and at the end, we will do basic Symfony installation to test everything together. If you don't just want to check out the repo with the entire setup you can find it on Github Setting up docker-compose configuration There are two files that tell docker-compose what to spin up. The first is docker-compose.yml and the other is docker-compose.override.yml. The override file is responsible for exposing the host using the hostname . This is useful for both debugging and for referencing other containers more easily. dockerhost version: '3.5'

services:
  devbox:
    container_name: devbox-nginx
    build:
      context: ./docker/nginx
      dockerfile: Dockerfile
    ports:
      - "9001:80"
    volumes:
      - .:/app:cached
    restart: unless-stopped
    depends_on:
      - devbox-service

  devbox-service:
    container_name: devbox-service
    build:
      context: .
    volumes:
      - .:/app:cached
      - ./docker/service/php.ini:/usr/local/etc/php/conf.d/99-app.ini
      - ./docker/service/www.conf:/usr/local/etc/php-fpm.d/www.conf
    restart: unless-stopped
    environment:
      XDEBUG_CONFIG: ${XDEBUG_CONFIG}
      APP_ENV: ${APP_ENV}
      APP_DEBUG: ${APP_DEBUG}
      APP_SECRET: ${APP_SECRET}
    env_file:
      - .env
      - .env.local
    depends_on:
      - mysql

  mysql:
    image: mysql:8.0
    container_name: devbox-mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: database
    ports:
      - "3308:3306"
    volumes:
      - database-volume:/var/lib/mysql

volumes:
  database-volume:
    driver: "local" Adding Dockerfiles There are two Dockerfiles used. One for php-fpm and the other for Nginx. The one for the app itself is the php-fpm one and it's found at the root of the project and the other one is found in . docker/nginx/Dockerfile The Nginx Dockerfile just copies the Nginx configuration defined in default.conf into the container. The Nginx configuration is quite apart from the fact that the name of the service defined in docker-compose was specified Dockerfile for Nginx: FROM nginx:stable

COPY default.conf /etc/nginx/conf.d/default.conf Dockefile for php-fpm: FROM php:8.1-fpm-alpine

LABEL maintainer="alexandrunastase@github"
LABEL description="Devbox Docker image"

# User build args
ARG APP_ENV="prod"
ARG APP_DEBUG="0"
ARG APP_LOG="php://stdout"

# Environment variables
ENV APP_ENV=${APP_ENV}
ENV APP_DEBUG=${APP_DEBUG}
ENV APP_LOG=${APP_LOG}

ENV XDEBUG_CONFIG=""
ENV COMPOSER_NO_INTERACTION=1

# Add PHP user
ARG PHP_USER_ID=1000
ARG PHP_GROUP_ID=1000
RUN set -x \
    && addgroup -g $PHP_GROUP_ID -S php \
    && adduser -u $PHP_USER_ID -D -S -G php php

# Install dependencies
RUN set -ex \
    && docker-php-source extract \
    && apk add --update --no-cache \
    ${PHPIZE_DEPS} \
    curl \
    # Runtime deps
    icu-dev icu-libs \
    libzip-dev zlib-dev \
    libxml2-dev \
    oniguruma-dev \
    && pecl install xdebug \
    && docker-php-ext-install intl opcache pdo_mysql zip bcmath mbstring sockets pcntl soap sockets ctype > /dev/null \
    && docker-php-ext-enable intl opcache pdo_mysql zip bcmath mbstring sockets pcntl soap sockets ctype \
    && apk del ${PHPIZE_DEPS} \
    && docker-php-source delete

# Copy configuration files
COPY ./docker/service/www.conf /usr/local/etc/php-fpm.d/www.conf
COPY ./docker/service/php.ini $PHP_INI_DIR/conf.d/99-app.ini
COPY ./docker/service/xdebug.ini $PHP_INI_DIR/conf.d/docker-php-ext-xdebug.ini

# Install composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

COPY --chown=php . /app

WORKDIR /app

USER php Creating a Makefile I found a Makefile a useful addition to any docker-compose setup, as it makes it much easier to access common commands without needing to remember how a container was named or needed to search the shell history. When editing Makefiles make sure to always use tabs instead of spaces, especially when indenting commands. .PHONY: run
run:
	@if [ ! -e ".env.local" ]; then\
		cp .env .env.local; \
	fi
	@docker-compose up -d
	@echo "Service is running on http://localhost:9001"

.PHONY: install
install:
	@docker-compose exec --user="php" -T devbox-service composer install

.PHONY: stop
stop:
	@docker-compose stop

.PHONY: enter
enter:
	@docker-compose exec --user="php" devbox-service /bin/sh

.PHONY: enter-as-root
enter-as-root:
	@docker-compose exec --user="root" devbox-service /bin/sh

.PHONY: test
test:
	@docker-compose exec --user="php" -T devbox-service /bin/sh -c 'APP_ENV="test" ./bin/phpunit --testdox'

.PHONY: destroy
destroy:
	@docker-compose down --rmi local Adding Symfony and testing everything To test the entire setup we can set up a Symfony application. You can find instructions to do so . I went with the LTS version which is 5.4 at the time of writing. here I also updated the composer file to make sure the database is created. You can skip this if there's another way to make that happen. Setting up xDebug Debugging can be enabled by uncommenting the contents of the file ./docker/service/xdebug.ini These are the steps to configure xDebug on PHPStorm: Choose as CLI interpreter. Make sure the local interpreter is removed PHP Remote Debugging Choose as the configuration type and as the service Docker Compose devbox-service Lifecycle should be Connect to existing container Working demo In the docker-compose the port is mapped to the localhost so you can check if everything is working after running: 9001 make run To set up the containers: make install to install all the composer packages. There is one endpoint defined call which should return a 200 status code. http://localhost:9001/healthz In order to run the tests, you can run: make test To run other ad-hoc commands like requiring another composer package you can do: make enter Tested using Ubuntu 21.10 docker version : 20.10.14 docker-compose version : 1.29.1 Also published . here

Dockerizing Your PHP Application

In this tutorial, you’ll learn how to add SuperTokens authentication to your React and NodeJS application and deploy it on Vercel. Getting started To get started with SuperTokens, please visit the and pick the login method you want for your application. After choosing a guide, follow the quick setup section or one of the sections for integrating with a framework that you have chosen. Recipe Guides page We also have a blog post on how to integrate , if that is what you are looking for. email password + social login with express and react Restructuring your application for Vercel deployment Once you have done the basic implementation on your local system, we want to do the following to convert your application so that it can be deployed on Vercel: Create an folder. This folder will contain the API logic that we can deploy on Vercel. We will be exposing the API's entry point via an file in this folder. api index.js Open the and export at the end of the file as shown below index.js app module.exports = app; Note: We are deploying our backend as a standalone express app, and not with serverless functions that Vercel provides. If you want to deploy using , then you can check out our nextJS framework integration guide that's within the recipe guide. /pages/api /pages/api Change the appInfo config to get Vercel deployments to work To enable your project to run on production and the inspect sites for Vercel, you need to make the and point to the URLs generated by Vercel. The production URL is always the same for an app, but the inspect URL keeps changing. To allow it to work in this dynamic condition, we must set the values of and dynamically. websiteDomain appDomain apiDomain websiteDomain On the backend appInfo = {
    appName: "My App",
    apiDomain: process.env.VERCEL_URL,
    websiteDomain: process.env.VERCEL_URL,
    apiBasePath: "/api/auth",
    websiteBasePath: "/auth",
}, Vercel provides an env var - - to the backend which is equal to the inspect URL / production URL (depending on the site that’s loaded). So we use this to set the and values dynamically. process.env.VERCEL_URL apiDomain websiteDomain On the frontend We can use it to get the currently loaded URL and set those to the and . This way, even if the inspect URL keeps on changing, it will still point to the current domain. window.location.origin apiDomain websiteDomain appInfo = {
    appName: "TodoApp",
    apiDomain: window.location.origin,
    websiteDomain: window.location.origin,
    apiBasePath: "/api/auth",
    websiteBasePath: "/auth",      
}, This only works if the frontend and backend of your application have the same domain. If your backend is hosted elsewhere and you use Vercel only for the frontend, be sure to change the on the frontend and backend to point to your backend server. In this case however, your app may not function properly for inspect deployments since your backend server has no way of knowing what the inspect URL of the frontend site would be on each deployment. apiDomain Update the CORS Middleware You also need to update the CORS middleware origin with the environment variable. VERCEL_URL app.use(
    cors({
        origin: process.env.VERCEL_URL,
        allowedHeaders: ['content-type', ...SuperTokens.getAllCORSHeaders()],credentials: true,
    })
); Configure Vercel and Deploy With the backend and frontend of your application code updated, create a file in the root directory of your application which will instruct Vercel to push all traffic on path to our express backend server: vercel.json /api/* {
    "rewrites": [{ "source": "/api/(.*)", "destination": "/api" }]
} Finally, to deploy the app to Vercel, you need to run the Vercel command on the root of your project: vercel Once deployed, you should be able to test the login functionality on the inspect URL and the production URL. Demo app We also have that has Email Password login with express and React, and is configured to work with Vercel. You can even see its . a demo app on our GitHub live preview Written by the Folks at — hope you enjoyed! We are always available on our server. Join us if you have any questions or need any help. SuperTokens Discord

Deploying SuperTokens with React and NodeJS on Vercel

Adding Auth Flow Using SuperTokens into a React and Hasura GraphQL App

Stories, News & Mentions about APPINIO

Appinio’s Stories on HackerNoon