Bird
Raised Fist0
Spring Bootframework~20 mins

JWT validation filter in Spring Boot - Practice Problems & Coding Challenges

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Challenge - 5 Problems
🎖️
JWT Validation Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
component_behavior
intermediate
2:00remaining
What happens when a JWT is missing in the request header?
Consider a Spring Boot JWT validation filter that checks the Authorization header for a JWT token. What is the typical behavior of the filter when the JWT token is missing?
AThe filter rejects the request and responds with HTTP 401 Unauthorized.
BThe filter allows the request to proceed without authentication.
CThe filter throws a NullPointerException and crashes the application.
DThe filter redirects the user to a login page.
Attempts:
2 left
💡 Hint
Think about security best practices for protected endpoints.
📝 Syntax
intermediate
2:00remaining
Which code snippet correctly extracts the JWT token from the Authorization header?
Given the Authorization header value 'Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...', which code correctly extracts the token string after 'Bearer '?
AString token = authorizationHeader.replace("Bearer", "");
BString token = authorizationHeader.split("Bearer")[1];
CString token = authorizationHeader.substring(6);
DString token = authorizationHeader.substring(7);
Attempts:
2 left
💡 Hint
Remember that 'Bearer ' includes a space after the word.
🔧 Debug
advanced
2:30remaining
Why does this JWT validation filter always reject valid tokens?
Review this filter code snippet that validates JWT tokens. It always rejects tokens even if they are valid. ```java String token = authorizationHeader.substring(7); Claims claims = Jwts.parser().setSigningKey(secretKey).parseClaimsJws(token).getBody(); if (claims.getExpiration().before(new Date())) { response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); return; } chain.doFilter(request, response); ``` What is the likely cause?
Spring Boot
String token = authorizationHeader.substring(7);
Claims claims = Jwts.parser().setSigningKey(secretKey).parseClaimsJws(token).getBody();
if (claims.getExpiration().before(new Date())) {
  response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
  return;
}
chain.doFilter(request, response);
AThe filter uses 'before' instead of 'after' to check expiration, so it rejects tokens that are still valid.
BThe token substring is off by one character, causing parsing errors.
CThe secretKey is incorrect, causing all tokens to fail signature validation.
DThe filter does not call chain.doFilter() when the token is valid.
Attempts:
2 left
💡 Hint
Check the logic comparing expiration date with current date.
state_output
advanced
2:00remaining
What is the value of SecurityContext after a valid JWT is processed?
In a Spring Boot JWT validation filter, after successfully validating a JWT token and extracting user details, the filter sets the authentication in the SecurityContext. What will SecurityContextHolder.getContext().getAuthentication() return?
ANull, because the filter does not set any authentication.
BAn Authentication object containing the user's username and granted authorities.
CA JWT token string representing the user's session.
DAn exception is thrown because SecurityContext is immutable.
Attempts:
2 left
💡 Hint
Think about how Spring Security stores user info after authentication.
🧠 Conceptual
expert
3:00remaining
Why should a JWT validation filter be stateless and not store session data?
In designing a JWT validation filter for a Spring Boot application, why is it important that the filter remains stateless and does not store session data on the server?
ABecause JWT tokens contain all necessary user info, so server-side sessions are redundant and reduce scalability.
BBecause storing session data causes JWT tokens to expire immediately.
CBecause stateless filters automatically refresh JWT tokens without client interaction.
DBecause Spring Boot does not support session management with JWT tokens.
Attempts:
2 left
💡 Hint
Consider how JWT tokens carry user data and how server memory is affected.

Practice

(1/5)
1. What is the main purpose of a JWT validation filter in a Spring Boot application?
easy
A. To generate new JWT tokens for users
B. To check and verify JWT tokens on incoming HTTP requests
C. To log all incoming requests without validation
D. To encrypt the response data before sending

Solution

  1. Step 1: Understand JWT validation filter role

    A JWT validation filter is designed to intercept incoming requests and check the validity of JWT tokens.
  2. Step 2: Identify the correct purpose

    It does not generate tokens or encrypt data; its main job is to verify tokens to allow or deny access.
  3. Final Answer:

    To check and verify JWT tokens on incoming HTTP requests -> Option B
  4. Quick Check:

    JWT validation filter = Verify tokens [OK]
Hint: JWT filter checks tokens on requests, not generating or logging [OK]
Common Mistakes:
  • Confusing validation with token generation
  • Thinking filter encrypts data
  • Assuming it only logs requests
2. Which method in a Spring Boot filter is typically overridden to implement JWT validation logic?
easy
A. doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
B. init(FilterConfig filterConfig)
C. destroy()
D. handleRequest(HttpRequest request)

Solution

  1. Step 1: Identify filter method for request processing

    In Spring Boot, filters extend OncePerRequestFilter and override doFilterInternal to process requests.
  2. Step 2: Match method to JWT validation

    doFilterInternal is where JWT token extraction and validation happen before continuing the chain.
  3. Final Answer:

    doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) -> Option A
  4. Quick Check:

    JWT validation code goes in doFilterInternal [OK]
Hint: JWT validation logic goes in doFilterInternal method [OK]
Common Mistakes:
  • Using init() which is for filter setup only
  • Confusing destroy() with request handling
  • Inventing non-existent handleRequest() method
3. Given this snippet inside a JWT validation filter, what happens if the token is invalid?
String token = request.getHeader("Authorization");
if (token == null || !jwtUtil.validateToken(token)) {
    response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
    return;
}
chain.doFilter(request, response);
medium
A. The server throws a NullPointerException
B. The request proceeds without validation
C. The request is blocked with 401 Unauthorized status
D. The token is refreshed automatically

Solution

  1. Step 1: Analyze token check condition

    If token is missing or invalid, the code sets response status to 401 and returns immediately.
  2. Step 2: Understand filter chain behavior

    Because it returns before calling chain.doFilter, the request does not proceed further.
  3. Final Answer:

    The request is blocked with 401 Unauthorized status -> Option C
  4. Quick Check:

    Invalid token = 401 block [OK]
Hint: Invalid token triggers 401 and stops request chain [OK]
Common Mistakes:
  • Assuming request proceeds despite invalid token
  • Expecting automatic token refresh
  • Thinking NullPointerException occurs here
4. Identify the error in this JWT validation filter snippet:
@Override
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException {
    String token = request.getHeader("Authorization");
    if (token != null && jwtUtil.validateToken(token)) {
        SecurityContextHolder.getContext().setAuthentication(jwtUtil.getAuthentication(token));
    }
    chain.doFilter(request, response);
}
medium
A. It does not handle the case when token is missing or invalid by blocking the request
B. It incorrectly sets authentication before validation
C. It calls chain.doFilter twice causing errors
D. It throws IOException without handling

Solution

  1. Step 1: Review token validation logic

    The code sets authentication only if token is valid, but does not block invalid or missing tokens.
  2. Step 2: Check filter chain continuation

    It always calls chain.doFilter, so invalid requests proceed without rejection.
  3. Final Answer:

    It does not handle the case when token is missing or invalid by blocking the request -> Option A
  4. Quick Check:

    Missing block on invalid token = security hole [OK]
Hint: Always block requests with missing or invalid tokens [OK]
Common Mistakes:
  • Allowing requests without token validation
  • Calling chain.doFilter twice (not here though)
  • Misunderstanding exception handling in filters
5. You want to create a JWT validation filter that extracts the token from the Authorization header, validates it, and sets the user authentication in the security context only if valid. Which sequence of actions is correct inside doFilterInternal?
hard
A. Continue filter chain -> Extract token -> Validate token -> Set authentication -> Else respond 401
B. Validate token -> Extract token -> Set authentication -> Continue filter chain -> Else respond 401
C. Set authentication -> Extract token -> Validate token -> Continue filter chain -> Else respond 401
D. Extract token -> Validate token -> Set authentication -> Continue filter chain -> Else respond 401

Solution

  1. Step 1: Determine correct order of JWT processing

    First, extract the token from the Authorization header, then validate it to ensure it's correct.
  2. Step 2: Set authentication and control flow

    If valid, set user authentication in the security context, then continue the filter chain; otherwise, respond with 401 Unauthorized.
  3. Final Answer:

    Extract token -> Validate token -> Set authentication -> Continue filter chain -> Else respond 401 -> Option D
  4. Quick Check:

    Correct JWT filter flow = Extract token -> Validate token -> Set authentication -> Continue filter chain -> Else respond 401 [OK]
Hint: Extract first, then validate, set auth, continue or block [OK]
Common Mistakes:
  • Validating before extracting token
  • Setting authentication before validation
  • Continuing filter chain before validation