You’ll be able to add and query data from your database, and even update or delete records. All of this can be done in just a few simple steps! So if you’re ready to get started creating your own powerful CRUD API with FastAPI and Supabase, read on!

What is Supabase?

Supabase is an open-source Firebase alternative. It provides the same functionality and architecture as Firebase, but with a focus on Postgres databases instead of NoSQL storage.

Supabase provides a number of features including real-time streaming, authentication, storage, and more. It's designed to be easy to use for developers who are familiar with SQL databases such as Postgres or MySQL. With Supabase, you can quickly and easily set up a CRUD API (and much more) that can handle all your data needs.

What is FastAPI?

FastAPI is an open-source web framework built on top of Python's highly popular asynchronous web framework, Starlette. It is designed to help developers create high-performance, reliable, and secure APIs quickly and easily.

FastAPI makes use of industry-standard tools such as OpenAPI and JSON Schema, ensuring that all APIs created using it are fully compatible with existing APIs used by other applications. Its architecture is also specifically designed for scalability so that developers can easily scale their projects as their user base grows.

Setting up Supabase Project

To integrate Supabase with Python, we need Supabase URL & API Key. We can get these directly from Supabse. First, create a project in Supabase from the Supabase dashboard.

Once the project is up, navigate to Project Setting < API and copy the URL & API Key.

After copying the URL & Key, navigate to the Tables tab and create users table and add 3 columns: name , email , and password .

Integrating FastAPI with Supabase

Before we integrate FastAPI with Supabase, let's first create a virtual environment and install the required dependencies.

mkdir fastapi-supabase; cd fastapi-supabase
pipenv shell
pip install "fastapi[all]" bcrypt supabase

🚨Note: If you don't have pipenv installed, you can install it using the sudo apt install pipenv command.

Once all dependencies are installed, create a config.py file to store secrets. Although storing secrets in plain text is never recommended, for the sake of ease of this tutorial, let's add the secrets in the config file.

url="https://abc.supabase.co"
api="dummy-api"

💡Learn more: How to Handle Secrets in Python

Now, let's create a FastAPI application. First, create an app directory containing the main.py file and paste the following code.

from fastapi import FastAPI

app = FastAPI()

app.get("/")(lambda: {"Hello": "World"})

This is a bare-minimum FastAPI application running on http://127.0.0.1:8000/ and returning {"Hello": "World"} on / route. Start the server using the command:

uvicorn app.main:app --reload

FastAPI Supabase Connection

We have successfully created the Supabase project and FastAPI application. Now let's connect to Supabase. Create a db directory and add a supabase.py file with the following code. Also, add __init__.py file in the db directory.

from supabase import Client, create_client
from config import api, url

api_url: str = url
key: str = api

def create_supabase_client():
    supabase: Client = create_client(url, key)
    return supabase

We can now import create_supabase_client function in our main.py file to connect to Supabase.

CRUD API using Supabase & FastAPI

We have successfully connected to Supabase. Now, let's create a route to add data in the table but before we do that, let's first create a Pydantic BaseModel which we will use to validate the request body. Create a models.py file in the app directory and add the following code.

from pydantic import BaseModel

class User(BaseModel):
    name: str
    email: str
    password: str

Now, let's add the first route in the main.py file to add data to the users table.

import bcrypt
from fastapi import FastAPI
from app.models import User
from db.supabase import create_supabase_client

app = FastAPI()

# Initialize supabase client
supabase = create_supabase_client()

def user_exists(key: str = "email", value: str = None):
    user = supabase.from_("users").select("*").eq(key, value).execute()
    return len(user.data) > 0

# Create a new user
@app.post("/user")
def create_user(user: User):
    try:
        # Convert email to lowercase
        user_email = user.email.lower()
        # Hash password
        hased_password = bcrypt.hashpw(user.password, bcrypt.gensalt())

        # Check if user already exists
        if user_exists(value=user_email):
            return {"message": "User already exists"}

        # Add user to users table
        user = supabase.from_("users")\
            .insert({"name": user.name, "email": user_email, "password": hased_password})\
            .execute()

        # Check if user was added
        if user:
            return {"message": "User created successfully"}
        else:
            return {"message": "User creation failed"}
    except Exception as e:
        print("Error: ", e)
        return {"message": "User creation failed"}

In the above code, we have /user POST route to add data to the table by using insert function from supabase . We are also using user_exists function to check if the user exists in the table or not. Additionally, we are using hashpw function to hash the password before storing the password in DB (NEVER store plain text passwords in DB).

Now, let's test it out using curl . You can also use the Swagger UI or any other API testing tools (such as Postman).

curl -X POST -H "Content-Type: application/json" -d '{"name": "John Doe", "email": "john.doe@example.com", "password": "password123"}' http://127.0.0.1:8000/user

🚨Note: Swagger UI can be accessed by visiting the /docs or /redoc environment.

If you have followed all steps properly, you will receive the following response.

{"message":"User created successfully"}

Let's now quickly update the main.py file to add functions to perform READ, UPDATE, and DELETE operations.

from typing import Union

import bcrypt
from fastapi import FastAPI
from app.models import User
from db.supabase import create_supabase_client

app = FastAPI()

# Initialize supabase client
supabase = create_supabase_client()

def user_exists(key: str = "email", value: str = None):
    user = supabase.from_("users").select("*").eq(key, value).execute()
    return len(user.data) > 0

# Create a new user
@app.post("/user")
def create_user(user: User):
    try:
        # Convert email to lowercase
        user_email = user.email.lower()
        # Hash password
        hased_password = bcrypt.hashpw(user.password, bcrypt.gensalt())

        # Check if user already exists
        if user_exists(value=user_email):
            return {"message": "User already exists"}

        # Add user to users table
        user = supabase.from_("users")\
            .insert({"name": user.name, "email": user_email, "password": hased_password})\
            .execute()

        # Check if user was added
        if user:
            return {"message": "User created successfully"}
        else:
            return {"message": "User creation failed"}
    except Exception as e:
        print("Error: ", e)
        return {"message": "User creation failed"}


# Retrieve a user
@app.get("/user")
def get_user(user_id: Union[str, None] = None):
    try:
        if user_id:
            user = supabase.from_("users")\
                .select("id", "name", "email")\
                .eq("id", user_id)\
                .execute()

            if user:
                return user
        else:
            users = supabase.from_("users")\
                .select("id", "email", "name")\
                .execute()
            if users:
                return users
    except Exception as e:
        print(f"Error: {e}")
        return {"message": "User not found"}


# Update a user
@app.put("/user")
def update_user(user_id: str, email: str, name: str):
    try:
        user_email = email.lower()

        # Check if user exists
        if user_exists("id", user_id):
            # Check if email already exists
            email_exists = supabase.from_("users")\
                .select("*").eq("email", user_email)\
                .execute()
            if len(email_exists.data) > 0:
                return {"message": "Email already exists"}

            # Update user
            user = supabase.from_("users")\
                .update({"name": name, "email": user_email})\
                .eq("id", user_id).execute()
            if user:
                return {"message": "User updated successfully"}
        else:
            return {"message": "User update failed"}
    except Exception as e:
        print(f"Error: {e}")
        return {"message": "User update failed"}

# Delete a user
@app.delete("/user")
def delete_user(user_id: str):
    try:        
        # Check if user exists
        if user_exists("id", user_id):
            # Delete user
            supabase.from_("users")\
                .delete().eq("id", user_id)\
                .execute()
            return {"message": "User deleted successfully"}

        else:
            return {"message": "User deletion failed"}
    except Exception as e:
        print(f"Error: {e}")
        return {"message": "User deletion failed"}

We have added functions to perform CRUD operations on users table. We have used GET to get user (or list of users) information, POST to add information to the table, PUT to update name and email and DELETE to delete data from the table.

In the update_user function, we are receiving user_id , name and email from the client and checking if the user (with user_id) exists in DB or not. If yes, we update the name and email in the table.

curl -X PUT "http://127.0.0.1:8000/user?user_id=5&email=test@gmail.com&name=hello"

In the get_user function, we receive user_id as a query parameter. In this case, user_id is optional. If user_id is present, we respond back with user details (without password) otherwise we send back a list of users from the users table.

curl http://127.0.0.1:8000/user

The delete_user simply checks if the user with user_id from query parameter is present in the table or not. If it's present, it deletes the user.

curl -X DELETE "http://127.0.0.1:8000/user?user_id=5"

🚨Note: This is just a basic tutorial for an explanation. Please thoroughly test your application before moving your application to production! 🚀

Link to Code

Here's the GitHub repository with the complete code.

Conclusion

In this blog, we discussed how developers can use FastAPI and Supabase to quickly build a powerful CRUD API. With the step-by-step guide provided, developers will be able to leverage the power of both platforms to query data from their database and even update or delete records with ease.

Furthermore, all APIs created using FastAPI are fully compatible with existing APIs used by other applications due to their use of industry-standard tools like OpenAPI and JSON Schema. So if you're looking for an efficient way to create your own RESTful API then give FastAPI & Supabase a try today!

If you have any questions, feel free to send me an email 📧.

Thank you for reading! 🎉👨‍💻

To get a better idea of how big open source has become, we have some recent insights: according to a survey from Gartner, over 90% of the respondents stated that they rely on open source components. In another report from Synopsis, 98% of the audited codebases contained at least one open-source component, and 75% of the source code came from open-source. The report also noted that 85% of the audited codebases contained components "more than four years out of date".

This last data reveals the growing concern about the reliability and security of all this open-source material found in private code bases. Packages that are not maintained anymore cannot be patched for recently discovered vulnerabilities. Therefore it's become critical for organizations to be able to inventory open-source components and assess their vulnerabilities, making the use of software composition analysis mandatory. But not all SCA tools are created equal.

This blog post will provide eight factors to consider when choosing an SCA tool.

What is SCA (Software Composition Analysis)?

SCA is the process of analyzing an application's dependencies to determine if it is affected by known security vulnerabilities. Organizations can more effectively manage security risks by understanding the dependencies between components.

SCA can be performed either manually or using automated tools. Manual SCA is not scalable as the engineers must constantly check a vulnerability database such as NVD (National Vulnerability Database, maintained by NIST) and then compare the vulnerable versions with their existing dependencies. Much more efficient is to use automated SCA scanning tools, which can be triggered manually or integrated into the CI/CD pipeline for continuous checks.

Importance of Software Composition Analysis

SCA is integral to application security, as it helps identify and mitigate risks associated with using third-party components. SCA can help identify vulnerabilities in third-party components that attackers could exploit. It can also help track the versions of third-party components and ensure that they are up to date. By keeping track of the components used in an application, SCA can also help ensure compliance with license and security policies.

In short, SCA is an essential part of the code security toolkit, focused on third-party components.

How is SCA different from SAST?

SAST is a software testing technique that involves analyzing the source code of a software application to identify potential security vulnerabilities such as injection attacks, cross-site scripting (XSS), improper error handling, and insecure use of cryptographic functions.

SAST aims to identify security vulnerabilities early in the software development cycle to mitigate them before the application is compiled and deployed.

While SAST is an analysis technique used to check for known vulnerabilities in source code, SCA is used to scan dependencies for security vulnerabilities and license issues.

Both are usually performed pre-build (against source code), or post-build (against binaries), as they don't require an application's execution to identify potential vulnerabilities. Both are equally important in ensuring the security of a software application.

How to Choose an SCA tool?

The many SCA tools on the market today can make it hard to decide which is the right one for your needs. To help you select the right one, we have curated a list of 9 things you should look out for in an SCA tool:

1. Language Support

When opting for an SCA tool, it's vital to check what all languages are supported by the tool. Software composition analysis is language, end even ecosystem-dependent (package managers, build system, etc.): for instance, most SCA tools rely on lock files such as package-lock.json or Pipfile.lock to find dependencies and their respective versions. So you need to be careful here.

2. Accessible to Use/Developer Friendliness

The SCA tool you choose should make your life easier, not harder. It should be intuitive and easy to use so that you can focus on your work, not on learning the tool. It should also be developer friendly so that you can easily integrate it into your existing development process. Also, it should be scalable to grow with your organization.

The vendor should also have proper technical documentation available for the developers and having technical support for the tool is always a plus.

3. Support for Binary scanning

When looking for a Software Composition Analysis (SCA) tool, choosing one that supports the scanning of binary files is essential. Many SCA tools don't support this type of scanning, which can leave vulnerabilities in the binaries used by the developers unchecked.

Scanning binary files such as wheel files(.whl) are essential because it can find vulnerabilities that would otherwise be missed by scanning the dependencies. If you are not doing binary scanning used by your developers, you are not getting the complete picture of your code's security.

4. Direct vs. Transitive Dependencies

There are two types of dependencies in software development: direct and transitive.

A direct dependency is when one piece of software directly depends on another piece of software. For example, if software A directly uses software B, then A has a direct dependency on B. Conversely if software A uses software B, and software B uses software C, then A has a transitive dependency on C.

The SCA tool should be able to provide you with the information if the vulnerability is in the direct dependency or transitive dependency. This is important because both types of dependencies can pose a security threat to a software project.

5. False positives / False negatives

If you are not familiar with the concept of false positives and false negatives, you should read this article about accuracy, precision, and recall.

In a nutshell, false positives are vulnerabilities wrongly flagged as such by the tool, and false negatives are genuine vulnerabilities that the detection tool silently skipped. This is an important factor to consider when choosing a software composition analysis tool because false positives can lead to wasted time and resources.

Developers may spend a significant amount of time manually reviewing and investigating these results, even though most are not security threats. This (also known as "alert fatigue") can be frustrating for developers and decrease their trust in the tool, potentially leading them to ignore or not use the tool as frequently as they otherwise would.

The numbers reported by vendors can be challenging to verify. The best way to ensure that an SCA tool can accurately identify security threats while minimizing the number of false positives is to test it (for free, when possible).

6. Webhooks & API Support

When looking for an SCA tool, it's essential to check if the tool has proper API and webhook support so that you can easily integrate it into your CI/CD pipeline.

Having proper API and webhook support will allow you to automate SCA scanning as part of your CI/CD process, which will help ensure that your applications are always up-to-date and compliant with security standards. Without proper API and webhook support, you may have to manually trigger SCA scans, which can lead to delays in your pipeline.

7. Rich Vulnerability Database

A good SCA vendor should have a rich vulnerability database to detect vulnerabilities in your open-source packages. Such a database would enable the SCA vendor to provide you with customized alerts and recommendations on the best way to fix the identified vulnerabilities.

In addition, the SCA vendor should have a team of expert analysts who can help you understand the nature of the vulnerabilities and their potential impact on your organization in case you need any support.

8. Time to Onboard New CVEs

SCA tools are used by many organizations to keep track of vulnerabilities and potential security risks. It's essential to check how much time the SCA tool takes to onboard new CVEs on their platform from the vulnerability database. This allows organizations to plan for and respond to new security risks promptly. Additionally, it helps to ensure that SCA tools are up-to-date and provide accurate information about the latest security threats.

9. Detailed Reporting/Remediation

The scanning should provide detailed reporting that helps the security team understand the scan results of the open-source packages. The report should include a list of all the packages that were scanned, as well as the results of the scan, including

• Vulnerability description

• CVSS score

• CVSSv3 score

• Version impacted

The SCA tool should also provide proper remediation steps so that the developers can fix the issues.

Conclusion

Open source has become the norm in the software development world, with nearly 80% of companies using open-source software in some form or another. For many companies, open source is the preferred choice for software development due to its flexibility, cost-effectiveness, and vast ecosystem of available tools and resources.

However, with the increasing popularity of open source, there is also an increase in the number of vulnerabilities of open-source packages. This can create several risks and challenges for companies, including vulnerabilities in developed applications, licensing issues, and potential security breaches.

Having SCA tools in your build and deployment pipeline can help you avoid security risks that might arise from any open-source dependency. You should now be more informed about the important factors to consider before selecting such as tool.

There's a lot to love about GitHub, and the organizational structure it can give you is definitely one of them. When you share your code with other developers, make it public, or collaborate with a large team (or even a small one), the circle expands faster than you would imagine. Like it or not, a managed hierarchy of access and well-thought rules become imperative for the sustainability and security of your projects.

What could go wrong if you do not manage access? It's a legitimate question considering you trust the people you collaborate with. Well, all it takes is an honest intern who rewrites the history in your master branch to wreak havoc. Let us say it is safe to have a managed organizational structure, and that's what we'll talk about.

In this blog, I will guide you through the best practices for managing developer teams in GitHub Orgs and provide recommendations to help you secure your GitHub organization.

What is an organization in GitHub?

A GitHub organization is a shared platform where you can put one or more repositories and share controlled access with members and collaborators who can perform specific tasks. These organizations can be companies, non-profit organizations, some coalitions, or independent developers working together on a project for fun. An unlimited number of people can collaborate in an organization across multiple projects.

Usually, an organization has five levels of role-based permissions

• Owner: has complete control of the organization along with full administrative access. They can determine the team's access level to the project code.

• Billing manager: can manage payment settings for the organization. This includes setting up payment methods, managing subscriptions, and viewing invoices.

• Member: is granted role-based access to control what they can see and do within the organization. Depending on their role, they may access the repositories or projects.

• Moderator: have all the permissions granted to members by default. On top of that, they can block or unblock outside collaborators, set interaction limits, and hide comments on public repositories that belong to the organization.

• Outside collaborator: a contractual member who's granted access to one or more repositories to perform specific tasks but doesn't have the full array of permissions granted to the members.

What is a team in GitHub?

Teams are groups of members that reflect the organization's structure. The teams are maintained by organization owners and team maintainers who can manage the level of access granted to a team and add or remove members. Teams have pages where you can see the members, child teams, the team profile picture, etc.

Managing a team's access to repositories in GitHub

The owners can give a team access to a repository, remove the access, or modify the permission level to a specific repository based on the need. If a team has direct access to a repository, the access can be simply removed. However, if a team has inherited access from a parent team, then the maintainers have to remove the access for the parent team to remove access for the child team.

8 Best Practices for Managing Teams in GitHub

Now that we have somewhat established organizations and teams in GitHub let's jump right into the practices that make it easier to manage teams safely and sustainably.

Configure the Organization

Creating an organization on GitHub is extremely simple; it takes just a few clicks. But you should take the time to configure the organization based on the group's specific needs. This could mean restricting access to certain repositories, setting up review cycles, or modifying other settings to strengthen the organization's security. This will help to keep things organized and make it easier for team members to find the information they need.

One Branch for Each Feature or Bug

One of the key advantages of a GitHub organization is allowing an unlimited number of developers to work on different projects simultaneously. Having a branch for each bug or feature helps you make the most out of this advantage, allowing multiple people to work on various features without worrying about overwriting the code written by someone else. This also keeps things well organized.

Create Nested Teams

As an organization owner, you can create child teams or nested teams that inherit the permissions from their parent teams. It simplifies access management, as adding or removing permissions for the parent teams automatically means doing the same for the child teams.

When working with a large number of groups, having nested teams simplify communication. Nested teams can also be given different permissions than their parent teams so that you can tailor the team's access to your organization's needs.

Assign Code Owners

The success of a project relies heavily on code reviews. Code owners are a special type of GitHub user responsible for reviewing and approving code changes in a repository. Code owners can be assigned to specific files or directories and will be notified whenever a change is made to those files. This makes pull requests safer, removes the confusion pertaining to ownership and reviews, and ensures the smooth functioning of a team.

Rebasing the Feature Branches

As we have discussed earlier, creating a branch for each feature or bug is a good practice. But if a team is working on a bunch of features simultaneously, it creates a complicated graph of branches that becomes very difficult to track. To avoid that, the ideal practice is to rebase the feature branches with the master branch.

Rebasing can help resolve merge conflicts more efficiently and make it easier to track changes and keep your codebase up to date.

Squash Commits Before Merging

Commits are like milestones in the journey of a Git project. Squashing commits is a way of rewriting the commit history before you share it with your team. It keeps the commit history clean and makes it easier to associate a bug with a specific commit when it comes to testing or debugging.

Setup Pre-Merge & Post-Merge Jobs with GitHub Repositories

If you're using GitHub for your project development, you can easily set up pre-merge and post-merge jobs to run automatically on your repositories.

This also helps to ensure that the code integrates properly and that any potential conflicts are resolved before they cause problems. Pre-merge jobs can be used to run tests and verify that the code compiles correctly. Post-merge jobs can be used to deploy the code to a staging environment for further testing.

Use Secret Scanning Tools

Secret scanning tools like GitGuardian or gitleaks can help you avoid accidentally leaking secrets like API keys and passwords through your GitHub repositories. These tools work by scanning your repositories and pull requests for potentially sensitive information and then alerting you so you can take action to remove or protect the information. You can install the GitGuardian App through the GitHub Marketplace for free on public repositories here.

Using a secret scanning tool is a good first step in preventing accidental leaks, but it's also important to be aware of the potential risks and to review your code regularly to ensure that no sensitive information is accidentally left exposed.

Track Progress using GitHub Projects

It is essential to keep track of team progress. This can be done by creating a GitHub project board and adding issues and milestones. This feature allows you to create Kanban-style boards for your repositories to see what's being worked on and what is still pending. You can also add notes and tags to your cards to keep all the relevant information in one place. Tracking progress using GitHub Projects is a great way to keep your project organized and on track.

Best practices to secure your GitHub Organization at a glance

To keep your GitHub Organization secure, it is essential to follow best practices. Some of these best practices include:

Backup & restore for your repos

As a best practice, it is always recommended that you have a backup and recovery plan for critical repositories and ever-changing metadata. This will help ensure that you can recover your data in the event of a disaster and that your metadata is always up-to-date.

Supervise access controls

One of the most crucial security steps is setting access controls on an as-needed basis. Make sure that no one has more permissions than they need to have. This will help to prevent unauthorized access to sensitive information. You should also have a process in place for revoking access when someone no longer needs it.

MFA for all

Enforce multi-factor authentication for all members of the GitHub organization, moderators & billing managers. MFA (multi-factor authentication) adds an extra layer of security to your account by requiring you to enter a code from your mobile phone or another device in addition to your password. This makes it much harder for threat actors to gain access to your account, even if they have your password.

Security policies

Organizations on GitHub have several different security settings that can be adjusted to fit the organization's needs. It is essential to review these settings regularly and audit your member's activity to ensure that your organization's data is safe.

To sum it up

GitHub organizations are fantastic if you can maintain a few habits and imbibe some practices into the way your teams function. The responsibility is shared between the owners and the team members. As the owner, you can create nested teams, set security policies, and assign code owners to make things easier. Then if the team members can pull their share of the weight by being responsible for squashing the commits, rebasing the branches, and testing code, everything falls into place.

One such way is using Merge Queues. Merge Queue allows developers to manage and collaborate on code changes on a large scale.

Merge Queues are a crucial part of how most tech companies are able to manage and collaborate on code at such a large scale. Merge Queues allow developers to work together on code changes without worrying about breaking the production, merge conflicts, or waiting for PR to be merged.

Understanding the Problem

Engineering teams are tasked with developing new features across multiple branches to keep many different products in step. This means that there is a lot of merging to do. When many engineers are working concurrently, there are likely to be many branches and PRs; merging these branches can lead to various conflicts and even break the application or production environment.

Most companies use CI to prevent such issues. But even with CI in place, if you don't manage your PRs correctly, you may break the prod. But how? Let me explain this with an example.

You asked your team of developers to add X features to the application. They started working on it based on what you assigned them by creating their feature branch. One of the developers completed the task and created the PR, and CI checks also ran successfully. Meanwhile, the other developer also changed one of the files affecting the first PR and created his PR (CI ran successfully again🟢).

The senior developer started looking at both the PRs and thought of merging as CI passed, and everything was good. The senior dev merged the second PR first, which changed in the file affecting the other PR. As the CI was already 🟢, he merged the other one too. You know what happened next.

How to Overcome the Problem? 💡

The solution to this problem is Merge Queues that automate this tedious task for you by ensuring that before merging, the PRs are up-to-date with their respective base branches. And if you have a CI process, it will pick up these PRs again and rerun the jobs on the new code.

So, GitHub must be offering this. Not quite ❌. GitHub provides a built-in merge queues feature; however, as per their official documentation, it is currently in limited public beta and thus not generally available to all. On the other hand, GitLab calls this feature Merge Trains and is available only for premium users.

If you use GitHub and have been reviewing PRs even for a while now, you know that there are certain kinds of PRs that you don't even need to thoroughly review based on whatever factors like saying a PR is good to be merged if the PR:

• just adds files and does not modify or delete any of the existing files
• modifies just the README.md file
• is approved by a senior developer 🧑‍💻

This is where Mergify comes in 🚀. Mergify enables you to do that and a lot more. It's a SaaS integration that connects with GitHub repositories to automate and assist with prioritizing, queuing, and merging PRs.

Here are some more use cases for you that can be achieved with Mergify apart from condition-based automated merging:

1. Rebase the source branch of PRs
2. Label and assign to fellow team members
3. Delete the head branches upon PR merge

Although there are various options in the market for merge queues like MergeQueue, Mergify stands out as not just a merge queue offering but also as a process automation solution.

Some of the benefits of using Mergify over MergeQueue and other similar alternatives include:

1. Offers time-saving features such as speculative checks and batch pull requests that positively affect the merge time.
2. Offers the ability to set up multiple queues in which you can sort, order, and prioritize your PRs based on condition checks and how your processes work.
3. Offers not just safe code merging capability but a complete automated approach towards dealing with multiple collaborators for your codebase.
4. Offers community support and dedicated customer success manager on paid plans where you also get premium features such as priority queues, random request reviews, private deployments, and much more.

How to Setup and Install Mergify? 😁

Now when we have a fair understanding of what Mergify is and how it can help us, let's dive into how you can get started with Mergify.

• Have yourself signed into your GitHub account.
• Have a public repository ready to be connected with Mergify. (private repositories are supported in paid plans)
• Head to Mergify SignUp and sign in via GitHub, and you can choose to let Mergify connect to all your repositories or select a few, similar to how GitHub apps work.

Getting Started with Mergify 🚀

Now when you're all signed up and Mergify connected to your GitHub repository, let's walk through a couple of examples to see how Mergify can solve our problems.

Mergify's configs have a pretty simple structure. It has a list of conditions that, when become true with respect to any of our PRs, the mentioned actions shall take place.

We can define multiple pull request rules that Mergify will check our PRs against but for the sake of simplicity of this article, let's stick to the simple ones that will help a larger audience get started with Mergify.

To set up a config, you need a file .mergify.yml in the root of your directory that will tell Mergify what to do with the PRs. What we'll have in the config editor when we open it up for the first time will be a very basic initial configuration that the Mergify config editor loads up by default once a repository is connected.

What's nice about Mergify is that you can create a PR from the Mergify Dashboard itself that'll create a .mergify.yml file for you in your repo. Even if you feel it's too soon and you need to test it before committing stuff, then there's a test option available within the config editor where you can test your config against a particular PR to test out the config. It also acts as a validation of your config schema.

Let's go through the same initial config where we've added just another condition.

pull_request_rules:
  - name: Automatic merge on approval
    conditions:
      - "#approved-reviews-by>=1"
      - "author=theinfosecguy-example"
    actions:
      merge:
        method: merge

Given the minimal config, translating this into simpler terms means that whenever a PR has either 1 or more approvals just go ahead and merge the PR.

In a PR in our example repo, as shown below, the PR was authored by @theinfosecguy-example and the moment the PR got approved by a collaborator, the Mergify bot went ahead and merged the PR as post the approval this PR matched all the conditions mentioned in our pull request rules in the config, as mentioned above.

You can refer to Conditions — Mergify documentation to get a hold of all the conditions Mergify can work with which you can further combine as per your teams’ needs.

Mergify will take care of your simple checks freeing a large chunk of your time to focus on the more challenging PRs where merge conflicts arise and PRs with outdated base branches require your input.

Here’s another example where we have multiple PRs that desire to update a single file meaning that the base branch of the second PR will be outdated once the first PR is merged but Mergify is here to save the day.

Firstly we have defined a queue, you can define multiple as per your requirement, and then we have to define pull request rules. Here’s the config for your reference.

queue_rules:
  - name: default
    conditions: []
pull_request_rules:
  - name: merge using the merge queue
    conditions:
      - "#files=1"
      - "author=theinfosecguy-example"
    actions:
      queue:
        name: default

In this particular config, we have set up a queue named "default" and the conditions say that if the PR modifies one single file and is authored by a specific user, then send the PR to the "default" merge queue to be further merged.

Let's take another example to understand better the automated PR management in a team of multiple collaborators where say; you have a senior Python developer and a DevOps team to be looped in regarding security-related tasks.

queue_rules:
  - name: default
    conditions: []
pull_request_rules:
  - name: assign PRs with Python files modified to theinfosecguy-example
    conditions:
      - files~=\.py$
      - -closed
    actions:
      assign:
        add_users:
          - theinfosecguy-example
  - name: ask the security team to review security labeled PR
    conditions:
      - label=security
    actions:
      request_reviews:
        teams:
          - "@myorg/devops"

This above-mentioned config has two rules, the first one will look for open PRs that modify any files with .py extension and assign the PR to theinfosecguy-example whereas the second rule states that if a PR is labeled as “security” then request reviews from the “devops” team from your GitHub organization which you’d anyway do if even if not automated.

Having a look at their documentation, Mergify can cater to many use cases with its powerful condition-based automation configurations.

Conclusion 🙌

All merge queues do is avoid merging outdated PRs to prevent merging broken pull requests and extend that functionality. Mergify also automates DevOps operations, prioritization, queuing, and condition-based automatic merges. You can have multiple queues, multiple condition checks, more advanced checks with logical and grouping, and whatnot.

Although Mergify requires a paid subscription to set up multiple queues and connect to private repositories, it is free and offers basic open-source project features. They also have a 14-day free trial on their paid plans if you want to check out the premium features.

Check out Mergify!

Security is always a concern, and ReactJS is no different. If security is handled properly, ReactJS can be a great framework for developing web and mobile applications (using react-native).

This blog will list 3 best practices for ReactJS projects that can help you avoid security vulnerabilities.

What is ReactJS?

React is a front-end JavaScript library developed by Facebook. This library is used for building user interfaces and allows you to create reusable components.

The Facebook team built it because they needed a way to handle DOM updates while the browser was still rendering a page, so the user wouldn't notice the page was still loading. React has become more and more popular over the last few years. A lot of people love it for its sheer simplicity and its speed.

Why is Secure Coding Important?

Every technology has its own set of security vulnerabilities. The big question is, are you securely using them? You may have heard the term "secure coding" before, but what does it mean?

Secure coding refers to the practice of writing code that is immune to attacks. It is a subset of software security that refers to all aspects of a software system, including but not limited to its architecture and implementation, that prevent malicious parties from being able to access the software for malicious purposes.

Today, most applications are vulnerable to the OWASP top 10 vulnerabilities, and React applications are no different. If you don't know what these vulnerabilities are, you should probably look at them on the OWASP official website.

No matter what technology you use, you'll need to know how to implement secure coding practices. Let’s take a look at 3 security best practices for your React project that you can adopt today.

3 Security Best Practices for ReactJS

Everyone wants a secure application. But how do we achieve this? We need to do a couple of things to make the React application secure from the ground up. Let's dive in.

1. Avoid using dangerouslySetInnerHTML

Quite simply, dangerouslySetInnerHTML is a property you can use on HTML elements in a React application to set their content programmatically. But why is dangerouslySetInnerHTML dangerous?

If you are not careful with the HTML you are passing in, you could open yourself up to a cross-site scripting (XSS) attack. Let’s understand this using an example.

function XSS() {
  const vulnerableHTML = `
    <div>
        Hello, world!
        <img src="abc" onerror="alert('XSS')" />
    </div>`;

  return (
    <div>
      This is a XSS Vulnerable Component using dangerouslySetInnerHTML
      <div dangerouslySetInnerHTML={{ __html: vulnerableHTML }}></div>
    </div>
  );
}

export default XSS;

In the code mentioned above, we use dangerouslySetInnerHTML in a React Component. Still, if you carefully look at the HTML code stored in the vulnerable HTML variable, you’ll understand that when the stored HTML renders, this will make the application vulnerable to XSS (Cross-Site Scripting). But what exactly is XSS, and how can you prevent it?

Cross-site scripting (XSS) attacks inject malicious scripts into otherwise benign and trusted websites. Attackers can use XSS to bypass access controls such as the same-origin policy.

To prevent your application from XSS attacks, you must sanitize your data before passing it to dangerouslySetInnerHTML. Various NPM packages are available that can help you do so, or you can write your regex to sanitize the data.

Also Read: How to Fix Clickjacking on NGINX Server in 6 Simple Steps🔥

2. Avoid Hardcoding Secrets

If you use React in your application, you most likely have some secret information that you don’t want to expose to the internet. For example, you may have a database URL, API key, or password.

The common approach is to store the secrets in environment variables and then access them in the application using process.env.SECRET_KEY. Environment variables stored in .env are a part of the build and are publicly accessible. You can see that in your browser by going to the React Dev Tools.

AWS_ACCESS_KEY=""
AWS_SECRET_KEY=""
AWS_REGION=""

One of the ways to solve this issue is to store the keys on the server and then retrieve them as per your needs. But this is not a suitable way to do this. The best way is to pass the environment variable directly to the server wherever you host your application, like EC2.

Not just this, most frontend deployment platforms, such as Vercel, Netlify, etc., allow you to add environment variables directly through their platform.

3. Disable GENERATE_SOURCEMAP in Build Script

If you have a React application that you have deployed on any front-end platform or any server and you have not updated the build script from the package.json file, you might be disclosing your application's source code to the internet.

You can check this by going to the Source tab and clicking on your website name. Here’s how it looks.

As you can see in the above image, the whole source code of the application is disclosed; this vulnerability is known as Source Code Disclosure.

To fix this issue, update the build script to:

"build": "GENERATE_SOURCEMAP=false react-scripts build"

Learn more about GENERATE_SOURCEMAP

Conclusion

The security industry is fast-paced, so it’s difficult to stay up to date with the latest news and threats. As a developer, it’s important to keep up with the industry and be aware of the latest trends and threats. I’ve explained three best practices to avoid security vulnerabilities in the ReactJS application in this post.

If you have any questions or concerns about the post, feel free to reach out to me anytime. I would be happy to discuss how to make your next ReactJS Project secure and safe.

This blog will be about one of those various functions, and it will be about hosting static files on a server using NGINX.

Step 1: Editing the NGINX Config File

First of all, we'll have to edit the NGINX config file to add the directory, which will serve static content. Open the NGINX config file using the command:

sudo vi /etc/nginx/nginx.conf   # OR /etc/nginx/sites-enabled

Step 2: Updating the Location Block

Once you have opened the file using the vi editor, create a new location block in the server block.

server {
   server_name <>;
   location / {
     ...
   }

   location /files/ {
      root /var/www;
   }
}

In the above code snippet, we have added a new location block for the /files path and updated the root directive to point at /var/www. Now let's create an empty directory named /files on the above location.

Note: As we use the root directive in the location block, NGINX will add the route name to all paths. For example, if you request any file, NGINX will look it in the /var/www/files directory.

cd /var/www && mkdir files

Change the directory and create any file for testing purposes.

cd files
sudo touch hello.txt  # Add some random text too

Step 3: Restart the NGINX

Restart the NGINX server using the following command:

sudo service nginx restart

Test the NGINX configuration using sudo nginx -t to make sure there are no errors in the file.

Accessing the Static Files 🚀

To access the files, you can simply visit the server URL with the route that is mentioned in the location block (/files)

curl <<Server_URL>>/files/<<file_name>>

If you liked this post or found it interesting, give it a thumbs-up 👍

Thank you for reading! 💯

NodeJS is a great framework, and I keep using it for my projects. But I don't like installing the dependencies, writing the same code, and making the MVC directory structure again & again, which is why I created ServerGen, which helps you set up a NodeJS project within seconds.

What is Currently Supported?

ServerGen currently supports the following features:

• MVC Directory Structure ( Along with .gitignore file )
• Multiple View Engine ( Pug, EJS, HBS )
• Docker Support
• Express/Node Server Boilerplate
• Mongoose Boilerplate for MongoDB

What's Yet to Come?

• Swagger Documentation
• Passport Authentication
• Sequalize ORM for MySQL & PostgreSQL

How to use it?

To use ServerGen, make sure you have NodeJS installed on your system. Install ServerGen by using the command npm i servergen

Liked the project? Do give it a ⭐ on GitHub!

Thank you for reading! 🚀

Why Do You Need SSH Keys?

With the help of SSH keys, a developer can connect to a remote server using a secure network connection. SSH-keys also permits the developer to access their remote repositories without being asked to enter user names or passwords every time.

Step 1: Generating SSH Keys

You can quickly generate SSH Keys on your server using ssh-keygen by using the following command.

ssh-keygen -t rsa -c "first key"

After using this command, you'll be prompted to enter the output file location and the name. SSH keys are usually stored in the .ssh directory. Feel free to use any location and name of your choice.

Let's use this dummy location for example: ~/.ssh/key1

Here key1 is the name for SSH keys. Once done, two files (Private and Public Key) will be saved in the output directory.

Use the same steps to generate one more SSH Key and name it key2

Step 2: Adding SSH Keys to GitHub Repositories

After setting up SSH Keys, add the Public Key to the GitHub Repository. To add the SSH key in the GitHub Repo, Navigate to Repository < Setting < Deploy Keys.

Add both the keys to two different repositories (Public or Private).

Step 3: Setting up SSH Config

Now it's time to add SSH Keys in the SSH Config File on the server. This allows SSH to identify which key to use for the host.

Let's use the vi editor to edit the SSH Config (~/.ssh/config) file. Open the file using vi ~/.ssh/config and paste the following in the file.

Host private-repo-1
HostName github.com
User git
IdentityFile ~/.ssh/key1

Host private-repo-2
HostName github.com
User git
IdentityFile ~/.ssh/key2

Here Host represents the Repository's name, and IdentityFile means the file's location.

Step 4: Clone the Repository

That's all you need to do. Now to clone the repo, use the following command.

git clone <Host>:<Username-Org_Name>/<Repository_Name>

For example, I have a private repository with the name hashnode, and in the SSH config file (Step 3), I've set Host to hashnode, so the command will be:

git clone hashnode:myusername/hashnode

And that's just it!

I hope you found a solution to the problem you were looking for. If you have any queries regarding this topic, then please comment below. We will be happy to help you.