java - Spring Security - api gateway pattern - bug?

Question

We've created an application that mimics the Spring Security - API Gate Pattern tutorial (https://spring.io/guides/tutorials/spring-security-and-angular-js/#_the_api_gateway_pattern_angular_js_and_spring_security_part_iv). The only variation is that we're using a MySQL database rather than Redis.

Using localhost:8080 as the root, we have localhost:8080/login (login page), localhost:8080/ui (jQuery client), and localhost:8080/api (restful web services, business logic, etc.)

We're finding session handling and forwarding to the various entities works as expected. Meaning the session gets created as expected, forwarding is happening as expected, etc. There is one exception. If I log in, then log out, then go directly to localhost:8080/ui it'll forward me to the login page. You login, and it forwards you back to the localhost:8080/ui, but will display "ACCESS DENIED"!

After tracking the sessions in the database and client I've found that there are two sessions that exist in the database. One with permissions and one without. The client retains the one without!

Has anyone else run into this problem? Is there a way to circumvent this?

Here's a list steps I went through, the database session tracking, and client verification.

    session_id                               principal_name  Client
    ------------------------------------------------------------
1)  go to localhost:8080                    
    9229045c-27e0-410a-8711-45c56576d647    -                X

2)  login                   
    2275db1c-fca4-4a2f-be73-e440599499d6    root             X

3)  logout                  
    cc917e68-b1c0-46a4-bbe3-6705ccf7a5fa    -                X

4)  go to localhost:8080/ui --> forwards to localhost:8080/login
    cc917e68-b1c0-46a4-bbe3-6705ccf7a5fa    -                X

5)  login -> forwards to  localhost:8080/ui -> Access Denied                    
    90d7931d-b265-42e2-a225-286bcf7d159c    -                X

    d2fae0ac-9cf9-4287-8e38-51f64b0ab28d    root 

Answer 1

Alright, after many hours we found a solution to what seemed to be inconsistent behavior. Meaning sometimes you'd log in and it'd retain the proper session and you could go the the localhost:8080/ui page and not get the Whitelabel Error page... sometimes you'd still get it.

On the Gateway server...
1) Added RequestMethod.POST

@Controller
public class HomeController {
    @RequestMapping(method = { RequestMethod.GET, RequestMethod.POST }, path = "/")
    public String home() {
        return "redirect:" + RequestMappings.UI;
    }
}

2) Changed configure file, specifically
a) added .successForwardUrl(“/”)
b) added .loginProcessingUrl(“/login”)
c) added .logoutSuccessUrl("/login?logout")

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.headers()
        .frameOptions().sameOrigin()
    .and().formLogin()
        .loginPage(RequestMappings.LOGIN)
        .failureHandler(failureHandler())
        .successForwardUrl("/")
        .permitAll()
        .loginProcessingUrl("/login")
    .and().logout()
        .logoutSuccessUrl("/login?logout")
    .and().authorizeRequests()
        .antMatchers("/login").permitAll()
        .antMatchers(RequestMappings.CHANGE_PASSWORD).permitAll()
        .anyRequest().authenticated()
    .and().csrf()
        .csrfTokenRepository(csrfTokenRepository())
    .and().addFilterAfter(csrfHeaderFilter(), SessionManagementFilter.class);
}

Now, there still is a way to get the whitepage error. If, before ever logging in, you go directly to localhost:8080/ui…. It’ll forward you to the localhost:8080/login page. You log in. You’ll be at localhost:8080/ui/ looking at everything as expected. If you remove the last forward slash then you’ll get the whitepage error. Then from there things can get mucked up in the cache. But if you go back to the root, you can login as normal and everything will work as normal.

I think what is going on is that the pre-login localhost:8080/ui call is being cached and because the index.html page was never loaded once you log back in and go back you pass the authorization check, but it tries to load… well, nothing, then throws an error. At least that’s my best guess.

Anyways, cheers! Thanks for the help, which started us off on the right track!