DEV Community: horlartundhey

Password Reset Without a Database Table: Stateless OTPs in Laravel

horlartundhey — Thu, 30 Jul 2026 19:56:58 +0000

How an HMAC and a rounded clock replaced password_reset_tokens — and the trade-offs nobody mentions.

Every Laravel developer knows the password reset flow. You run the migration, you get a password_reset_tokens table, you call Password::sendResetLink(), and the framework handles the rest. It works. It's battle-tested. It's the right answer most of the time.

I recently built one that stores nothing at all — no table, no cache key, no session. The whole thing is an HMAC and a rounded clock.

This is a walkthrough of how it works, why it was worth doing, and — the part most posts skip — an honest accounting of what it costs you.

The problem with storing reset tokens

Laravel's default is a stateful design. A reset request writes a row:

email                 | token (hashed)      | created_at
alice@example.com     | $2y$10$abc...       | 2026-07-24 09:00:00

Verification reads that row, compares the token, checks created_at against config('auth.passwords.users.expire'), and deletes it.

Nothing is wrong with this. But it carries a tail of small obligations:

A migration, against a schema that may already be live.
Rows that outlive their usefulness. Expired tokens sit there until something prunes them. Laravel ships auth:clear-resets — a scheduled command that many teams never actually wire up.
A write on every request. Password reset is a low-volume endpoint, so this rarely matters — but it is a database write in your unauthenticated attack surface, which is a thing an attacker can make you do a lot of.
Shared state across nodes. Fine with one database. Something to think about with read replicas and replication lag, where a token written to the primary may not be visible to the replica the verification request lands on.

None of these are dealbreakers. They're just there. And I had a codebase where the pattern for avoiding all of them already existed.

The insight: a token that verifies itself

The passwordless-login flow in this application already did something clever, inline, in a controller:

$otp = rand(100000, 999999);

$now = now();
$minuteBlock = floor($now->minute / 5) * 5;
$lastBlockStart = $now->copy()->setTime($now->hour, $minuteBlock, 0)->toDateTimeString();

return response()->json([
    'nonce_key' => hash_hmac('sha256', $request->email . $otp . $lastBlockStart, config('app.key')),
]);

The idea underneath: don't store the code — store a proof that you issued it.

The server generates a 6-digit OTP and emails it. It also computes an HMAC over email + otp + time_block, keyed with the application secret, and hands that back to the client as a nonce_key. Then it forgets both.

When the user submits their code, they send back three things: the email, the OTP from their inbox, and the nonce_key their browser has been holding. The server recomputes the HMAC and compares.

If it matches, the code is genuine — because only the server knows APP_KEY, and therefore only the server could have produced that HMAC over that exact triple. The token carries its own proof of authenticity.

The pattern was worth promoting out of the controller and into something reusable:

namespace App\Support;

class OtpNonce
{
    public static function generate(string $identifier): array
    {
        $otp = ! app()->environment('production')
            ? '123456'
            : (string) random_int(100000, 999999);

        return [
            'otp' => $otp,
            'nonce_key' => self::hash($identifier, $otp, self::currentBlock()),
        ];
    }

    public static function verify(string $identifier, string $otp, string $nonceKey): bool
    {
        foreach ([self::currentBlock(), self::currentBlock(-5)] as $block) {
            if (hash_equals(self::hash($identifier, $otp, $block), $nonceKey)) {
                return true;
            }
        }

        return false;
    }

    private static function hash(string $identifier, string $otp, string $block): string
    {
        return hash_hmac('sha256', $identifier.$otp.$block, config('app.key'));
    }

    private static function currentBlock(int $offsetMinutes = 0): string
    {
        $now = now()->addMinutes($offsetMinutes);
        $minuteBlock = floor($now->minute / 5) * 5;

        return $now->copy()->setTime($now->hour, (int) $minuteBlock, 0)->toDateTimeString();
    }
}

Forty lines. That's the whole mechanism.

Three details that carry the weight

Expiry that requires no cleanup

currentBlock() floors the clock to a 5-minute boundary. 09:07:41 becomes 09:05:00.

That timestamp goes inside the hash. Which means: once the wall clock moves past the accepted window, the same email + otp pair hashes to a different value, and the old nonce_key simply stops matching.

The token expires because time moved, not because anything deleted it. There is no cron job. There is no TTL to configure. There is nothing to garbage-collect.

But quantised time has a sharp edge. A code issued at 09:04:59 is bound to block 09:00 — and one second later, currentBlock() returns 09:05. One second of life.

The fix is to accept the previous window too:

foreach ([self::currentBlock(), self::currentBlock(-5)] as $block) {

Now every code lives at least 5 minutes and at most 10, depending on where in the window it was issued. It's the same trade-off TOTP authenticator apps make when they accept the adjacent time step to tolerate clock skew: a little precision traded for a lot of usability.

`hash_equals`, always

if (hash_equals(self::hash($identifier, $otp, $block), $nonceKey)) {

PHP's === short-circuits at the first differing byte. Comparing a secret with it leaks, through response latency, how many leading bytes you got right. An attacker who can measure that reconstructs the expected value byte by byte — turning 2²⁵⁶ guesses into about 8,000.

hash_equals() compares in constant time. It costs nothing. Use it every single time you compare something secret.

Binding is what makes it a token

hash_hmac('sha256', $identifier.$otp.$block, config('app.key'));

Every input inside the hash is a property the token now enforces:

identifier inside → a nonce minted for alice@ will never validate for bob@.
otp inside → you can't pair a stolen nonce with a guessed code.
block inside → it expires.
APP_KEY as the key → nobody outside the server can forge one.

This last point deserves emphasis, because it's the one people get wrong. If you use a plain hash('sha256', ...) over public inputs, anyone can compute it and the token proves precisely nothing. HMAC keys the hash with a server secret. That's the entire difference between a token and a checksum.

A useful side effect: rotating APP_KEY instantly invalidates every outstanding code. Handy during an incident. Slightly annoying during a routine rotation.

Splitting knowledge across two channels

The controller side is where the design's real security property shows up:

public function forgotPassword(Request $request)
{
    $request->validate(['email' => ['required', 'email:rfc,dns']]);

    $user = User::where('email', $request->input('email'))->first();
    $otp  = OtpNonce::generate($request->input('email'));

    if ($user) {
        $user->notify(new UserForgotPasswordOtp($otp['otp']));
    }

    return response()->json([
        'status'    => true,
        'message'   => 'If that email is registered, a reset code has been sent.',
        'nonce_key' => $otp['nonce_key'],
    ]);
}

Two things are deliberate here.

First: the OTP is generated unconditionally. Look at the ordering — generate() runs whether or not the account exists. Only the email send is conditional. So a registered address and an unregistered one produce byte-identical responses: same status, same message, same shape, a real nonce_key either way.

That closes user enumeration. An attacker can't use this endpoint to work out which addresses have accounts. The deliberately hedged copy — "If that email is registered…" — exists for the same reason, and is why GitHub, Stripe, and Laravel Fortify all word theirs the same way.

Second: the two secrets travel over different channels. The OTP goes to the inbox. The nonce_key goes to the browser. Verification needs both.

An attacker who compromises the email but not the session has a code and no nonce. One who intercepts the HTTP response but not the inbox has a nonce and no code. Neither half is sufficient.

Verification is then trivial:

abort_unless(
    OtpNonce::verify($request->email, $request->otp, $request->nonce_key),
    Response::HTTP_UNPROCESSABLE_ENTITY,
    'Invalid or expired code'
);

$user = User::where('email', $request->email)->first();
abort_unless($user, Response::HTTP_UNPROCESSABLE_ENTITY, 'Invalid or expired code');

The HMAC check runs first — it's pure CPU, while the lookup is a query, so forged requests never cost a round-trip. And both failures return the identical message. "Wrong code" and "no such user" are indistinguishable from outside. The repetition is the point.

Now the part that matters: what this costs you

Here's where most posts about a clever pattern stop. They shouldn't.

Statelessness means you cannot enforce single use

This is the big one, and it follows directly from the design rather than from any mistake in it.

With nothing stored, nothing can be marked as used. A code that successfully resets a password stays valid for the remainder of its window and can reset it again. A stateful token gets deleted on use. This one can't be.

Any fix reintroduces exactly the state you were avoiding:

$fingerprint = 'otp_used:'.hash('sha256', $nonceKey);
abort_if(Cache::has($fingerprint), 422, 'Invalid or expired code');
Cache::put($fingerprint, true, now()->addMinutes(10));

That's a legitimate middle ground — a 10-minute cache key is a far lighter obligation than a permanent table. But be clear-eyed: you are now stateful. Make it a decision, not an accident.

Statelessness also means you can't count attempts

And this is where it gets genuinely dangerous.

The routes as first written carried no throttle middleware — while the email-verification routes directly beside them in the same file used throttle:6,1.

The attack is short:

POST /forgot-password with the victim's email. You get a valid nonce_key in the response.
Brute-force POST /reset-password across the 900,000-code space.
You never needed the victim's inbox at all.

Nothing burns attempts. Nothing locks out. Nothing alerts. The split-knowledge property I described above is exactly what collapses, because the endpoint hands you one of the two halves for free.

A stateful implementation gets a natural attempt counter — the row is right there. A stateless one has nowhere to put it, so the throttle has to be external:

Route::middleware(['guest', 'throttle:5,10'])->post('reset-password', ...);
Route::middleware(['guest', 'throttle:3,10'])->post('forgot-password', ...);

Throttling on email and IP is stronger. But the honest framing is this: statelessness didn't remove the need for state — it moved it into the rate limiter. If you skip that step, you have built a very elegant account-takeover endpoint.

Environment gates are sharper than they look

$otp = ! app()->environment('production') ? '123456' : random_int(100000, 999999);

A fixed dev code is genuinely good DX — you test the flow in Postman without opening a mail catcher every time.

But read the condition carefully. It says "not production." Which means staging, testing, demo, and any host with a typo'd APP_ENV all issue 123456. Combined with the nonce_key coming back in the response body, anyone can reset any account on such a host with zero email access.

Laravel defaults APP_ENV to production when unset, which is the right direction to fail. But deny-lists fail open by nature. Allow-list instead:

$fixed = app()->environment('local', 'testing') && config('auth.otp.fixed_code');

Your existing tokens don't care that the password changed

This one isn't specific to stateless OTPs, but it's specific to JWT auth, and the two ship together often enough to be worth stating.

With jwt-auth, tokens are self-contained and valid until they expire. Changing the password does not invalidate them. An attacker holding a token keeps their access after the victim resets — which defeats the single most common reason a user resets a password under duress.

You need a token_version claim you can bump, or a blacklist entry on reset. Not optional if the reset flow is meant to be a recovery mechanism.

So: was it worth it?

For this codebase, yes — with the throttle added.

What you get: no migration on a live schema, no cleanup job, no shared state between nodes, and a verification path that's pure computation. Any app server can verify any code with no coordination whatsoever. In a horizontally-scaled deployment, that's a genuinely nice property, and it comes from forty lines with no infrastructure attached.

DevOps Week 04: From Git Commits to a Live EC2 Server: Deploying CodeTrack with Nginx

horlartundhey — Sat, 25 Jul 2026 00:14:37 +0000

From Git Commits to a Live EC2 Server: Deploying CodeTrack with Nginx

Introduction

One of the most important lessons I am learning in my DevOps journey is that writing code is only one part of building software.

A project also needs to be tracked, versioned, transferred, deployed, served, and verified.

For this project, I worked on CodeTrack, a static website that I first managed locally with Git and then deployed to a live AWS EC2 instance running Ubuntu and Nginx.

The goal was to simulate a basic real-world deployment workflow:

Local Development
        ↓
Git Tracking
        ↓
Git Staging
        ↓
Meaningful Commits
        ↓
Secure File Transfer
        ↓
AWS EC2
        ↓
Nginx
        ↓
Live Website
        ↓
Deployment Verification

This exercise helped me connect concepts that I had previously learned separately: Git, Linux, AWS EC2, SSH, SCP, Nginx, HTTP, and basic deployment validation.

What I Built

The project was a static website called CodeTrack.

The deployment workflow involved:

Creating and managing the project files locally
Tracking the files with Git
Staging files intentionally
Creating a clean initial commit
Making a controlled homepage update
Creating a second meaningful commit
Transferring the project to an AWS EC2 instance using SCP
Serving the website using Nginx
Validating the deployment using curl
Confirming the application was accessible through the EC2 public IP

The assignment was designed to connect local version-control practices with a basic manual deployment workflow used in DevOps environments.

Part 1: Verifying the Git Repository

Before making any changes, I first verified that Git was installed and that I was working inside the correct project directory.

git --version

This confirmed that Git was available on the system.

I then navigated into the CodeTrack project directory and checked the repository status:

git status

This step is simple, but important.

Running commands in the wrong directory is a common mistake when working with Git. Before modifying files or creating commits, it is important to know exactly where you are and whether the directory is actually a Git repository.

The git status command provides information about:

The current branch
Untracked files
Modified files
Staged files
Changes waiting to be committed

This gave me a clear starting point before making any changes.

Part 2: Creating the Starter Files

The project required two basic files:

index.html
style.css

I created them using:

touch index.html style.css

Then I confirmed that they existed:

ls

At this point, the project had its basic structure, but the files still needed their actual HTML and CSS content.

I then populated the files with the provided starter content.

This represents a common development workflow: first creating the basic project structure, then adding the implementation.

Part 3: Understanding Git Tracking and Staging

After creating the files, I checked the repository status again:

git status

Because the files had not yet been added to Git, they appeared as untracked files.

This distinction is important.

A file can exist in the project directory without being tracked by Git.

The basic Git workflow looks like this:

Working Directory
        ↓
git add
        ↓
Staging Area
        ↓
git commit
        ↓
Repository History

I staged the files:

git add index.html
git add style.css

Then I checked the status again:

git status

The files were now listed under:

Changes to be committed

This confirmed that Git was ready to include them in the next commit.

One thing I learned from this process is that staging provides control over what goes into a commit. Instead of automatically committing every change in the project, I can deliberately choose which files should be included.

Part 4: Creating the First Commit

Once the files were staged, I created the initial commit:

git commit -m "Initial UI scaffold: add index.html and style.css"

This created the first snapshot of the project.

A commit is essentially a saved point in the project's history.

The first commit represented the initial UI scaffold:

Initial UI Scaffold
├── index.html
└── style.css

I then verified the commit history:

git log --oneline

The purpose of using a meaningful commit message is to make the project history easier to understand.

Instead of seeing a history full of vague messages such as:

update
changes
fix
new

a message like:

Initial UI scaffold: add index.html and style.css

immediately explains what changed.

Good commit messages become a useful work log for developers and teams.

Part 5: Making a Controlled Change

After creating the initial commit, I made a controlled update to the homepage.

The changes included updating the homepage content, including the student information and group details required by the assignment.

After modifying index.html, I checked the repository status:

git status

Git detected that the file had been modified.

This is different from the earlier untracked-file situation.

Previously:

index.html

was a file Git had never seen before.

Now, Git already knew about the file because it had been included in the first commit.

Therefore, Git could compare the current version with the version stored in the repository and detect the changes.

I then staged only the modified file:

git add index.html

After confirming the staging area, I created a second commit:

git commit -m "Update homepage content: heading, tagline, CTA button"

I then checked the commit history again:

git log --oneline

The history now contained two separate commits:

Update homepage content: heading, tagline, CTA button

Initial UI scaffold: add index.html and style.css

This separation is useful because the project history now clearly shows two different stages of development:

The initial UI was created.
The homepage content was later updated.

If the second change introduced a problem, it could be reviewed or reverted separately from the original project scaffold.

This is one of the practical benefits of maintaining meaningful commits.

Part 6: Preparing the AWS EC2 Server

After completing the local Git workflow, the next step was to deploy the website to a live server.

The deployment target was an AWS EC2 instance running Ubuntu.

Before deploying, the server needed to have:

A running EC2 instance
SSH access
HTTP access through port 80
Nginx installed and running

The basic deployment architecture looked like this:

Browser
   │
   │ HTTP Request
   ▼
EC2 Public IP
   │
   ▼
Nginx
   │
   ▼
/var/www/html
   │
   ├── index.html
   └── style.css

The EC2 Security Group needed to allow:

SSH traffic on port 22 from the appropriate IP address
HTTP traffic on port 80 for testing the website

This is an important security consideration.

SSH is necessary for server administration, but it should not be exposed more broadly than necessary.

HTTP, on the other hand, needs to be accessible to users who want to visit the website.

Part 7: Verifying Nginx

Before deploying the CodeTrack files, I verified the state of Nginx.

sudo systemctl status nginx --no-pager

The expected result was:

Active: active (running)

This confirmed that the Nginx service was running.

I also validated the Nginx configuration:

sudo nginx -t

A successful result looked like:

nginx: configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

This is an important habit when working with Nginx.

Before restarting or reloading the service after configuration changes, it is safer to validate the configuration first.

A configuration error can cause Nginx to fail to restart.

If Nginx fails to restart in production, the website may become unavailable because Nginx is responsible for serving the HTTP traffic.

A basic recovery process would be:

sudo nginx -t

Then, if there is a problem:

systemctl status nginx --no-pager

And:

sudo journalctl -u nginx --no-pager -n 50

These commands help identify the cause of the failure.

If a recent configuration change caused the issue, the basic rollback plan would be to restore the last known-good configuration, validate it again, and restart Nginx.

Part 8: Transferring the Website to EC2 with SCP

The CodeTrack files existed locally, but Nginx could only serve files that existed on the EC2 server.

To transfer the files, I used SCP.

SCP stands for Secure Copy Protocol.

It allows files to be transferred between computers over an SSH connection.

The basic idea was:

Local Computer
      │
      │ SCP over SSH
      ▼
AWS EC2 Instance

The files were transferred to the server using a command similar to:

scp -i "your-key.pem" -r CodeTrack ubuntu@<EC2_PUBLIC_IP>:~/CodeTrack

The important parts of this command are:

scp

The secure copy command.

-i "your-key.pem"

Specifies the SSH private key used for authentication.

-r

Means recursive, which is required when copying a directory and its contents.

CodeTrack

The local project directory.

ubuntu@<EC2_PUBLIC_IP>

The remote server username and address.

The files were then transferred to the EC2 instance.

This was an important distinction for me:

Having a project committed to Git does not automatically make it available on a server.

The files still need to be transferred or retrieved by the deployment system.

In a manual deployment, SCP can be used.

In a more advanced CI/CD workflow, a pipeline could automatically build and deploy the application after changes are pushed to a repository.

Part 9: Performing a Pre-Deployment Check

Before replacing the existing content in the Nginx web root, I checked the current state of the server.

The Nginx web root was:

/var/www/html

I checked the current Nginx status:

sudo systemctl status nginx --no-pager

I validated the configuration:

sudo nginx -t

I inspected the existing web root:

ls -la /var/www/html/

And tested the current HTTP response:

curl -I http://localhost

The expected response included:

HTTP/1.1 200 OK

This pre-deployment check created a known baseline.

Before making a change, I knew:

Nginx was running
The configuration was valid
The web root contained existing files
The server was responding to HTTP requests

This is a useful operational habit.

Before making a potentially destructive change, understand the current state of the system first.

Part 10: Deploying CodeTrack to the Nginx Web Root

The files needed to be placed inside the directory Nginx was configured to serve.

The target directory was:

/var/www/html

The old content was removed:

sudo rm -rf /var/www/html/*

The CodeTrack files were copied into the web root:

sudo cp -r ~/CodeTrack/* /var/www/html/

Permissions and ownership were then applied:

sudo chown -R www-data:www-data /var/www/html

And:

sudo chmod -R 755 /var/www/html

After the deployment, I validated the Nginx configuration again:

sudo nginx -t

Then restarted Nginx:

sudo systemctl restart nginx

Finally, I confirmed that the expected files existed:

ls /var/www/html/

The directory contained:

index.html
style.css

At this point, the CodeTrack files had been placed in the location Nginx was serving.

Part 11: Verifying the Deployment with curl

A deployment should not be considered complete simply because the files were copied successfully.

The application needs to be tested.

I used:

curl -I http://localhost

The expected response was:

HTTP/1.1 200 OK

This confirmed that:

The request reached the server.
Nginx was running.
Nginx was able to serve the deployed content.
The server returned a successful HTTP response.

This is a simple but valuable deployment check.

It verifies the server from inside the machine before relying only on a browser.

The final step was opening the EC2 public IP in a browser and confirming that the CodeTrack application was accessible externally.

Understanding the Complete Deployment Flow

The complete workflow looked like this:

┌──────────────────────────┐
│ Local CodeTrack Project  │
└────────────┬─────────────┘
             │
             ▼
       git status
             │
             ▼
       git add
             │
             ▼
       git commit
             │
             ▼
      Controlled Changes
             │
             ▼
        Second Commit
             │
             ▼
          SCP Transfer
             │
             ▼
┌──────────────────────────┐
│      AWS EC2 Server      │
│         Ubuntu           │
└────────────┬─────────────┘
             │
             ▼
          Nginx
             │
             ▼
     /var/www/html
             │
             ▼
       CodeTrack Website
             │
             ▼
        HTTP 200 OK
             │
             ▼
        Browser Access

This workflow demonstrated how multiple tools work together:

Tool	Purpose
Git	Track changes and maintain project history
Git Commit	Save meaningful project snapshots
SSH	Securely connect to the EC2 server
SCP	Transfer files securely
AWS EC2	Provide the virtual server
Ubuntu	Operating system for the server
Nginx	Serve the website
curl	Test HTTP responses
Browser	Verify the application externally

What I Learned

This project helped me understand several important concepts more practically.

1. Git is more than just saving code

Git provides a history of how a project changes over time.

Creating separate commits for separate changes makes it easier to:

Review changes
Understand project history
Troubleshoot issues
Roll back changes

2. Staging provides control

The staging area acts as a checkpoint between the working directory and the commit.

The workflow is:

Make Changes
     ↓
Review Changes
     ↓
Stage Selected Files
     ↓
Commit

This prevents unrelated changes from accidentally being included in the same commit.

3. Deployment requires verification

Copying files to a server is not enough.

A proper deployment should verify:

The service is running
The configuration is valid
The files exist in the correct location
The server returns the expected HTTP response
The application is accessible from the browser

4. Nginx is the bridge between the server and the browser

The browser does not directly open the index.html file from my local computer.

Instead, the request follows a path:

Browser
   ↓
EC2 Public IP
   ↓
Nginx
   ↓
/var/www/html/index.html
   ↓
HTTP Response
   ↓
Browser

Understanding this request flow makes troubleshooting much easier.

5. Manual deployment helps explain CI/CD

Although this was a manual deployment, the underlying process is similar to what automated pipelines do:

Code Change
    ↓
Version Control
    ↓
Build
    ↓
Transfer
    ↓
Deploy
    ↓
Restart/Reload
    ↓
Verify

A CI/CD pipeline automates many of these steps, but understanding the manual process first makes the automation easier to understand.

Final Thoughts

This CodeTrack project was more than simply putting a static website online.

It helped me connect several foundational DevOps concepts into one practical workflow.

I started with a local project, tracked it with Git, created meaningful commits, transferred the files securely to AWS, deployed them to an Ubuntu server, configured the web server, and verified the result using HTTP testing.

The biggest lesson for me was the importance of verification.

A deployment is not complete simply because a command ran successfully.

You need evidence.

Nginx is active
        +
Configuration is valid
        +
Files exist in the web root
        +
curl returns HTTP 200
        +
The browser loads the application

Together, these checks provide much stronger confidence that the deployment is actually working.

This project is another step in my journey toward becoming a stronger Software Engineer with deeper skills in Linux, AWS, Git, Nginx, Cloud Engineering, and DevOps.

Acknowledgements

You can follow my graded progress throughout the cohort.

This project is part of the DevOps Micro Internship with Agentic AI Cohort 3.

Technologies Used

Git
AWS EC2
Ubuntu
Nginx
SSH
SCP
HTML
CSS
curl

DevOps #Linux #Git #AWS #EC2 #Nginx #CloudEngineering #SoftwareEngineering #Deployment #LearningInPublic

Week 3 at DMI — When Linux Stopped Being Theory

horlartundhey — Mon, 20 Jul 2026 16:04:19 +0000

Week 3 of DevOps Micro Internship was the week Linux stopped being something I read about and became something I broke, diagnosed, and fixed on a real Ubuntu VM.

It started with spinning up an AWS Free Tier account and provisioning the EC2 instance I'd be operating on for the rest of the week. From there, I deployed two real applications through Nginx: a React app built with Node.js and npm, and a personal portfolio site, EpicReads. Both drills covered the same core loop — install the runtime, clone the code, build it, move the build into Nginx's web root, and configure the server block to serve it correctly. Small details mattered more than I expected: file permissions, the right root path, and a working reverse-proxy config were the difference between a blank page and a live site.

The most valuable part of the week was the Production Maintenance Drill, where I deliberately broke things in order to learn how to recover them. In one simulation, two semicolons went missing from my Nginx config. nginx -t caught the syntax error before I restarted anything, I restored the missing semicolons, re-validated, and restarted the service — confirming recovery with an external curl -I check for a clean 200 OK. In a second simulation, the entire web root was emptied out, and the app started returning 500s even though Nginx itself stayed healthy. Because I'd backed up the deployment beforehand, recovery was just restoring the backup and re-verifying — a small preview of why atomic, versioned deployments matter in real production systems.

Alongside that, I worked through Bash scripting fundamentals — variables, arrays, loops, conditionals, and functions — building up to a small automation script. That groundwork paid off immediately in the week's capstone: building an AI-assisted Linux health-check skill with Claude Code. I wrote a triage script, wired it into a Claude Code skill, then simulated a real incident (nginx stopped, port 80 down, HTTP checks failing). The skill correctly gathered evidence and diagnosed the cause from the logs — but it was restricted to read-only analysis by design. Per the project's safety rules, only I, the human, could approve and run the actual fix (sudo systemctl start nginx).

That distinction — AI that investigates and recommends, but doesn't execute — is the same "guardrails, not autopilot" lesson from Week 2, and it's the one I keep relearning: the tooling should make me faster at making decisions, not replace the decision.

P.S. This post is a part of DevOps Micro Internship with Agentic AI Cohort-3 by Pravin Mishra. You can start your DevOps journey by joining the DMI waiting list: https://forms.gle/3hvrWJBDzsDeJoPs6

DMIByPravinMishra

You can follow my graded progress throughout the cohort.

Week 0 at DMI: Relearning the Internet From First Principles

horlartundhey — Mon, 20 Jul 2026 15:59:53 +0000

Before I touched a single cloud console, DevOps Micro Internship Cohort 3 sent me back to the internet's plumbing — and it turned out I needed the refresher more than I expected.

Task one asked me to use ChatGPT as a learning assistant, prompting it to explain "What is a protocol in networking?" with a real-life example. The answer stuck with me in the simplest possible way: a protocol is just a set of rules devices agree on before they talk, the same way two people agree on a shared language before a conversation makes sense. That framing carried me through everything else that week.

The core exercise put me in the shoes of a friend launching an online bookstore called EpicReads, hosted on a server in Finland, and asked me to explain to him how someone on the other side of the world would actually reach his site. Walking through packet switching, IP addressing, TCP/IP, and HTTP/HTTPS forced me to stop treating "the internet" as a black box. A request doesn't travel as one block of data — it's broken into packets, routed independently, addressed to a specific IP, and reassembled at the other end, all wrapped in TCP/IP's reliability guarantees and delivered over HTTP or HTTPS.

From there, I mapped out two-tier and three-tier application architecture (frontend/database vs. frontend/backend/database), which made it obvious why EpicReads would eventually need a backend layer once it outgrew a simple storefront. Then came DNS: understanding that epicreads.com is really just a friendly alias for 52.172.142.222, resolved through an A record, was the moment the whole stack finally clicked together — domain name, DNS, IP, and server all pointing at the same thing from different angles.

The hardest part wasn't any single concept — it was holding TCP/IP, DNS, and architecture in my head at the same time as one connected flow instead of four separate facts. That's the habit I'm carrying into the rest of the internship: build the mental model first, then layer in the tools.

DMIByPravinMishra

You can follow my graded progress throughout the cohort.

Week 2 of my reflections from the DevOps Micro Internship: Guardrails, Not Autopilot

horlartundhey — Fri, 10 Jul 2026 13:42:20 +0000

Learning to trust an AI coding agent with real infrastructure, one permission at a time

Going into Week 2 of the DMI DevOps Micro Internship, I assumed I already understood what an AI coding assistant does: you type a prompt, it writes some code, you review it. What I actually learned this week is that Claude Code isn't a text generator you talk to; it's an agent operating inside a system of guardrails, and understanding those guardrails turned out to be the real curriculum.

1. Biggest technical insight I got this week

The concept that reframed everything for me was the agentic loop: read context, plan, call a tool, observe the result, decide the next step, repeat until done. That loop is powerful, but it's only safe because of what wraps around it.

In the project I worked on, CLAUDE.md tells the agent upfront that the site is pure HTML/CSS with no JavaScript and no build step, so it doesn't waste a turn inventing a bundler or npm scripts that were never there. Layered on top of that are skills: reusable slash commands like /scaffold-terraform and /tf-plan that turn a long, easy-to-forget prompt into a single, repeatable action, each with its own declared allowed-tools.

That's where tool restrictions stopped being an abstract "best practice" and became something I could point to. The tf-plan skill is scoped to Bash, Read, Grep, deliberately no Write, because a plan should only observe infrastructure, never change it. settings.json reinforces the same philosophy at the project level: it explicitly allows read-only Terraform and AWS calls (terraform plan, aws s3 ls, aws sts get-caller-identity) and explicitly denies destructive ones (rm -rf *, aws iam *). Permissions, I realized, aren't bureaucracy bolted onto AI, they're the actual mechanism that makes it safe to hand an agent something as consequential as real cloud infrastructure.

2. Biggest insight I got about myself this week

I learn better while doing a video guide that helps people, which surprisingly makes the learning and doing more interesting.

3. My biggest weakness or loop I noticed

The loop I kept catching myself in was trusting documentation over the actual state of the repo. This project's own CLAUDE.md includes a candid note that earlier commits referenced .claude/skills/, a GitHub Actions workflow, and a terraform/ directory, but those were later deleted from the working tree, meaning the "documented" pipeline was aspirational, not real. More than once I found myself reasoning about a file as if it existed because a description said it should, instead of running git status or listing the directory first. It's a small habit gap, but in DevOps, where "what's documented" and "what's actually deployed" can quietly diverge, it's exactly the kind of gap that causes real incidents.

4. One system I will implement this week

Before running any skill or command that touches infrastructure, like /scaffold-terraform or /tf-plan, I will first run git status and check the relevant directory to confirm what actually exists on disk, rather than trusting CLAUDE.md or a skill description alone. I'll do this at the start of every task, not just once per session, so I stop building on assumptions about files that were deleted, renamed, or never committed in the first place.

5. What I learned about Agentic AI and DevOps

Before this internship, "AI" meant a chat window that answered questions. This week reframed it as an operator with guardrails. An agentic AI can follow a structured workflow end-to-end, scaffold Terraform, run a plan, hand the output to a security-auditor or cost-optimizer subagent, and only then wait for a human to approve tf-apply, instead of producing a single disconnected answer.

What stood out most is that the safety doesn't come from the model being well-behaved; it comes from design. tf-plan physically cannot write files. Destructive commands are denied at the settings level, not just discouraged in a prompt. Hooks fire before and after every shell command to check and log what's happening, whether the model "intended" to be careful or not. Reusable skills cut the repetitive typing, which is nice, but the real lesson is that DevOps engineers now have to design two things at once: the automation, and the control layer that keeps it honest. Human review before apply isn't a leftover step from the pre-AI era. It's still the last line of defense.

6. My Week 2 highlight

Highlight of this week will be understanding and actually creating skills and sub-agents, using claude.md as a guide to make sure my agent has the correct context to work with.

I had a bit of an issue with Terraform, but this made me understand the flow better.

*You can view my graded progress for the DevOps Micro Internship here.

This is Week 2 of my reflections from the DevOps Micro Internship. If you're on a similar path, I'd love to hear what clicked for you this week too.*

Introduction to the Document Object Model(DOM): The Foundation of Frontend Development

horlartundhey — Thu, 12 Jun 2025 13:32:11 +0000

What's this article about?

Introduction
What is the DOM?
Why is the DOM Important in Frontend Development?
Understanding the DOM Tree Structure
Interacting with the DOM using JavaScript
Events and the DOM
Common Mistakes Beginners Make with the DOM
Tools and Browser DevTools for DOM Exploration
Best Practices for DOM Manipulation
Conclusion

1. Introduction

When you open a website in your browser, you see buttons, text, images, and various interactive elements. But have you ever wondered how your browser understands and organizes all these parts of a webpage? The answer lies in something called the Document Object Model (DOM).

The DOM serves as the foundation of frontend development. It’s a programming interface that allows developers to structure, access, and modify the content and appearance of a webpage dynamically. Without the DOM, modern interactive websites as we know them would not exist.

For beginners starting in frontend development, understanding the DOM is one of the most crucial first steps. Once you grasp how the DOM works, you’ll be able to:

Dynamically update content on a webpage.

Handle user interactions like clicks, form submissions, and keyboard events.

Build more interactive and responsive user experiences.

In this article, we’ll break down the DOM in a beginner-friendly way, explore its structure, show you how to interact with it using JavaScript, and highlight best practices along the way.

2. What is the DOM?

The Document Object Model (DOM) is a structured representation of an HTML or XML document. Think of it as a live map of your webpage that your browser creates when it loads a page.

When you write HTML code like this:

<!DOCTYPE html>
<html>
  <head>
    <title>My First Webpage</title>
  </head>
  <body>
    <h1>Hello, World!</h1>
    <p>This is my first webpage.</p>
  </body>
</html>

Your browser takes this code and builds a tree-like structure that represents every element, attribute, and piece of text. This structure is the DOM.

At its core, the DOM:

Represents the document as a tree of objects.

Allows programming languages (like JavaScript) to interact with and manipulate the document’s content, structure, and style.

Updates automatically when changes are made, allowing for dynamic content.

In simple terms: HTML is the source, the DOM is the live version your browser uses.

Key Characteristics of the DOM:

Object-Oriented: Everything in the DOM is represented as an object (elements, attributes, text).

Hierarchical: Elements are nested inside one another, forming a tree.

Dynamic: The DOM can be changed in real-time using JavaScript.

3. Why is the DOM Important in Frontend Development?

The DOM is at the heart of almost everything you do as a frontend developer. It bridges the gap between your code and what the user sees and interacts with on the screen. Let’s explore why it's so important:

3.1. Dynamic User Interfaces

Without the DOM, webpages would be static, once loaded, they would never change. But thanks to the DOM, developers can:

Add or remove elements.

Update content without reloading the page.

Show or hide parts of the page based on user actions.

Example:

document.getElementById("greeting").innerText = "Welcome back!";

The above code changes the text content of an element dynamically.

3.2. User Interaction Handling

When users interact with a webpage (clicking buttons, submitting forms, hovering over elements), the DOM allows developers to capture these events and respond accordingly.

For example:

Show a message when a button is clicked.
Validate a form before submission.
Animate elements on user actions.

3.3. Powering Modern Web Frameworks

Modern frontend frameworks like React, Angular, and Vue work heavily with the DOM (or even virtual DOMs) to create smooth, efficient updates to the user interface.

Understanding the DOM is essential even if you plan to work with these frameworks, because:

They build upon DOM principles.
You’ll often need to work directly with the DOM for custom behaviors.

3.4. Debugging and Browser DevTools

When debugging your frontend code, most of your work involves inspecting and manipulating the DOM via browser developer tools. A solid understanding of the DOM helps you:

Diagnose layout problems.
Understand how CSS applies to elements.
Verify event bindings.

4. Understanding the DOM Tree Structure

The DOM is often visualized as a tree, where every part of your HTML document becomes a node in the tree. Understanding this tree structure makes it easier to navigate, select, and manipulate elements using JavaScript.

Let’s break it down:

4.1. The Tree Analogy

Root Node: The very top of the tree is the document object. Everything starts here.
Element Nodes: Each HTML tag (like , ,
,

) becomes an element node.
Text Nodes: The actual text inside elements becomes text nodes.
Attribute Nodes: Attributes (like class, id, and src) are nodes attached to their respective elements.

4.2. A Simple Example

Consider this HTML code:

<!DOCTYPE html>
<html>
  <head>
    <title>DOM Example</title>
  </head>
  <body>
    <h1>Hello World</h1>
    <p>This is a paragraph.</p>
  </body>
</html>

The DOM tree would look something like this:
Document
└── html
├── head
│ └── title
│ └── "DOM Example"
└── body
├── h1
│ └── "Hello World"
└── p
└── "This is a paragraph."

4.3. Why is the Tree Important?

You can move up and down the tree using JavaScript.
You can select parent, child, or sibling elements.
You can add or remove branches (nodes) dynamically.

4.4. The Parent-Child Relationship

The <body> is a child of <html>.
The <h1> and <p> are children of <body>.
The text "Hello World" is a child of <h1>.

4.5. Visualizing the DOM

Visualizing the DOM tree is extremely helpful for beginners because it helps you understand how elements are connected.

5. Interacting with the DOM using JavaScript

Now that you understand what the DOM is and how it’s structured, let’s dive into how you can interact with it using JavaScript. This is where the DOM truly becomes powerful, allowing you to make your webpage dynamic and interactive.

5.1 Accessing Elements

To manipulate an element, you first need to select it. JavaScript provides several ways to do this:

getElementById()
Selects an element by its ID.

<p id="greeting">Hello!</p>

let greeting = document.getElementById("greeting");
console.log(greeting.innerText); // Outputs: Hello!

getElementsByClassName()
Selects elements by class name (returns a collection).

<p class="message">First message</p>
<p class="message">Second message</p>

let messages = document.getElementsByClassName("message");
console.log(messages[0].innerText); // Outputs: First message

querySelector()
Selects the first element that matches a CSS selector.

let heading = document.querySelector("h1");

querySelectorAll()
Selects all elements that match a CSS selector.
let paragraphs = document.querySelectorAll("p");

5.2 Modifying Elements

Once you’ve selected an element, you can modify its content, style, and attributes.

Change Text Content

document.getElementById("greeting").innerText = "Welcome!";

Change HTML Content

document.getElementById("greeting").innerHTML = "<strong>Welcome!</strong>";

Change Style

document.getElementById("greeting").style.color = "blue";

5.3 Adding and Removing Elements

You can also create, append, or remove elements dynamically.

Create and Append

let newParagraph = document.createElement("p");
newParagraph.innerText = "This is a new paragraph.";
document.body.appendChild(newParagraph);

Remove Element

let element = document.getElementById("greeting");
element.remove();

6. Events and the DOM

While manipulating the DOM allows you to change the webpage structure and content, events are what make your webpage interactive. An event occurs when the user or the browser does something, like clicking a button, moving the mouse, submitting a form, or pressing a key.

The DOM allows you to listen for these events and execute JavaScript code in response.

6.1 Common DOM Events

Event	Description
`click`	When an element is clicked
`mouseover`	When the mouse hovers over an element
`mouseout`	When the mouse leaves an element
`keydown`	When a keyboard key is pressed
`submit`	When a form is submitted
`load`	When the page has finished loading

6.2 Adding Event Listeners

The most common way to handle events is by using the addEventListener() method.

Example: Button Click

<button id="myButton">Click Me!</button>
<p id="result"></p>

let button = document.getElementById("myButton");
let result = document.getElementById("result");

button.addEventListener("click", function() {
  result.innerText = "Button was clicked!";
});

When the user clicks the button, the text inside the <p> tag updates dynamically.

6.3 Why Use Event Listeners?

Separation of Concerns: Keeps HTML and JavaScript code separate.
Multiple Handlers: You can attach multiple listeners to the same element.
Flexibility: Allows better control over complex user interactions.

6.4 Other Example: Form Submission

<form id="myForm">
  <input type="text" id="nameInput" />
  <button type="submit">Submit</button>
</form>
<p id="displayName"></p>

let form = document.getElementById("myForm");
let display = document.getElementById("displayName");

form.addEventListener("submit", function(e) {
  e.preventDefault(); // Prevents page reload
  let name = document.getElementById("nameInput").value;
  display.innerText = `Hello, ${name}!`;
});

7.Common Mistakes Beginners Make with the DOM

As you start working with the DOM, it’s natural to run into a few pitfalls. Let’s go over some of the most common mistakes and how to avoid them.

7.1 Trying to Access DOM Elements Before the Page Loads

Problem:
If you try to select or modify DOM elements before they exist in the browser, your code may fail.

Example:

let heading = document.getElementById("heading");
heading.innerText = "Hello!";
If this code runs before the DOM has fully loaded, heading will be null, causing an error.

Solution:
Use the DOMContentLoaded event to ensure your code runs after the DOM is ready.

document.addEventListener("DOMContentLoaded", function() {
  let heading = document.getElementById("heading");
  heading.innerText = "Hello!";
});

7.2 Overusing innerHTML

While innerHTML is powerful, it’s easy to misuse it and accidentally introduce bugs or security vulnerabilities like Cross-Site Scripting (XSS).

Better practice: Use textContent or DOM methods to modify elements.

element.textContent = "Safe Text";

7.3 Forgetting to Remove Event Listeners

When dynamically adding and removing elements, forgetting to remove event listeners can cause memory leaks and unexpected behavior.

button.removeEventListener("click", myFunction);

7.4 Mixing Inline JavaScript with DOM Manipulation

While it’s possible to use inline onclick attributes:

<button onclick="alert('Hello!')">Click Me</button>

Best practice:
Separate your JavaScript code from HTML by using addEventListener(). This makes your code more maintainable and scalable.

7.5 Not Using Efficient Selectors

Using getElementById() is faster and more specific.

Avoid using overly broad selectors that may select multiple unintended elements.

8. Tools and Browser DevTools for DOM Exploration

One of the best ways to learn and work with the DOM is by using the powerful tools built into modern web browsers. These tools allow you to inspect, edit, and experiment with the DOM in real-time.

8.1 The Browser Developer Tools (DevTools)

Almost every modern browser (Chrome, Firefox, Edge, Safari) includes DevTools. You can usually open them by:

Right-click on any element on the page and select Inspect.

Or press F12 or Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac).

8.1.1 Elements Panel

Displays the live DOM tree of the current webpage.

You can expand and collapse elements to see the structure.

You can edit HTML directly to see instant changes.

8.1.2 Console Panel

Allows you to run JavaScript directly in the context of the webpage.

Great for testing DOM manipulations quickly.

Example:

document.querySelector("h1").innerText = "Changed via Console!";

8.1.3 Other Useful Panels

Network: See how resources load.
Sources: Debug JavaScript.
Performance: Analyze page speed.
Accessibility: Review accessibility issues.

8.2 Online Playground Tools

Many online tools allow you to experiment with the DOM:

These are great for practicing DOM manipulation without having to set up files on your computer.

9. Best Practices for DOM Manipulation

As you grow more comfortable working with the DOM, following best practices will help you write more efficient, maintainable, and secure code. Let’s cover some important tips:

9.1 Access Elements Efficiently

Use getElementById() when possible — it’s the fastest.

Minimize repeated DOM queries — store elements in variables if used multiple times.

Example:

let button = document.getElementById("submitBtn");

// reuse `button` instead of querying again
button.addEventListener("click", handleSubmit);

9.2 Avoid Unnecessary Reflows and Repaints

Manipulating the DOM excessively or inefficiently can slow down your page. If you're making multiple changes, try:

Modifying elements outside of the visible document (using DocumentFragment).

Minimizing layout calculations in loops.

9.3 Sanitize User Input

Never directly insert user input into the DOM using innerHTML. This can lead to security issues like Cross-Site Scripting (XSS).

Instead:

element.textContent = userInput;

9.4 Use Event Delegation

Instead of attaching multiple event listeners to many child elements, attach one listener to a parent element.

Example:

document.getElementById("list").addEventListener("click", function(e) {
  if (e.target.tagName === "LI") {
    console.log(e.target.innerText);
  }
});

This approach is more efficient, especially for dynamic content.

9.5 Separate Concerns

Keep your HTML, CSS, and JavaScript separate.

Avoid mixing inline JavaScript (onclick="...") with your HTML.

This leads to cleaner, more maintainable code.

9.6 Use DOMContentLoaded

Make sure the DOM is fully loaded before manipulating it.

document.addEventListener("DOMContentLoaded", function() {
  // Safe DOM manipulation here
});

9.7 Clean Up Event Listeners

When removing elements dynamically, ensure you also remove any event listeners to prevent memory leaks.

element.removeEventListener("click", myFunction);

10. Conclusion

The Document Object Model (DOM) is truly the foundation of frontend development. Every time you build a webpage, you're essentially creating a DOM structure that your browser understands and renders.

For beginners, mastering the DOM unlocks the ability to:

✅ Create dynamic, interactive webpages
✅ Respond to user actions with JavaScript
✅ Modify page content on the fly
✅ Build confidence for learning modern frontend frameworks like React, Vue, or Angular

Key Takeaways:

The DOM represents your HTML as a live tree structure.
JavaScript allows you to interact with and manipulate the DOM.
Events are key to making webpages interactive.
Browser DevTools are your best friend for exploring and debugging the DOM.
Always follow best practices for efficient, safe, and maintainable code.

👉 Next Steps for You as a Beginner:

Practice manipulating the DOM using simple projects (to-do list, calculator, form validation).

Experiment using DevTools on existing websites.

Gradually move on to understanding Virtual DOM (used by modern frameworks).

💡 Always remember:

If you master the DOM, you're already halfway to becoming a great frontend developer!

DEV Community: horlartundhey

Password Reset Without a Database Table: Stateless OTPs in Laravel

The problem with storing reset tokens

The insight: a token that verifies itself

Three details that carry the weight

Expiry that requires no cleanup

hash_equals, always

Binding is what makes it a token

Splitting knowledge across two channels

Now the part that matters: what this costs you

Statelessness means you cannot enforce single use

Statelessness also means you can't count attempts

Environment gates are sharper than they look

Your existing tokens don't care that the password changed

So: was it worth it?

DevOps Week 04: From Git Commits to a Live EC2 Server: Deploying CodeTrack with Nginx

From Git Commits to a Live EC2 Server: Deploying CodeTrack with Nginx

Introduction

What I Built

Part 1: Verifying the Git Repository

Part 2: Creating the Starter Files

Part 3: Understanding Git Tracking and Staging

Part 4: Creating the First Commit

Part 5: Making a Controlled Change

Part 6: Preparing the AWS EC2 Server

Part 7: Verifying Nginx

Part 8: Transferring the Website to EC2 with SCP

Part 9: Performing a Pre-Deployment Check

Part 10: Deploying CodeTrack to the Nginx Web Root

Part 11: Verifying the Deployment with curl

Understanding the Complete Deployment Flow

What I Learned

1. Git is more than just saving code

2. Staging provides control

3. Deployment requires verification

4. Nginx is the bridge between the server and the browser

5. Manual deployment helps explain CI/CD

Final Thoughts

Acknowledgements

Technologies Used

DevOps #Linux #Git #AWS #EC2 #Nginx #CloudEngineering #SoftwareEngineering #Deployment #LearningInPublic

Week 3 at DMI — When Linux Stopped Being Theory

DMIByPravinMishra

Week 0 at DMI: Relearning the Internet From First Principles

DMIByPravinMishra

Week 2 of my reflections from the DevOps Micro Internship: Guardrails, Not Autopilot

1. Biggest technical insight I got this week

2. Biggest insight I got about myself this week

3. My biggest weakness or loop I noticed

4. One system I will implement this week

5. What I learned about Agentic AI and DevOps

6. My Week 2 highlight

Introduction to the Document Object Model(DOM): The Foundation of Frontend Development

What's this article about?

1. Introduction

2. What is the DOM?

Key Characteristics of the DOM:

3. Why is the DOM Important in Frontend Development?

3.1. Dynamic User Interfaces

3.2. User Interaction Handling

3.3. Powering Modern Web Frameworks

3.4. Debugging and Browser DevTools

4. Understanding the DOM Tree Structure

4.1. The Tree Analogy

,

4.2. A Simple Example

4.3. Why is the Tree Important?

4.4. The Parent-Child Relationship

4.5. Visualizing the DOM

5. Interacting with the DOM using JavaScript

5.1 Accessing Elements

5.2 Modifying Elements

5.3 Adding and Removing Elements

6. Events and the DOM

6.1 Common DOM Events

6.2 Adding Event Listeners

6.3 Why Use Event Listeners?

6.4 Other Example: Form Submission

7.Common Mistakes Beginners Make with the DOM

7.1 Trying to Access DOM Elements Before the Page Loads

`hash_equals`, always