"Why is my API returning HTML error pages?!" I stared at my console in disbelief. My React frontend was trying to parse JSON, but Spring Security was happily serving up a Whitelabel Error Page for failed authentication attempts. This took me 3 hours to fix. Let me show you how to make Spring Security play nice with modern frontends. 🎨✨
Ever wondered why sometimes your Spring Boot exceptions are caught by @RestControllerAdvice and other times they're not? Or why your custom AccessDeniedHandler returns 403 before your controller even executes? I spent hours debugging this mystery until I understood Spring Boot's two-tier exception handling architecture. Let me save you the confusion. 🎯
I'll never forget the day I accidentally exposed user passwords in my API responses. I returned the entire User entity from a GET endpoint, thinking "Spring Boot will handle it!" Spoiler alert: It returned EVERYTHING—including hashed passwords, internal IDs, and timestamps. My code reviewer nearly had a heart attack. 😱 That's when I learned about DTOs. Let me save you from this nightmare.
"My login endpoint is returning 403 Forbidden! But I configured it as .permitAll() in SecurityConfig! Why is the JwtFilter still blocking it?" I spent 2 hours debugging this. Turns out, I had a fundamental misunderstanding of how Spring Security works. The JwtFilter doesn't "skip" endpoints - it runs on EVERYTHING. Let me explain the magic. 🎩✨
"Why make something private? Just make everything public. If the coder knows which method to call, they call it. Problem solved, right?" That was me a week ago. I was so wrong. Here's my journey from "public/private is just fancy nonsense" to "holy crap, this actually makes sense!" 🤯
"Why create InvalidCredentialsException extending RuntimeException? Isn't it just to get a descriptive name instead of generic RuntimeException?" No! The name is only a small part. The real power is type-safe error handling - allowing Spring to distinguish between different errors and handle them differently without string parsing. Let's see why custom exceptions are essential, not just fancy naming.
"Why do we use application.properties for secrets in development but environment variables in production?" Because file-based secrets are fine for your local machine (only you have access), but dangerous on production servers (many people have access, files can be compromised). Let's understand why this distinction matters and how to properly manage secrets across environments.
"But don't we still have if-else statements with interfaces?" Yes! But here's the critical difference: scattered if-else in 10 files vs centralized if-else in 1 factory vs zero if-else with registry pattern. Let's see the evolution.
"I changed the object's failedLoginAttempts field, but when I query the database again, it's back to the old value! In high school, changing object properties just worked - why do I need to call save() in Spring Boot?" This is the fundamental difference between in-memory objects (what you learned in school) and database-backed objects (what you use in production). Let's understand why object changes don't automatically persist to the database.
"Why do we need both generateToken() (public) and createToken() (private) instead of just one method?" Because separation of concerns makes your code extensible. The public method handles what claims to add (business logic), while the private method handles how to build the JWT (technical details). This lets you add new token types without repeating code. Let's understand why this design pattern is essential.