A Clear Diagram of the User Login Verification Process

Login Flow

Client enters phone number, requests an SMS verification code, inputs the received code, and optionally checks “auto‑register new user”.

Server validates the verification code, creates a new user record if the user does not exist, generates a token, and returns the token to the client.

Token Design

The generated token is stored in Redis with the user’s ID, account and nickname. Token lifetime is chosen per client type: mobile apps receive a week‑long token, web clients receive an hour‑level token. Separate login endpoints or header inspection can be used to assign the appropriate expiration.

Gateway Token Validation

Every subsequent request carries the token. The gateway looks up the token key in Redis, obtains the cached user information, and rewrites internal request headers with userId, account and nickname so downstream services can perform permission checks.

Logout

The logout endpoint deletes the token’s Redis entry and returns HTTP 401; the client interprets 401 as a signal to redirect to the login page.

Anonymous Access

Two approaches are described for allowing requests without a logged‑in user:

Provide an authorized token and limit the number of requests per unit time.

Configure path‑based regular‑expression rules that bypass token verification.

Solution 1: Authorized Token with Rate Limiting

A management UI defines each token and its allowed requests per minute (e.g., 60). Tokens are stored in a Redis hash auth_token_limit where the field is the token value and the value is the request limit. For each request the gateway increments a counter stored under the key auth_token_limit:{token} with a TTL of one minute. If the counter exceeds the configured limit the request is rejected.

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;

import java.util.concurrent.TimeUnit;

/**
 * Authorized token request limit cache
 *
 * @author 热黄油啤酒
 * @since 2021-11-01
 */
@Component
public class AuthTokenRequestLimitCache {

    @Autowired
    private RedisTemplate<String, Integer> redisTemplate;

    private static final String AUTH_TOKEN_LIMIT_KEY_PREFIX = "auth_token_limit";

    /**
     * Increment request count and check if it exceeds the limit
     * @param token token value
     * @return true if the request is allowed, false otherwise
     */
    public boolean incrementWithCheck(String token) {
        // 1. Get the request limit; null means the token is no longer authorized
        Integer limit = getLimit(token);
        if (limit == null) {
            return false;
        }
        // 2. Build cache key and read current count
        String key = String.join(":", AUTH_TOKEN_LIMIT_KEY_PREFIX, token);
        Integer count = redisTemplate.opsForValue().get(key);
        // 3. If no count, initialize it and set 1‑minute expiry
        if (count == null) {
            redisTemplate.opsForValue().increment(key);
            redisTemplate.expire(key, 1L, TimeUnit.MINUTES);
            return true;
        }
        // Increment and compare with limit; return false if exceeded
        Long inc = redisTemplate.opsForValue().increment(key);
        return inc <= limit;
    }

    /**
     * Retrieve the configured limit for a token
     * @param token token value
     * @return limit value or null if the token is not configured
     */
    public Integer getLimit(String token) {
        Object limit = redisTemplate.opsForHash().get("auth_token_limit", token);
        return limit == null ? null : (Integer) limit;
    }
}

Typically only GET operations are permitted for such authorized tokens; POST/PUT actions are disallowed unless the business design explicitly allows them.

Solution 2: Path Regex Validation

The gateway configuration adds a whitelist of regular‑expression rules for request paths. When a request matches a whitelist rule the gateway forwards it without token verification; otherwise normal token validation is performed.

Blacklist

Blacklist is stored as a Redis set of user IDs. Implementation steps:

Provide a “ban” button in the user‑management UI; banned user IDs are added to the Redis set.

During login, check whether the user ID is in the blacklist set and reject the login if present.

If a logged‑in user is later added to the blacklist, the gateway removes the corresponding token cache after authentication and returns HTTP 401, causing the client to redirect to the login page.

Summary

The article presents a complete user login workflow, including token generation, token‑based gateway validation, logout handling, two patterns for anonymous access, and blacklist management, with concrete code and configuration examples.