Forem: Hafiq Iqmal

I Built a Claude Code Slash Command for OWASP Top 10:2025, NIST CSF 2.0 and 850+ Security Checks

Hafiq Iqmal — Mon, 02 Mar 2026 01:33:51 +0000

Security audits should happen on every project before every major release. In practice, they happen whenever someone puts it in the budget, which is usually once a year if the project is lucky.

I built claude-security-audit to close that gap. It is a Claude Code slash command that runs a comprehensive white-box and gray-box security audit on any project, maps every finding to the compliance frameworks your clients and auditors care about and saves the report to your project root.

One command. No setup per project. No external service.

What It Is

A Claude Code slash command (/security-audit) that:

Reads your entire codebase (or just the diff from a PR)
Runs 850+ security checks across 18 attack categories
Detects your framework and loads tailored checklists
Maps every finding to OWASP Top 10:2025, CWE, NIST CSF 2.0 and more
Outputs a structured report to ./security-audit-report.md

GitHub: https://github.com/afiqiqmal/claude-security-audit

Install

curl -fsSL https://raw.githubusercontent.com/afiqiqmal/claude-security-audit/main/install.sh | bash

This installs the slash command globally at ~/.claude/commands/security-audit.md and the reference files at ~/.claude/security-audit-references/. Available in every project from that point forward.

For per-project install only:

cp -r .claude/commands/security-audit.md /path/to/your-project/.claude/commands/

Then use /project:security-audit inside that project.

Usage

# Full audit: white-box + gray-box + hotspots + code smells
/security-audit

# Quick scan: CRITICAL and HIGH only, no gray-box
/security-audit quick

# Diff mode: scan only changed files (good for PR reviews)
/security-audit diff
/security-audit diff:main
/security-audit diff:develop

# Focused deep dives
/security-audit focus:auth     # Auth and authorization
/security-audit focus:api      # API security and input validation
/security-audit focus:config   # Config, supply chain, infrastructure

# Run individual phases
/security-audit phase:1        # Reconnaissance only
/security-audit phase:2        # White-box analysis only
/security-audit phase:3        # Gray-box testing only
/security-audit phase:4        # Security hotspots only
/security-audit phase:5        # Code smells only

# Include remediation code blocks (off by default)
/security-audit --fix
/security-audit quick --fix
/security-audit diff:main --fix

# Lite mode: reduces token usage significantly
/security-audit --lite         # OWASP + CWE + NIST only
/security-audit quick --lite   # Cheapest useful scan
/security-audit diff:main --lite --fix

Frameworks Covered

Every finding is tagged to one or more of these:

Framework	Version
OWASP Top 10	2025
CWE	4.x
NIST CSF	2.0
SANS/CWE Top 25	2024
OWASP ASVS	4.0
PCI DSS	4.0
MITRE ATT&CK	v15
SOC 2	2017
ISO 27001	2022

OWASP Top 10:2025 Coverage

The audit explicitly tests all ten 2025 categories. Two of them are new:

#	Category	OWASP ID	Note
1	Broken Access Control	A01:2025	Now includes SSRF
2	Security Misconfiguration	A02:2025	Moved up from #5
3	Software Supply Chain Failures	A03:2025	NEW - expands "Vulnerable Components"
4	Cryptographic Failures	A04:2025	Moved from #2
5	Injection	A05:2025	Moved from #3
6	Insecure Design	A06:2025	Moved from #4
7	Identification and Auth Failures	A07:2025	Unchanged
8	Software and Data Integrity Failures	A08:2025	Unchanged
9	Security Logging and Alerting Failures	A09:2025	Renamed, emphasis on alerting
10	Mishandling of Exceptional Conditions	A10:2025	NEW - fail-open logic, silent failures

Framework-Specific Checklists

Claude detects your framework and loads a tailored checklist alongside the base checks. Currently supported:

Laravel
Next.js
FastAPI
Express
Django
Rails
Spring Boot
ASP.NET Core
Go
Flask

For example, the Laravel checklist covers Eloquent mass assignment vectors, Laravel authorization bypass patterns, .env exposure, Sanctum and Passport token handling and queue job deserialization. Generic web checks miss these because they are framework-specific failure modes.

Gray-Box Testing

Beyond static analysis, the audit runs a gray-box phase that looks at your code the way a tester with partial knowledge would:

Area	What It Tests
Role-Based Access	Can lower-privilege roles reach higher-privilege endpoints?
API Probing	Verb tampering, undocumented params, over-fetching, mass assignment
Credential Boundaries	Expired tokens, revoked sessions, tenant isolation
Partial Knowledge	Hidden endpoints from routes, IDOR via migration schema
Rate Limit Verification	Is rate limiting actually enforced or just documented?
Error Differentials	Do your errors leak resource existence?

The error differential check is one worth calling out specifically. If your application returns "User not found" for a nonexistent user ID and "Access denied" for a valid ID that belongs to someone else, you have just given an attacker a user enumeration tool. The audit flags this even if the authentication logic itself is correct.

AI/LLM Security Checks

If your project includes AI or LLM features, the audit runs additional checks for:

Prompt injection vectors
Output sanitization before rendering
RAG poisoning paths
Tool calling permission scopes
Cost monitoring and DoS via large context inputs

This maps to A05:2025 and A01:2025. As more projects add AI features, these attack surfaces are becoming increasingly relevant.

Report Structure

The report at ./security-audit-report.md is organized for both technical and non-technical readers:

Executive Summary (finding counts, risk assessment)
OWASP Top 10:2025 Coverage Matrix
NIST CSF 2.0 Coverage Matrix
Critical and High Findings (with vulnerable code block)
Medium Findings
Low and Informational
Gray-Box Findings (role, endpoint, expected vs actual)
Security Hotspots (PR review guidance)
Code Smells (patterns that breed security bugs)
Recommendations Summary (grouped by OWASP)
Methodology

By default the report shows findings and descriptions. Append --fix to include copy-paste remediation code blocks. This is off by default because it adds roughly 50% to the output token count and is not always needed.

Token Usage

This is a token-intensive command. Be aware of this before running full audits on large codebases.

Mode	Estimated Total Tokens
`quick --lite`	~30-80K
`diff --lite`	~20-40K
`quick`	~50-100K
`focus:auth`	~40-75K
`diff`	~35-60K
`full --lite`	~75-170K
`full`	~90-190K
`full --fix`	~100-210K

Recommended workflow:

Use diff --lite for every PR review
Use quick --lite for regular development checks
Save full for pre-release audits or client deliveries

Custom Checks

Add your own security checklists to extend the built-in ones.

Folder	Scope
`~/.claude/security-audit-custom/`	Global - all projects
`.claude/security-audit-custom/`	Project-level only

Format your checks with OWASP and NIST tags:

## Internal API Standards [A01:2025, A05:2025 | PR.AA, PR.DS]

- [ ] All internal endpoints require service-to-service auth tokens
- [ ] Response bodies never include internal database IDs
- [ ] Deprecated endpoints return 410 Gone

A template file is installed at ~/.claude/security-audit-custom/custom-template.md during setup.

Both global and project-level custom checks run alongside the built-in checks. Project-level checks do not override global ones, they are merged.

Repository Structure

claude-security-audit/
├── .claude/
│   └── commands/
│       └── security-audit.md       # The /security-audit slash command
├── references/
│   ├── attack-vectors.md           # 850+ checks tagged to OWASP/NIST/CWE
│   ├── nist-csf-mapping.md         # OWASP 2025-to-NIST cross-reference
│   ├── compliance-mapping.md       # CWE, SANS, ASVS, PCI DSS, ATT&CK, SOC 2, ISO 27001
│   ├── custom-template.md          # Template for custom checks
│   └── frameworks/                 # Framework-specific checklists
│       ├── laravel.md
│       ├── nextjs.md
│       ├── fastapi.md
│       └── ...
├── security-audit-guidelines.md    # Severity ratings and conventions
├── install.sh                      # One-command installer
├── CLAUDE.md                       # Project context for Claude Code
└── README.md

What It Is Not

This is not a replacement for a proper penetration test done by human security researchers. A skilled pentester will find things a checklist-driven audit will not, because they bring creativity and adversarial thinking that goes beyond predefined checks.

What this replaces is the security check you were not doing at all. The code review that focused on feature correctness but skipped the security angle. The audit that was supposed to happen before the release and did not.

Running diff --lite on every PR is a realistic habit that costs almost nothing and catches the class of vulnerabilities that show up repeatedly in production incidents: missing authorization checks, unvalidated inputs, sensitive data in logs, rate limiting that exists in documentation but not in code.

GitHub: https://github.com/afiqiqmal/claude-security-audit

MIT licensed. Pull requests welcome, especially for additional framework-specific checklists.

If you build something on top of this or extend it for your stack, open a PR or drop an issue. The reference files are designed to be extended.

Preventing Duplicate Requests in Laravel: The AtomicLockMiddleware

Hafiq Iqmal — Mon, 21 Oct 2024 08:12:49 +0000

How to Handle Multiple Request Collisions and Keep Your Laravel App Running Smoothly??

If you ever developed a web app in Laravel, you must have faced one such problem which is rather common: handling of duplicate requests currently being processed. It's that trivial problem, but it may lead to data inconsistency, a failed transaction, or-what's worse-a poor user experience. Imagine your application handling some form submission twice. You'd end up with duplicate records or maybe even duplicated payments, which would be a huge headache both for you and your users.

For this, we need to ensure each request should be processed one at a time, especially when the action is sensitive, such as making any payment or updating something. One of the solutions is by using an atomic lock. In this post, I am going to walk you through how I implemented a simple middleware in Laravel to handle such scenarios. This middleware will allow processing of only one request from any particular user at one time for specific actions.

Let's take a closer look into how it works and why you might want to use it in your projects.

Why Should You Care About Duplicate Requests?

Before getting into the code, let's talk about why handling duplicate requests is important. It's easy to think of a web request as a one-time thing, but there are several scenarios where duplicate requests can sneak in, like:

Slow internet connections: Users might click the same button multiple times out of impatience.
Page reloads: If a user refreshes the page quickly after submitting a form, it might send the same request again.
Automated scripts or bots: These can sometimes trigger requests in a way you don't expect.

In these cases, Laravel could end up processing 2 (or more) identical requests at the same time. That's where the atomic lock middleware comes in.

The Middleware

The middleware is simple and its ensures only one request from a user is processed at a time. It works by locking the request URL with a unique key in Laravel's cache. If another request with the same URL comes in before the first one finishes, the middleware throws an error, preventing the duplicate request from being processed.

Here's the full code of the AtomicLockMiddleware:-

class AtomicLockMiddleware
{
    /**
     * Handle an incoming request.
     *
     * @param  Closure(\Illuminate\Http\Request): (\Symfony\Component\HttpFoundation\Response)  $next
     */
    public function handle(Request $request, Closure $next, $prefix = null): Response
    {
        // Ensure that no duplicate request is being processed
        $this->ensureSingleRequest($request);

        // Proceed with the original request
        $response = $next($request);

        // Release the lock after the request is processed
        $this->releaseSingleRequest($request);

        return $response;
    }

    /**
     * Generate a unique key for the request.
     */
    public function requestKey(Request $request): string
    {
        return 'atomic_lock_middleware_' . $this->suffix($request);
    }

    /**
     * Handle request termination and release lock.
     */
    public function terminate(Request $request, Response $response): void
    {
        $this->releaseSingleRequest($request);
    }

    /**
     * Ensure that only one request is processed at a time by locking it.
     */
    private function ensureSingleRequest($request): void
    {
        // Check if the request is already locked
        if (Cache::has($this->requestKey($request))) {
            throw new HttpException(
                429, // HTTP status code for "Too Many Requests"
                __('Multiple duplicate request. Wait until the previous request is completed.')
            );
        }

        // Lock the request for 60 seconds
        Cache::put($this->requestKey($request), 'this signature has been consumed', 60);
    }

    /**
     * Release the lock after the request is processed.
     */
    private function releaseSingleRequest($request): void
    {
        Cache::forget($this->requestKey($request));
    }

    /**
     * Generate a unique prefix for the request based on URL and other parameters.
     */
    private function suffix(Request $request): string
    {
        $prefix = 'global';

        // You can add custom logic here to modify the suffix, such as user IDs or other identifiers

        return md5($request->url()) . '_' . $prefix;
    }
}

Breaking Down the Middleware

Let's dive into each part of the code to understand how this middleware works:

1. Handling Requests

The handle method is the core of this middleware. It ensures that duplicate requests are blocked until the original one is processed:

public function handle(Request $request, Closure $next, $prefix = null): Response
{
    $this->ensureSingleRequest($request);

    $response = $next($request);

    $this->releaseSingleRequest($request);

    return $response;
}

First, it calls the ensureSingleRequest method to check whether the request is already locked. If not, it processes the request normally. After the request is processed, it calls releaseSingleRequest to remove the lock from the cache.

2. Locking the Request

In the ensureSingleRequest method, we create a unique lock key for each request. If the request is already locked, the middleware throws an exception:

private function ensureSingleRequest($request): void
{
    if (Cache::has($this->requestKey($request))) {
        // Too Many Requests status code
        throw new HttpException(
            429,
            __('Multiple duplicate request. Wait until the previous request is completed.')
        );
    }

    Cache::put($this->requestKey($request), 'this signature has been consumed', 60);
}

The lock is set to expire after 60 seconds, meaning if a request takes longer than that to process, the lock will automatically expire and allow new requests.

3. Generating Unique Keys

To ensure that each request gets its own lock, we generate a unique key using the request URL and a prefix / suffix:

public function requestKey(Request $request): string
{
    return 'atomic_lock_middleware_' . $this->suffix($request);
}

This allows us to lock requests based on their URL, so two different URLs won't interfere with each other.

4. Releasing the Lock

Once the request is fully processed, we remove the lock from the cache, allowing new requests to be made:

private function releaseSingleRequest($request): void
{
    Cache::forget($this->requestKey($request));
}

This keeps the system clean and ensures that the lock isn't held unnecessarily after the request is done.

How to Use the Middleware

To use this middleware, first, register it in your Kernel.php file:

Laravel 10

protected $routeMiddleware = [
    // Other middleware...
    ...
    'atomic.lock' => \App\Http\Middleware\AtomicLockMiddleware::class,
    ...
];

Laravel 11

return Application::configure(basePath: dirname(__DIR__))
    ....
    ->withMiddleware(function (Middleware $middleware): void {
        .....

        $middleware->alias([
            ...
            'atomic.lock' => \App\Http\Middleware\AtomicLockMiddleware::class,
            ...
        ]);
    })
    ....

You can then apply it to specific routes or controllers:

Route::post('/approve-order', [OrderApprovalController::class, 'submit'])->middleware('atomic.lock');

This will ensure that only one request is processed at a time for the form submission.

Why You Should Use This Middleware

The AtomicLockMiddleware provides several benefits for your Laravel application:

Prevents double submissions: Avoid issues like duplicated form submissions, which can create duplicate records or even duplicate payments.
Ensures atomicity: Actions are guaranteed to only happen once at a time, ensuring data consistency.
Improves user experience: Users are prevented from accidentally submitting forms multiple times, which could otherwise cause confusion or errors.

This simple middleware adds a layer of protection against unwanted duplicate requests, helping your application run more smoothly.

Customising the Middleware

You can easily extend this middleware to fit your needs. Here are a few ideas:

Add user-specific locks: You could modify the prefix method to include the user's ID in the request key. This would allow each user to have their own lock for requests.
Custom lock expiration times: Depending on the type of request, you may want to adjust the expiration time of the lock. For example, you might set longer expiration times for actions that typically take more time to complete.

Conclusion

Basically, anything significant or sensitive that any Laravel application does needs to be handled by duplicated requests. In this case, the atomic lock middleware keeps it off so that every request would go ahead accordingly in an orderly, atomic fashion.

This little middleware can save you from duplicte form submissions, or any actions which written into your database, and so on, with just some lines of code. Put this lock on your routes for everything from the most simple app up to the most complex API.

Feel free to play around with it in your Laravel projects and understand how it simplifies the parallel requests handling for you!

This middleware offers a straightforward solution to a common problem, helping you ensure that no request gets processed twice unintentionally. By keeping things simple and atomic, your app will provide a more seamless experience for users and help you avoid messy data issues.

Thank you for reading! Don’t forget to subscribe to stay informed about the latest updates in system design. Happy designing!

If you found this article insightful and want to stay updated with more content on system design and technology trends, be sure to follow me on :-

Twitter: https://twitter.com/hafiqdotcom
LinkedIn: https://www.linkedin.com/in/hafiq93
Buy Me Coffee: https://paypal.me/mhi9388 /
https://buymeacoffee.com/mhitech
Medium: https://medium.com/@hafiqiqmal93

How to Install WKHTMLTOPDF with Patched QT on Ubuntu and CentOS 8

Hafiq Iqmal — Mon, 07 Oct 2024 01:58:40 +0000

Ever needed to convert HTML to PDF and found yourself tangled in a web of outdated software? You’re in the right place. In this guide, I’ll show you how to install wkhtmltopdf with the patched QT on Ubuntu and CentOS 8. Let’s make this painless and straightforward!

Why WKHTMLTOPDF with Patched QT?

First things first, why are we even bothering with this patched QT version? Well, the patched QT version of wkhtmltopdf offers better compatibility and more features compared to the stock version that you usually get from default repositories. If you need reliable PDF generation with advanced CSS and JavaScript support, this is the way to go.

Installing on Ubuntu LTS

Let’s start with Ubuntu. Here’s how you can get wkhtmltopdf up and running.

Step-by-Step Guide:

Update your package list and install xfonts-75dpi package since it is required by wkhtmltopdf:

# sudo apt-get update 
# sudo apt-get install -y wget xfonts-75dpi

Download the wkhtmltopdf package:

# cd ~
# wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6.1-2/wkhtmltox_0.12.6.1-2.jammy_amd64.deb

Install the downloaded package:

# sudo dpkg -i wkhtmltox_0.12.6.1-2.jammy_amd64.deb

Verify the installation:

# wkhtmltopdf --version

If everything went smoothly, you should see the version of WKHTMLTOPDF printed out. Now, you’re all set on Ubuntu!

Installing on CentOS 8

Now, let’s move on to CentOS 8. The steps are a bit different, but just as simple.

Step-by-Step Guide:

Install the WKHTMLTOPDF package directly:

# sudo dnf install -y https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6.1-3/wkhtmltox-0.12.6.1-3.almalinux9.$(uname -m).rpm

Verify the installation:

# wkhtmltopdf --version

That’s it! Your CentOS 8 system should now have wkhtmltopdf installed and ready to go.

Wrapping Up!

There you have it — a quick and easy way to install wkhtmltopdf with the patched QT on both Ubuntu and CentOS 8. Whether you’re converting reports, invoices or any other HTML content to PDF, this setup will have you covered.

Remember, keeping your tools up-to-date and using the right versions can save you a lot of headaches down the line. Happy converting!

If you found this guide helpful, share it with your friends and colleagues. Let’s make the web to PDF conversion process a breeze for everyone!

Additional Tips

Always check for the latest releases on the official WKHTMLTOPDF GitHub page.
For large scale deployments, consider automating the installation process with scripts or configuration management tools.

Thanks for reading! If you have any questions or run into any issues, drop a comment below. Let’s help each other out!

AWS Session Manager vs SSH

Hafiq Iqmal — Mon, 07 Oct 2024 01:39:36 +0000

A Comparison between SSM vs SSH

When dealing with the management of server access, there are 2 tools that frequently pop up: AWS Session Manager and SSH. Both have unique benefits and a few downsides. Understanding these should help you decide which is best for your needs.

In this post, we are going to explore the features, benefits, and limitations of each method and dive deep into their security aspects. Also, I'll share why I lean towards SSH over Session Manager.

What is AWS Session Manager?

AWS Session Manager, part of AWS Systems Manager, provides a way to access EC2 instances without needing to open inbound ports or manage SSH keys. It’s integrated into the AWS ecosystem, offering a way to connect directly via the AWS Management Console, CLI or SDKs.

Advantages of AWS Session Manager

No Need for Open Ports: You don’t need to expose inbound ports to your instances, which reduces the risk of external attacks.
Integrated with IAM: Uses AWS Identity and Access Management (IAM) to control access, simplifying permission management and providing detailed access logs.
Logging: Integration with AWS CloudTrail and Amazon CloudWatch offers detailed session logs, useful for auditing and troubleshooting.
No SSH Keys: Eliminates the need to manage and rotate SSH keys, which can be a security concern.
Cross-Platform: Works with both Linux and Windows instances, making it a flexible choice for diverse environments.

Disadvantages of AWS Session Manager

AWS Dependency: You need to be within the AWS ecosystem to use Session Manager. It’s not an option if you’re not using AWS services.
Learning Curve: Transitioning from SSH to Session Manager involves learning new tools and processes, which might be a bit challenging.
Connectivity Required: Session Manager requires network access to AWS, which can be a limitation if connectivity is unreliable.

What is SSH?

SSH (Secure Shell) is a protocol that has been used for years to securely access remote machines. It’s a staple tool for many system administrators, providing a secure way to run commands and manage systems remotely.

Advantages of SSH

Widely Used and Tested: SSH is a mature tool with broad support. It’s a reliable choice with extensive documentation and community support.
Direct Control: SSH provides a straightforward, direct connection to your server, which many find intuitive and easy to use.
Offline Access: As long as you have network access, you can use SSH without relying on a specific cloud provider.
Customisable: SSH offers extensive configuration options, making it adaptable to various environments and security requirements.

Disadvantages of SSH

Port Exposure: SSH typically requires opening port 22, which can be a security risk if not properly managed.
Key Management: Managing SSH keys can be a hassle and lost or stolen keys can lead to security breaches.
Logging and Monitoring: While possible, setting up logging and monitoring for SSH sessions can be more complex than with AWS Session Manager.
Firewall Rules: SSH access might be restricted by firewall rules, potentially complicating connectivity.

Security Comparison

AWS Session Manager Security

No Inbound Ports: Session Manager doesn’t require open inbound ports, reducing potential attack vectors.
IAM Integration: Access control is managed through IAM policies, making permissions easier to handle.
Session Logging: Detailed logs are automatically recorded, which helps with auditing and troubleshooting.
End-to-End Encryption: Communication is encrypted, safeguarding data during transmission.

SSH Security

Port Exposure: SSH’s need for an open port can be a vulnerability. It’s crucial to use best practices like changing default ports and implementing fail2ban to mitigate risks.
Key Management: Effective key management is essential to avoid security issues. Compromised keys can lead to unauthorized access.
Additional Tools Required: To enhance security, additional measures like multi-factor authentication (MFA) or using a bastion host may be necessary.

Why I Prefer SSH Over AWS Session Manager

While AWS Session Manager offers several benefits, particularly in environments where AWS is the primary platform, I personally prefer SSH for a few reasons related to my setup and preferences.

Site-to-Site VPN

We can use a site-to-site VPN to securely connect on-premises network with remote networks. This setup allows me to manage servers across different environments, not limited to AWS. SSH fits seamlessly into this architecture because it can operate independently of the cloud provider, giving me more flexibility.

Bastion Host

I also use a bastion host to manage access to my internal servers. SSH works well with this approach, allowing me to securely tunnel connections through the bastion host. This adds an extra layer of security and control, which I find valuable. With SSH, I can easily configure and manage these tunnels to meet my specific needs.

BUT i would say that you need to carefully configure your security group to open only required port and specific sources.

Portability and Third-Party Tools 🚀

One of the big advantages of SSH is the ease of using third-party tools like Termius. These tools provide a user-friendly interface for managing SSH connections and can be used on various devices, including mobile phones and laptops.

The portability is crucial for me, as it allows me to access and manage my servers from almost anywhere, whether I’m on the go or working from a different location. Tool like Termius make SSH connections more accessible and convenient, offering a seamless experience across different devices.

On the other hand, AWS Session Manager requires a direct connection to AWS and is not integrated as seamlessly as in my current VPN and bastion host configuration. Again, while Session Manager has great functionality within the AWS ecosystem, portability and integration with third-party tools I use in managing my SSHs are not as effective compared to this solution. And that makes SSH far more versatile and accessible when it comes to meeting my needs.

Summaries

Both AWS Session Manager and SSH is actually has their own pros and cons based on your needs. AWS Session Manager simplifies access management within the AWS environment and enhances security with its integrated logging and IAM features. However, it requires a reliance on AWS and may not fit every network setup. SSH, on the other hand, offers flexibility and is well-suited for environments.

For me, the best tool for you, its depend on your specific setup, security requirements and personal preferences. 🤘

Thank you for reading! Don't forget to subscribe to stay informed about the latest updates in system design and technology. Happy Crafting!

If you found this article insightful and want to stay updated with more content on system design and technology trends, be sure to follow me on :-
Twitter: https://twitter.com/hafiqdotcom
LinkedIn: https://www.linkedin.com/in/hafiq93
Buy Me Coffee: https://paypal.me/mhi9388 /
https://buymeacoffee.com/mhitech
Medium: https://medium.com/@hafiqiqmal93

Choosing the Right Primary Key for the Database

Hafiq Iqmal — Mon, 07 Oct 2024 01:15:51 +0000

ULID vs UUID vs Auto Increment??

Primary keys play a critical role in database management systems, serving as a unique identifier for each record in a table. They enable efficient retrieval, updating and deletion of data and help maintain data integrity by ensuring that no duplicate records are present. When designing a database schema, one of the most important decisions is selecting the right primary key type, which can significantly impact performance, scalability and ease of use.

This article will explore the pros and cons of three popular primary key types:- Universally Unique Identifier (UUID), Universally Unique Lexicographically Sortable Identifier (ULID) and auto-incrementing integers. We will discuss the properties and characteristics of each, along with examples to help you make an informed decision when choosing the right primary key for your database.

Universally Unique Identifier (UUID)

A UUID is a 128-bit number that is designed to be globally unique, meaning that the probability of generating the same UUID twice is astronomically low. They are represented as a string of 36 characters, including dashes and can be generated independently without the need for a central authority. There are various versions of UUIDs, but Version 4, which relies on random numbers, is the most commonly used. The format of a UUID is as follows:

XXXXXXXX-XXXX-MXXX-NXXX-XXXXXXXXXXXX

Where x is a hexadecimal digit (0-9, a-f) and M and N represent specific bits with predefined meanings. For example, a UUID might look like:

123e4567-e89b-12d3-a456–426614174000

In a database, a UUID primary key might appear in a table like this:

Benefit of UUIDs

Global uniqueness: UUIDs provide an extremely low risk of collision, making them suitable for distributed systems or databases where multiple clients may be generating IDs simultaneously.
No central authority needed: UUIDs can be generated independently on each client without the need for coordination, making them suitable for decentralized systems.
Easy to merge data: When combining data from different databases, UUIDs eliminate the need to worry about conflicting primary key values.

Drawback of UUIDs

Size: UUIDs are larger than auto-incrementing integers, occupying 16 bytes of storage as opposed to 4 bytes for a typical integer. This can lead to increased storage and indexing costs, as well as decreased performance when querying or joining tables.
Not human-readable: UUIDs are difficult to read, remember and communicate verbally, making them less user-friendly for developers and support teams.
Unordered: UUIDs are not generated in a sequential manner, which can lead to fragmentation and decreased performance when inserting data into a table with a clustered index.

Universally Unique Lexicographically Sortable Identifier (ULID)

ULIDs are another type of unique identifier that combines the advantages of UUIDs with the added benefit of being sortable. They are 128-bit numbers, represented as a 26-character string composed of upper-case letters and digits. The first half of the ULID represents a timestamp, while the second half is a randomly generated value. The format of a ULID is as follows:

01ARZ3NDEKTSV4RRFFQ69G5FAV

In a database, a ULID primary key might appear in a table like this:

Benefit of ULIDs

Global uniqueness: Like UUIDs, ULIDs provide a very low risk of collision, making them suitable for distributed systems.
Lexicographically sortable: ULIDs are generated in a way that ensures they are sortable by their creation time, making them more efficient for querying and inserting into tables with clustered indexes.
No central authority needed: ULIDs can be generated independently on each client without the need for coordination, making them suitable for decentralized systems.
Human-readable: While not as easy to read as auto-incrementing integers, ULIDs are more human-readable than UUIDs due to their shorter length and character set.

Drawback of ULIDs

Size: ULIDs occupy 16 bytes of storage, similar to UUIDs, which can lead to increased storage and indexing costs, as well as decreased performance when querying or joining tables.
Not as human-readable as integers: Although more readable than UUIDs, ULIDs are still not as user-friendly as auto-incrementing integers, which can pose challenges for developers and support teams.

Auto-Incrementing Integers

Auto-incrementing integers are the most common type of primary key used in databases. As the name suggests, auto-incrementing integers are sequential numbers that automatically increase by a specified increment (usually 1) for each new record added to the table. An example of an auto-incrementing primary key sequence might be:

1, 2, 3, 4, 5, ...

In a database, an auto-incrementing integer primary key might appear in a table like this:

Benefit of Auto Increments:

Easy to understand: Auto-incrementing integers are human-readable and easy to communicate verbally, making them user-friendly for developers and support teams.
Smaller size: Auto-incrementing integers typically occupy 4 bytes of storage, which can lead to lower storage and indexing costs, as well as improved performance when querying or joining tables.
Ordered: Auto-incrementing integers are generated sequentially, which can improve performance when inserting data into tables with clustered indexes.

Drawback of Auto Increments:

Risk of collisions: In distributed systems or databases where multiple clients may be generating IDs simultaneously, there is a risk of conflicting primary key values.
Central authority needed: Auto-incrementing integers require coordination between clients or a central authority to ensure unique ID generation, which can be a challenge in decentralized systems.
Difficult to merge data: When combining data from different databases, auto-incrementing integers can lead to conflicting primary key values, making the merge process more complex.

Choosing the Right Primary Key

When deciding on the type of primary key to use for your database, it is essential to consider the specific requirements and constraints of your system. Here are some guidelines to help you choose the most suitable primary key based on your situation:

Centralized Systems: If you have a centralized system where a single authority manages ID generation, auto-incrementing integers are an excellent choice due to their simplicity, smaller size and human-readable format. They also provide better performance when working with clustered indexes.
Distributed Systems: For distributed systems, where multiple clients generate IDs simultaneously and there is no central authority, UUIDs or ULIDs are more appropriate. Both provide global uniqueness and can be generated independently by each client. ULIDs have the added advantage of being lexicographically sortable, which can improve query performance.
Data Merging: If your system requires frequent merging of data from different databases, UUIDs or ULIDs are the better choice, as they eliminate the need to resolve conflicting primary key values.
Performance: If performance is a top priority, consider using auto-incrementing integers or ULIDs. Auto-incrementing integers offer better storage and indexing efficiency, while ULIDs provide better performance when working with clustered indexes due to their sortable nature.

Handling Primary Keys in Data Analytics

When working with primary keys in data analytics, it is crucial to understand the characteristics of each primary key type and how they might impact your analyses. Here are some tips for handling different primary keys in data analytics:

Auto-Incrementing Integers: When using auto-incrementing integers as primary keys, ensure that your analysis takes into account the ordered nature of these keys. For instance, when analyzing trends or patterns over time, ensure that the data is correctly sorted based on the auto-incrementing integer.
UUIDs and ULIDs: In data analytics, UUIDs and ULIDs can be more challenging to work with due to their complexity and larger size. To facilitate analysis, consider creating additional indexes or using derived columns to sort or filter the data based on relevant attributes.
Data Aggregation: When aggregating data from multiple sources with different primary key types, consider standardizing the primary keys by converting them to a common type, such as UUIDs or ULIDs. This can simplify the data merging process and ensure consistent analysis across all sources.
Human Readability: When presenting data analytics results to stakeholders, consider using more human-readable identifiers, such as usernames or email addresses, instead of complex primary keys like UUIDs or ULIDs. This can make the results more accessible and understandable for non-technical audiences.

Conclusion

In conclusion, choosing the right primary key for your database is a critical decision that can have a lasting impact on the performance, scalability and overall success of your system. By carefully considering the specific requirements and constraints of your situation and engaging in thoughtful discussions with your team, you can make informed choices that will lay a strong foundation for your database design. Remember that the primary key type you choose will not only affect your system’s technical aspects but also the ease of use for developers, support teams and even the stakeholders who rely on the data for decision-making. So, take the time to understand the trade-offs and select the primary key that best meets the unique needs of your project.

Good database design is like a well-organized library, and primary keys are the Dewey Decimal System that keeps everything in order.

Article orginated from https://medium.com/geekculture/choosing-the-right-primary-key-for-the-database-326136eff4f4

If you found this article insightful and want to stay updated on technology trends, be sure to follow me on :-

Twitter: https://twitter.com/hafiqdotcom
LinkedIn: https://www.linkedin.com/in/hafiq93
BuyMeCoffee: https://paypal.me/mhi9388 / https://buymeacoffee.com/mhitech
Medium: https://medium.com/@hafiqiqmal93

Normalizing Fancy Text to Normal Text in Laravel

Hafiq Iqmal — Sun, 06 Oct 2024 09:22:24 +0000

Article originated from https://medium.com/@hafiqiqmal93/normalizing-fancy-text-to-normal-text-in-laravel-7d9ed56d5a78

Text input from users are not at all interesting. With the advent of Unicode in the smartphones, users now have the luxury (and sometimes the whimsy) to input text in a variety of styles and formats. From emojis to diacritics, ligatures to full-width characters, the range of “fancy text” can be extremely confusing or difficult to understand by the system. While visually appealing, these text variations pose a significant challenge for the system particularly in terms of data consistency, searchability, and user experience.

Here are the example of fancy text:-

𝘕𝘦𝘪𝘨𝘩𝘣𝘰𝘳 𝘮𝘢𝘬𝘦 𝘢 𝘯𝘦𝘸 𝘤𝘰𝘯𝘯𝘦𝘤𝘵𝘪𝘰𝘯 𝘶𝘯𝘥𝘦𝘳 𝘵𝘰 𝘰𝘶𝘳 𝘮𝘦𝘵𝘦𝘳 𝘢𝘯𝘥 𝘸𝘦 𝘥𝘪𝘴𝘤𝘰𝘷𝘦𝘳𝘦𝘥 𝘪𝘵 𝘣𝘦𝘤𝘢𝘶𝘴𝘦 𝘵𝘩𝘦𝘺 𝘴𝘸𝘪𝘵𝘤𝘩 𝘰𝘧𝘧 𝘵𝘩𝘦 𝘮𝘢𝘪𝘯 𝘮𝘦𝘵𝘦𝘳 𝘢𝘯𝘥 𝘪 𝘨𝘰 𝘥𝘰𝘸𝘯 𝘵𝘰 𝘤𝘩𝘦𝘤𝘬 𝘢𝘯𝘥 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘨𝘰 𝘥𝘰𝘸𝘯 𝘢𝘭𝘴𝘰 𝘵𝘰 𝘰𝘧𝘧 𝘪𝘵 𝘢𝘨𝘢𝘪𝘯 𝘢𝘯𝘥 𝘤𝘭𝘢𝘪𝘮𝘪𝘯𝘨 𝘵𝘩𝘢𝘵𝘪𝘴 𝘵𝘩𝘦𝘪𝘳 𝘮𝘦𝘵𝘦𝘳, 𝘪𝘵 𝘰𝘯𝘭𝘺 𝘩𝘢𝘱𝘱𝘦𝘯𝘴 𝘵𝘩𝘪𝘴 𝘸𝘦𝘦𝘬..𝘯𝘦𝘷𝘸𝘳 𝘪𝘯 𝘵𝘩𝘦 𝘱𝘢𝘴𝘵. 𝘛𝘩𝘦 𝘺𝘦𝘭𝘭𝘰𝘸 𝘩𝘰𝘴𝘦 𝘪𝘴 𝘫𝘶𝘴𝘵 𝘯𝘦𝘸𝘭𝘺 𝘤𝘰𝘯𝘯𝘦𝘤𝘵𝘦𝘥

Looks like italic character but its not italic. Its actually belongs to Mathematical Alphanumeric Symbols.

Problem in PHP 💥

Well, a very obvious problem is that PHP can't JSON encode deformed UTF-8 characters upon receipt. In the modern way of doing web development, where APIs and frontend frameworks use JSON to transport data, this is a problem. If treated wrong, such deformed characters will result in data corruption, crash, or angry users.

Our goal is simple :- came out with the solution that will convert every fancy text into normal readable text.

PHP Normalizer

Normalization forms are pivotal to understanding the normalization process. They cater to different linguistic and technical needs. For instance, the NFC form combines characters into their composed forms, whereas NFD does the opposite, decomposing composed characters into their constituent parts. NFKC and NFKD forms go further, considering compatibility characters - folding variations of characters into a canonical form. These forms ensure that text comparison, searching, and storage are consistent and reliable.

The Solution 🚀

The code snippet provided is a sterling example of PHP approach to solving complex problems with simplicity and efficiency. Let's dissect this solution, understand its components, and see how it seamlessly integrates :-

public static function normalizeText($text): ?string
{
    if (!$text) {
        return null;
    }
    $intl = [
        \Normalizer::FORM_C,
        \Normalizer::FORM_D,
        \Normalizer::NFD,
        \Normalizer::FORM_KC,
        \Normalizer::NFKC,
        \Normalizer::FORM_KC_CF,
        \Normalizer::FORM_KD,
        \Normalizer::NFKD,
        \Normalizer::NFC,
        \Normalizer::NFKC_CF,
    ];
    foreach ($intl as $form) {
        if (!\Normalizer::isNormalized($text, $form)) {
            return \Normalizer::normalize($text, $form);
        }
    }
    return $text;
}

The usage is simple:-

$normalText = Utils::normalizeText($YOUR_FANCY_STRING)

You may register inside helper function to make it easier to use. For example:-

if ( ! function_exists('normalize_text')) {
    function normalize_text(string $text): string
    {
         return Utils::normalizeText($text)
    }
}

// USAGE
$normalText = normalize_text($YOUR_FANCY_STRING)

At its core, this function leverages PHP's **Normalizer** class-a part of the Internationalization (intl) extension-to address the normalization. The **Normalizer** class offers several normalization forms, each tailored to different normalization needs. This function iterates through these forms, checking if the text is already normalized in a given form using **isNormalized** function. If not, it normalizes the text to that form and returns the normalized string.

Conclusion

While fancy text may add visual appeal to user input, it poses significant challenges for data processing and system interoperability. However, with the adoption of PHP's Normalizer class and the implementation of normalization forms, developers can overcome these challenges and ensure that their applications maintain data consistency and reliability in the face of diverse text inputs.

Do you have any experiences or challenges related to handling fancy text in your projects? How do you currently address such issues, and do you find PHP's Normalizer class useful in your workflow? Let's continue the conversation and share our insights to help each other navigate the complexities of modern web development. 🤜🏼

Blurry Image Detection in Laravel

Hafiq Iqmal — Sun, 06 Oct 2024 04:21:22 +0000

Article originated from https://medium.com/@hafiqiqmal93/blurry-image-detection-in-laravel-4c91168e00f1

Crucial aspect of user experience, storing blurry images is significantly detract from the quality of a website or application. This article delves into how you can detect and manage blurry images using Laravel with help of Python and OpenCV, ensuring the application’s media remains sharp and engaging.

The Challenge of Blurry Images

Blurry images are more than just a visual nuisance; they can undermine the professionalism of your website or app. In e-commerce, real estate listings, online galleries or any platform where image quality is paramount, ensuring clarity is essential. The challenge lies in detecting blurriness programmatically.

Laravel to the Rescue

Laravel can be paired with Python to create an effective solution for this problem. By leveraging Laravel’s file validation alongside a Python script utilizing OpenCV, developers can seamlessly integrate blur detection into their file upload processes.

Blurriness Detection Concept

The detection of blurry images involves analyzing the image’s sharpness. This is typically done using the Laplacian operator, a mathematical tool used in image processing. The Laplacian operator measures the rate at which pixel intensity changes, and a lower variance of the Laplacian indicates a blurrier image.

Implementing in Laravel

In Laravel, we can create a custom validation rule to check for image blurriness. This rule executes a Python script that uses the Laplacian operator to determine the sharpness of the image. Let’s break down the process:

Installation OpenCV Python:

Install PIP (Ubuntu) :

sudo apt install python3-pip

Install OpenCV using PIP

pip3 install opencv-python

You might want to consider to install under **www-data** user if your application runs under **www-data**. If Yes, follow below commands to install

sudo mkdir /var/www/.local
sudo mkdir /var/www/.cache
sudo chown www-data.www-data /var/www/.local
sudo chown www-data.www-data /var/www/.cache
sudo -H -u www-data pip3 install opencv-python

Create Python Script

import sys
import cv2

def get_image_laplacian_value(image_path):
    image = cv2.imread(image_path)
    gray_image = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
    return cv2.Laplacian(gray_image, cv2.CV_64F).var()

if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit(1)
    image_path = sys.argv[1]
    laplacian_value = get_image_laplacian_value(image_path)
    print(laplacian_value)

Create Laravel Rule:

class ImageBlurDetectionRule implements ValidationRule
{
    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
        if ( ! $value instanceof UploadedFile) {
            return;
        }
        // ignore if not image
        if ('' !== $value->getPath() && ! in_array($value->guessExtension(), ['jpg', 'jpeg', 'png', 'gif', 'bmp', 'svg', 'webp'])) {
            return;
        }
        // get real path for the file
        $path = $value->getRealPath();
        $command = escapeshellcmd(config('image.python_path') . " blur_detection.py '{$path}'");
        $result = Process::path(base_path('scripts'))->run($command);
        if ( ! $result->successful()) {
            return;
        }
        if (trim($result->output()) < 100) {
            $fail(__('Blur image are not accepted. Please make sure your :attribute image is clearly visible.'));
        }
    }
}

How It Works

The integration of Laravel with a Python script for blur detection works in a seamless manner, offering a sophisticated yet straightforward approach to ensuring image quality. Here’s how the process unfolds:

Image Upload

When a user uploads an image to the Laravel application, the custom validation rule (ImageBlurDetectionRule) is triggered.

Validation Rule Execution

This rule first checks if the uploaded file is indeed an image by verifying its extension. If the file is not an image, the process stops here.

Python Script Invocation

If the file is an image, the rule then calls a Python script, blur_detection.py. The image's path is passed to this script as a command-line argument.

Image Processing in Python:

The Python script uses OpenCV to handle the image analysis.
The script reads the image and converts it into grayscale. This simplification allows for more straightforward analysis without the complexity of color.
It then applies the Laplacian operator to the grayscale image. The Laplacian operator is a mathematical tool that highlights areas of rapid intensity change, which are typically edges in an image. Blurry images have fewer and less defined edges, resulting in a lower variance of the Laplacian.

Blurriness Measurement

The script calculates the variance of the Laplacian, which serves as a measure of the image’s sharpness. A lower variance indicates a blurrier image.

Result Evaluation:

The script outputs the Laplacian variance as a numerical value.
Back in Laravel, the validation rule captures this output and checks if the value falls below a predefined threshold. This threshold determines whether an image is considered sharp enough.

Validation Feedback

If the image is too blurry (ex: the Laplacian variance is below the threshold), the validation rule fails and the user receives a message indicating that the image is blurry and should be checked.

User Experience Enhancement

By preventing the upload of low-quality, blurry images, this solution enhances the overall user experience. Users are prompted to only upload clear, high-quality images, which maintains the visual standard of the application.

This process is highly customizable. Developers can adjust the threshold for blurriness according to the specific needs of their application. Note that, the threshold is based on your observation. For advance usage, may need ML to determine the threshold. Moreover, the integration of Python within Laravel allows for further expansion into more advanced image processing techniques, offering a flexible and robust solution for managing image quality.

Practical Application

Incorporating this functionality in your Laravel application enhances the user experience by preventing the upload of low-quality images. This is particularly useful in scenarios where image clarity is critical, such as online portfolios, product catalogs, or user profile pictures.

Customization and Flexibility

The threshold for blurriness can be adjusted according to specific needs. Additionally, the integration of Python within Laravel offers flexibility to incorporate more advanced image processing techniques if required.

Conclusion

The combination of Laravel and Python for detecting blurry images is a powerful solution. It not only ensures the visual quality of your application but also enhances the overall user experience. With this approach, developers can maintain high standards for media content, contributing to a more polished and professional online presence.

Have you tried implementing this solution in your Laravel project? Share your experiences and any insights you’ve gained in the comments below. Let’s continue to elevate the standards of web development together!

Laravel SoftDelete: Avoiding the Unique Constraint Problem

Hafiq Iqmal — Sun, 06 Oct 2024 04:01:22 +0000

This article originated from https://medium.com/@hafiqiqmal93/laravel-softdelete-avoiding-the-unique-constraint-problem-45381d9745a0

In case you’ve been using Laravel for a while, especially when projects involve data integrity, most likely you have already encountered the SoftDelete feature. Pretty useful because you can “delete” records without really taking them out of the database. What Laravel does is just add a deleted_at timestamp so it marks it as deleted, but remains in the system. That’s all well and good to retain historical data, but it does introduce one potentially sticky problem — what happens to unique constraints when you restore soft-deleted records?

This becomes a problem when you want to restore a record that already has, for instance, a unique email or username, in the database. Laravel will just throw an error and stop the proceedings. Fortunately, there’s an easy way of avoiding this problem in a very clean manner.

Let’s walk through a solution using a trait that will help you bypass the unique constraints when using SoftDelete in Laravel.

Understanding the Problem

Let’s take a basic example. Imagine you have a users table with an email field that must be unique:

Schema::create('users', function (Blueprint $table) {
    $table->string('email')->unique();
    $table->softDeletes();
});

If you soft delete a user with the email johncena@wwe.com and then later create a new user with the same email, Laravel will complain about the unique constraint on the email field, throwing an error. In the same situation, when you try to restore the deleted user, Laravel also will complain about the unique constraint on the email field and throwing an same error.

This becomes a headache, especially when dealing with large systems where record restoration is a common task.

To prevent this, we can temporarily alter the values of unique fields when a record is soft deleted and restore the original values when the record is brought back. This way, the database doesn’t trip over the unique constraint during soft deletes or restores.

The Solution: Using a Trait to Avoid Duplicate Constraints

A Laravel trait is a great way to encapsulate this functionality. Here’s a trait we can use to handle the problem:

<?php

trait AvoidDuplicateConstraintSoftDelete
{
    abstract public function getDuplicateAvoidColumns(): array;
    public static function bootAvoidDuplicateConstraintSoftDelete(): void
    {
        static::restoring(function ($model): void {
            if ($model->trashed()) {
                foreach ($model->getDuplicateAvoidColumns() as $column) {
                    // handle for Spatie Translatable library
                    if (method_exists($model, 'getTranslatableAttributes')) {
                        $translates = $model->getTranslatableAttributes();
                        if (in_array($column, $translates)) {
                            foreach ($translates as $translate) {
                                if ($translate === $column) {
                                    $values = $model->getTranslations($column);
                                    foreach ($values as $translation => $value) {
                                        $values[$translation] = (explode('--', $value)[1] ?? $value);
                                    }
                                    $model->setTranslations($column, $values);
                                    break;
                                }
                            }
                            continue;
                        }
                    }
                    if ($value = (explode('--', $model->{$column})[1] ?? null)) {
                        $model->{$column} = $value;
                    }
                }
            }
        });
        static::deleted(function ($model): void {
            foreach ($model->getDuplicateAvoidColumns() as $column) {
                // handle for Spatie Translatable library
                if (method_exists($model, 'getTranslatableAttributes')) {
                    $translates = $model->getTranslatableAttributes();
                    if (in_array($column, $translates)) {
                        foreach ($translates as $translate) {
                            if ($translate === $column) {
                                $values = $model->getTranslations($column);
                                foreach ($values as $translation => $value) {
                                    $values[$translation] = time() . '--' . $value;
                                }
                                $model->setTranslations($column, $values);
                                break;
                            }
                        }
                        continue;
                    }
                }
                $model->{$column} = time() . '--' . $model->{$column};
            }
            $model->save();
        });
    }
}

This trait does a couple of things:

On deletion, it appends a timestamp to the unique field, essentially making the field unique again without affecting the original value. This trick is useful for keeping unique constraints satisfied while the record is soft-deleted.
On restoration, it strips away the timestamp, restoring the original value of the unique field.

How It Works:

Unique Field Handling: Whenever a model with this trait is deleted, the trait takes care of appending a timestamp to the fields that you want to keep unique (example: email, username). This prevents conflicts if you try to add a new record with the same unique values.
Handling Translatable Fields: If your model uses the Spatie Translatable library, this trait is smart enough to handle multilingual fields as well. It looks for the translatable attributes, adjusts their values, and saves them with the timestamp trick.
Restoration: When you restore a soft-deleted record, the trait strips off the timestamp from the unique fields, returning the field to its original value.

Applying the Trait to Your Model

Here’s how you can apply this trait in your Laravel model:

class User extends Model
{
    use SoftDeletes, AvoidDuplicateConstraintSoftDelete;
    // Specify which columns should avoid the unique constraint issue
    public function getDuplicateAvoidColumns(): array
    {
        return ['email', 'username'];
    }
}

By adding the **AvoidDuplicateConstraintSoftDelete** trait to your model and specifying which columns need to avoid unique constraint conflicts (like email and username), you can easily prevent these issues.

Why This Approach Works?

What that means is that, in the event of a soft delete record, it would not cause a conflict with further operations because of some unique constraints. Or, in other words, this way you will be able to, by appending the timestamp to unique fields, render the record “hidden” for the database in terms of uniqueness but still recoverable when needed.

This is quite useful when you’re dealing with a large database and restoration of records is quite common. You won’t have to deal every time with the “duplicate entry” error whenever you bring a soft-deleted user or any other model.

Final Thoughts

The most useful thing in Laravel is SoftDelete, but sometimes it gives headaches while working with unique constraints. Here comes a simple, trait-based solution that will give an elegant way of avoiding the problem, just by temporary changes of unique fields on deletion and restore afterward. This way you will avoid frustrating mistakes and let your application work smoothly not breaking unique constraints in your database.

If any of your fields have been made multilingual or make use of libraries like Spatie’s Translatable, the above solution will work without problems in each of these cases. The SoftDeletes are meant to give you flexibility, not get in your way. With the above minor fix in place you’ll avoid most the pitfalls and keep your data tidy and your users happy.

By adding this trait to your models, you’ll be saving yourself time and headaches, especially if you’re dealing with large datasets where soft-deleting and restoring are frequent operations. Give it a try in your Laravel project, and you’ll see how smoothly it handles those tricky unique constraint problems!

Thank you for reading! Don’t forget to subscribe to stay informed about the latest updates in system design and e-commerce innovations. Happy designing!

If you found this article insightful and want to stay updated with more content on system design and technology trends, be sure to follow me on :-

Installing Supervisor On Amazon Linux 2023

Hafiq Iqmal — Sun, 06 Oct 2024 03:30:01 +0000

Original Article -> https://medium.com/aws-in-plain-english/installing-supervisor-on-amazon-linux-2023-697b65901457

Amazon Linux 2023 stands as a reliable choice for developers and system administrators. However, users may face a hiccup: Supervisor, is absent from the default RPM packages. This omission poses a challenge for efficiently managing and monitoring processes on Amazon Linux instances.

But fret not! This guide will walk you through the steps to effortlessly install Supervisor on Amazon Linux 2023 using Pip, ensuring smooth sailing for your process management needs.

Understanding the Challenge

AL2023 is RPM-based and includes components sourced from multiple versions of Fedora and other distributions, such as CentOS 9 Stream. The Amazon Linux kernel is sourced from the long-term support (LTS) releases directly from kernel.org, chosen independently from other distributions.

BUT, the absence of Supervisor (Refer Here) in the default package repository complicates matters for users reliant on its intuitive process management capabilities. Supervisor streamlines the task of controlling and monitoring processes, making it indispensable for system administrators and developers. Without it, overseeing complex applications and services becomes significantly more cumbersome.

Installing Supervisor on Amazon Linux 2023 with Pip:

Step 1: Prerequisites:

Before proceeding, ensure your instance has Python and Pip installed. You can verify their presence by running the following commands:

sudo dnf install python3 python3-pip

Step 2: Install Supervisor

Once Python and Pip are available, installing Supervisor becomes a breeze. Execute the following command to install Supervisor using Pip:

sudo pip install supervisor

Step 3: Generate Supervisor Configuration File

After installation, generate the default configuration file for Supervisor using the following command:

echo_supervisord_conf > /etc/supervisor/supervisord.conf

Step 4: Customize Configuration (Optional)

Feel free to customize the generated configuration file according to your specific requirements. You can edit /etc/supervisor/supervisord.conf using your preferred text editor.

I would suggest to create the conf.d folder inside the /etc/supervisor/ and modify the supervisord.conf to include the folders.

[include]
files = /etc/supervisor/conf.d/*.conf

Step 5: Start Supervisor Service

With Supervisor installed and configured, start the Supervisor service using the following command:

sudo supervisord -c /etc/supervisor/supervisord.conf

We might want to auto start this supervisor service once reboot or on start server. Create a service called “supervisord.service”

sudo vim /usr/lib/systemd/system/supervisord.service

and paste this script inside the file

[Unit]
Description=Process Monitoring and Control Daemon
After=rc-local.service nss-user-lookup.target

[Service]
Type=forking
ExecStart=/usr/local/bin/supervisord -c /etc/supervisor/supervisord.conf

[Install]
WantedBy=multi-user.target

You might need to reload the daemon as it new script is created

sudo systemctl daemon-reload

Step 6: Verify Installation

Confirm that Supervisor is up and running by checking its status:

sudo systemctl enable supervisord
sudo systemctl start supervisord
sudo systemctl status supervisord

Now you are good to go to create your own application supervisor config.

Conclusion

While Supervisor may not come pre-packaged with Amazon Linux 2023, installing it via Pip is a simple process that enhances your ability to manage processes effectively. By following the steps outlined in this guide, you can equip your Amazon Linux instances with Supervisor, empowering you to streamline process control and monitoring. Whether you’re overseeing intricate applications or managing critical services, Supervisor on Amazon Linux 2023 ensures smooth operation in the ever-evolving landscape of cloud computing.

Thank you for reading! Don’t forget to subscribe to stay informed about the latest updates in system design and e-commerce innovations. Happy designing!

If you found this article insightful and want to stay updated with more content on system design and technology trends, be sure to follow me on :-

Laravel Jetstream database session with multiple user table

Hafiq Iqmal — Mon, 11 Oct 2021 07:10:19 +0000

If you are using Jetsream, you might notice that there is a feature called Browser Sessions. This feature allow the user to view the browser sessions associated with their account. Plus, the user may revoke other browser sessions other than the one being used by the device they are currently using.

So, what is the problem?

The problem is that, when multiple guard authentication happen, session is stored only based on user primary key in user_id column. Based on component Jetstream LogoutOtherBrowserSessionsForm , the logic is where if there are 2 guard with same id is stored and one of the guard user click revoke session in Jetstream, both of the session would be deleted. It would be nice if the session table accept polymorphic relationship

How about the solution?

So, i decide to came out a solution

Create a custom session driver to override database session used by Laravel default database session manager
Alter current session to accept polymorphic relation
Implement polymorphic relation to LogoutOtherBrowserSessionsForm

Lets get started

If you are not using database driver for session, this article might not for you.

Create a custom session driver

So, let’s start by looking at \Illuminate\Session\DatabaseSessionHandler. You will notice that there is method addUserInformation to add user_id to the payload of session table. This is where we can extend this class and override this method to add our polymorphic relation.

Create a class name as DatabaseSessionHandler extend from \Illuminate\Session\DatabaseSessionHandler. Override addUserInformation and add to the payload with morph column. We might want to keep the parent method to keep the old session driver. Here the full snippet :-



<?php

class DatabaseSessionHandler extends \Illuminate\Session\DatabaseSessionHandler
{
    protected function addUserInformation(&$payload)
    {
        if ($this->container->bound(Guard::class)) {
            $payload['authenticable_id'] = $this->userId();
            $payload['authenticable_type'] = $this->container->make(Guard::class)->user()?->getMorphClass();
        }

        return parent::addUserInformation($payload);
    }
}

Done extending the DatabaseSessionHandler. Now, registering the DatabaseSessionHandler is done through a provider, which is set up the same way as the built-in \Illuminate\Session\DatabaseSessionHandler. Im using name “database2” as a driver name. You may freely change the driver name as you wish



<?php


class SessionServiceProvider extends ServiceProvider
{
    public function boot()
    {
        \Session::extend('database2', function ($app) {
            return new DatabaseSessionHandler(
                $app['db']->connection($app['config']['session.connection']), 
                $app['config']['session.table'], 
                $app['config']['session.lifetime'], 
                $app
            );
        });
    }
}

Now, the custom session database driver is now registered.

Create/Alter Session Migration Table

Lets start with by publishing a migration for session table if not exist



> php artisan session:table

The content of the session would look like this



Schema::create('sessions', function (Blueprint $table) {
    $table->string('id')->primary();
    $table->foreignId('user_id')->nullable()->index();
    $table->string('ip_address', 45)->nullable();
    $table->text('user_agent')->nullable();
    $table->text('payload');
    $table->integer('last_activity')->index();
});

You would notice this migration doesn’t come with polymorphic relationship. This is where we need to alter the table. Add morphs relation named it as authenticable



Schema::create('sessions', function (Blueprint $table) {
    $table->string('id')->primary();
    $table->nullableMorphs('authenticable'); // add this

    $table->foreignId('user_id')->nullable()->index();

    $table->string('ip_address', 45)->nullable();
    $table->text('user_agent')->nullable();
    $table->text('payload');
    $table->integer('last_activity')->index();
});

I would suggest not to remove the user_id column because we shared session table. In case, you want to revert back to original session database driver, it wont be a problem. Unless you specify another table for new session driver.

In case you already have session table, you might want to alter the table. Just create another migration to alter the table



> php artisan make:migration alter_session_table --table=sessions

You might need to delete all the existing session. Just add DB truncate before migration happen. You may follow like below :-



<?php

class AlterSessionTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        DB::table('sessions')->truncate();

        Schema::table('sessions', function(Blueprint $table) {
            $table->after('id', function (Blueprint $table ){
                $table->nullableMorphs('authenticable');
            });
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('sessions', function(Blueprint $table) {
            $table->dropMorphs('authenticable');
        });
    }
}

Change session driver in env file

At this point, you can change session default driver to your new custom session driver.



...
QUEUE_CONNECTION=
SESSION_DRIVER=database2
...

You may try to login and you will notice in your session driver table, the morph column started to filled in.

Customize LogoutOtherBrowserSessionsForm (Jetstream)

Let’s take a look at Jetstream LogoutOtherBrowserSessionsForm class.

The red line shows the logic used to display and revoke session in the browser session feature. As mention, the query is not handling multi table or multi guard which cause see session of others. Let’s create new livewire component and extend this class.



> php artisan make:livewire LogoutOtherBrowserSessionsForm

Now alter the file and extend to Jetstream class



<?php

use Laravel\Jetstream\Http\Livewire\LogoutOtherBrowserSessionsForm as BaseLogoutOtherBrowserSessionsForm;

class LogoutOtherBrowserSessionsForm extends BaseLogoutOtherBrowserSessionsForm
{
   //
}

Override both method deleteOtherSessionRecords and getSessionsProperty to meet the requirement. Adding extra query and fix some logic and it will look like this :-



<?php

namespace App\Http\Livewire;

use Illuminate\Support\Carbon;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Str;
use Laravel\Jetstream\Http\Livewire\LogoutOtherBrowserSessionsForm as BaseLogoutOtherBrowserSessionsForm;

class LogoutOtherBrowserSessionsForm extends BaseLogoutOtherBrowserSessionsForm
{
    /**
     * Delete the other browser session records from storage.
     *
     * @return void
     */
     protected function deleteOtherSessionRecords()
     {
         if (!Str::contains(config('session.driver'), 'database')) {
             return;
         }

         DB::connection(config('session.connection'))
             ->table(config('session.table', 'sessions'))
             ->where('authenticable_id', Auth::user()->getAuthIdentifier())
             ->where('authenticable_type', Auth::user()->getMorphClass())
             ->where('id', '!=', request()->session()->getId())
             ->delete();
     }

    /**
     * Get the current sessions.
     *
     * @return \Illuminate\Support\Collection
     */
    public function getSessionsProperty(): \Illuminate\Support\Collection
    {
        if (!Str::contains(config('session.driver'), 'database')) {
            return collect();
        }

        return collect(
            DB::connection(config('session.connection'))
                ->table(config('session.table', 'sessions'))
                ->where('authenticable_id', Auth::user()->getAuthIdentifier())
                ->where('authenticable_type', Auth::user()->getMorphClass())
                ->orderBy('last_activity', 'desc')
                ->get()
        )->map(function ($session) {
            return (object) [
                'agent' => $this->createAgent($session),
                'ip_address' => $session->ip_address,
                'is_current_device' => $session->id === request()->session()->getId(),
                'last_active' => Carbon::createFromTimestamp($session->last_activity)->diffForHumans(),
            ];
        });
    }
}

Ok now everything is set up.

Once verified, the browser session shows only the one i’m using logged in based on guard. Means that our custom session are working fine. 🤘

That’s it. Hope its help 😁. Thanks for your time.

References

https://jetstream.laravel.com/2.x/introduction.html