life is too short for a diary




Daily Logs for Aug 4, 2025

Tags: oauth2 vim

Author
Written by: Tushar Sharma
Featured image for Daily Logs for Aug 4, 2025

Dear Vishi, my logs for today

Quickly moving around in the terminal is essential for productivity. While Ctrl+A (start of line) and Ctrl+E (end of line) are great for editing commands, scrolling through output is different.

Most terminal emulators (like iTerm, GNOME Terminal, or Windows Terminal) allow you to scroll through the output buffer using Shift+PageUp and Shift+PageDown or your mouse's scroll wheel. To jump directly to the top or bottom, you can pipe the output of a command to a pager like less:

# Pipe a long command's output to less
ls -lR / | less

# In less, you can:
# - Press 'G' to go to the end (bottom).
# - Press 'g' to go to the start (top).
# - Use arrow keys or j/k to scroll.
# - Press 'q' to quit.

Refreshing a File in Vim

When a file you're editing in Vim is changed by an external process (like a git pull), you need to reload it.

A Deep Dive into OAuth2 Grant Types

OAuth2 is an authorization framework, not an authentication protocol. It provides standardized flows for applications to gain secure, limited access to user resources without exposing their credentials. Identity Providers like Okta, Auth0, or Entra ID (Azure AD) implement these flows.

The Core Endpoints: /authorize and /token

OAuth2 separates the process of getting user consent from the process of obtaining an access token. This separation is a key security principle and is handled by two main endpoints:

Why the separation? To keep sensitive tokens out of the browser. The access token is a powerful credential. By exchanging the code on the backend, the token is never exposed to the user's machine, preventing its theft through browser history or malicious scripts.

1. Authorization Code Grant

This is the most common and secure grant type, ideal for traditional web and mobile applications that have a backend server.

Flow:

  1. User Consent: The application redirects the user to the /authorize endpoint.
  2. Get Code: The user logs in and gives consent. The provider redirects back to the application with a short-lived authorization code.
  3. Exchange Code for Token: The application's backend sends the authorization code, its client_id, and client_secret to the /token endpoint.
  4. Receive Tokens: The provider validates everything and returns an access token and a refresh token.

Real-World Examples:

2. Client Credentials Grant

This grant is for machine-to-machine (M2M) communication where there is no user interaction.

Flow:

  1. Request Token: A backend service makes a direct call to the /token endpoint, sending its client_id and client_secret.
  2. Receive Token: The provider validates the credentials and returns an access token.

Key Characteristics:

Real-World Examples:

3. PKCE: Securing Public Clients

PKCE (Proof Key for Code Exchange) is not a separate grant type but an extension that makes the Authorization Code flow more secure for clients that can't protect a secret, like Single-Page Applications (SPAs) and native mobile apps.

It mitigates an "authorization code interception" attack. In this attack, a malicious app on a user's device could intercept the authorization code and exchange it for an access token.

How PKCE Helps:

  1. Before starting the flow, the client app generates a secret code_verifier and a transformed version of it called the code_challenge.
  2. It sends the code_challenge to the /authorize endpoint.
  3. When exchanging the authorization code at the /token endpoint, it also sends the original code_verifier.
  4. The server transforms the verifier and checks if it matches the challenge sent earlier. If they match, the token is issued.

This ensures that only the application that initiated the request can complete it.

Reference: Microsoft OAuth2 Documentation

Resolving Ambiguous Mappings in Spring Boot

In Spring MVC, an IllegalStateException: Ambiguous mapping error occurs when two or more controller methods are mapped to the same URL pattern and HTTP method, and Spring cannot decide which one to invoke for an incoming request.

Consider this controller:

@RestController
class MyController {

    // Maps to POST /123
    @PostMapping("/{id}")
    public String handlePostWithId(@PathVariable String id) {
        // ...
    }

    // Also maps to POST /123, causing ambiguity!
    @PostMapping("/{id}")
    public String handlePostWithIdAndParam(@PathVariable String id, @RequestParam("test") String bar) {
        // ...
    }
}

Both methods map to POST requests for paths like /some-id. To resolve this, you need to make the mappings more specific. A common technique is to differentiate based on the presence of a request parameter using the params attribute.

The Fix: Using params

By adding params = "test", you tell Spring that the second method should only be invoked if the request URL contains the test parameter.

@RestController
class MyController {

    // Handles POST /123 (without a "test" param)
    @PostMapping("/{id}")
    public String handlePostWithId(@PathVariable String id) {
        // ...
    }

    // Handles POST /123?test=someValue
    @PostMapping(value = "/{id}", params = "test")
    public String handlePostWithIdAndParam(@PathVariable String id, @RequestParam("test") String bar) {
        // ...
    }
}

Now the mappings are unique, and Spring can correctly route requests.

Learning Spanish

I know Jo se
I know it Lo se
do you know? sabes?
I want to know ? Queiro saber
she know its ella lo sabe
comments powered by Disqus