Tired of Writing S3 Bucket Policies???

Tharvesh Muhaideen A — Wed, 29 Jul 2026 08:17:10 +0000

I Was Tired of Writing S3 Bucket Policies, So I Built a Visual Generator Inspired by WhatsApp Privacy

When I started learning AWS through the GitHub Student Developer Pack, I spent a good chunk of that time inside S3, poking around at its access management.

One part of it kept slowing me down: Bucket Policies.

Every time I wanted to give someone access to a file or folder, I'd end up bouncing between AWS docs and a JSON editor. One missing action or a stray syntax error and the whole policy would break — and debugging it wasn't exactly friendly to someone still learning the ropes.

That's when a question started nagging at me:

Why can't setting a bucket policy be as simple as WhatsApp Status Privacy?

Instead of editing JSON by hand, imagine just choosing:

No One
Everyone
Department Only
Domain Only
Share Only With
Everyone Except

...and letting the app generate the policy for you.

Building the Solution

That question became the Bucket Policy Generator — a frontend app that turns simple UI choices into bucket policy JSON.

Features

Read, Write, Download, and Full Access permission profiles
Single or multiple files and folders
Sharing with specific users
Department-based access
Domain-based access
"Everyone Except" support
Live JSON preview
Copy and download the generated JSON
Built with plain HTML, CSS, and JavaScript

The goal was never to replace AWS — just to flatten the learning curve by keeping policy syntax out of the way while still producing a properly structured policy underneath.

Why I Built It

Understanding permissions is hard enough on its own. Beginners shouldn't have to fight JSON formatting on top of that just to grasp access control.

I wanted people to focus on what access they're granting, not how the JSON has to be written.

Live Demo

https://tharvesh2026.github.io/policy-generator/

I'm still actively working on this and would love feedback from the community. A few things on the roadmap:

Multiple policy statements
Policy templates
Importing existing policies
Validation before export
Role and group support

If bucket policies have ever tripped you up while learning AWS, I'd like to hear how you dealt with it.

I built a full IAM system in Spring Boot — here's what broke when I put it on the internet

Tharvesh Muhaideen A — Wed, 15 Jul 2026 05:11:18 +0000

What I built

identityCore is a self-hosted Identity & Access Management (IAM) service — the kind of thing you'd normally reach for Auth0, Keycloak, or Cognito for, built from the ground up in Spring Boot to actually understand how the pieces fit together.

Stack: Spring Boot 3.3.5, Spring Security 6.3.4, Spring Data JPA, PostgreSQL (prod) / H2 (dev), Thymeleaf, HikariCP, BCrypt.

The feature set

Three login paths, one identity model: form login, Google (OIDC), GitHub (OAuth2) — all resolving to the same UserEntity
RBAC as data, not constants: RoleEntity and PermissionEntity are real JPA entities, editable through an admin UI, not @PreAuthorize("hasRole('ADMIN')") scattered everywhere with no single source of truth
REST + MVC in the same app: AuthApiController / UserApiController return a consistent ApiResponse<T> wrapper, while DashboardController / ProfileController / RoleController serve Thymeleaf views
One exception handler to rule them all: GlobalExceptionHandler catches ApplicationException, ValidationException, ResourceNotFoundException, AuthenticationException and maps each to the right HTTP status — no leaking stack traces, no inconsistent error shapes across endpoints

Why two OAuth2 user services, not one

This is the part most tutorials skip. Google and GitHub are not the same protocol even though Spring Security's oauth2Login() makes them feel identical:

.oauth2Login(oauth -> oauth
    .userInfoEndpoint(userInfo -> userInfo
        .userService(customOAuth2UserService)     // handles GitHub (plain OAuth2)
        .oidcUserService(customOidcUserService)    // handles Google (OIDC)
    )
)

GitHub returns an opaque access_token — no identity claims baked in. You have to call GET /user afterward, and if the user's email is private, that field comes back null. My CustomOAuth2UserService explicitly calls /user/emails to get a real, verified address instead of faking one.
Google returns an id_token — a signed JWT with email, email_verified, and name already inside it. CustomOidcUserService reads it directly, no extra network round-trip.

Both funnel into one shared OAuth2UserProvisioner that does the actual find-or-create against the DB — so the "is this a new user" logic exists in exactly one place, regardless of which provider they came from.

The bug that only showed up in production

Everything passed locally. The moment I pointed my own domain at the app through a tunnel (TLS terminated at the edge, plain HTTP to the app on port 8080), OAuth2 login died with redirect_uri_mismatch.

Root cause: Spring Security builds the OAuth2 redirect URI from what it thinks the incoming request's scheme was. Behind a tunnel/reverse proxy, the app only ever sees the internal http://localhost:8080 hop — so it built http://yourdomain.com/login/oauth2/code/google while Google had https://yourdomain.com/... registered. Same code, same config, silently broken by where it was running.

Fix — one line:

server.forward-headers-strategy=framework

This tells Spring to trust the X-Forwarded-Proto / X-Forwarded-Host headers the tunnel already sends, and rebuild URLs with the correct scheme. No proxy config needed on my end — most tunnels send these headers by default.

Lessons

OAuth2 ≠ OIDC. OAuth2 is authorization (what you can access). OIDC adds a purpose-built identity layer (id_token) on top of it for authentication (who you are). Treating them identically works right up until it doesn't.
A working demo and a working deployment are different problems. The exact same SecurityConfig behaves differently depending on what's between the client and your app.
Centralize provisioning. Two auth paths, one user-creation function — not two copies of "does this user exist" logic that can drift apart.

Repo (branch with the OAuth2 work): github.com/Tharvesh2026/identityCore_J25

Happy to go deeper on the RBAC design or the exception-handling setup if there's interest.

DEV Community: TharvBytes