Push fail freezes the UI

Ok, I’ll try and let you know

Maybe it’s a silly question, but this was the only way I could reproduce your problem.

Are heartbeat request correctly handled by HeartbeatHandler?
I mean, is there something that could intercept /HEARTBEAT requests and return 200 OK status (like a security filter dispatching to a login form for example)?

I could reproduce your problem only in that way.

HTH
Marco

The only thing that could interfere with the HeartbeatHandler is Spring Security, I hope that I set correctly the configuration:

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/UIDL/**").permitAll()
                .antMatchers("/login/UIDL/**").permitAll()
                .antMatchers("/login/PUSH*").permitAll()
                .antMatchers("/**").hasRole("USER")
                .and()
            .formLogin()
                .loginPage("/login")
                .permitAll()
                .and()
            .csrf()
                .disable();
    }
        
    @Override
    public void configure(WebSecurity web) throws Exception {
        web
            .ignoring()
            .antMatchers("/resources/**")
            .antMatchers("/static/**")
            .antMatchers("/login*")
            .antMatchers("/VAADIN/**")
            .antMatchers("/HEARTBEAT/**");
    }

In examples I remember HEARTHBEAT was configured in HttpSecurity instead of WebSecurity;

http.authorizeRequests().antMatchers("/HEARTBEAT/**").permitAll()

Don’t know If it will change behaviour.

By the way, try to debug HeartbeatHandler to check if it is invoked

Ok, I’ll change the configuration and try.

Nothing to do… I added the permitAll() in the http part but same error after 20 minutes, same result removing the matcher from the web security.

Pretty weird that it happens exactly 20 minutes later that the UI starts, the default heartbeat is 5 mins so it should trigger before.

Not so weird. If you have a 5 minute heartbeat interval, at minute 5. 10 an 15 timeout is not expired, at minute 20 it is.

Can you post responses from heartbeat requests (from chrome network tab in dev tools) so that we can eventually exclude heartbeat as a cause for you problem?


Solved
! Thanks a lot Marco, you pointed me in the right way.

I checked the Network tab on Chrome and the requests about the HeartBeat returned a 302 status, a redirection done by Spring Security.

Checking the configuration I posted above I realized that the requests have been redirected because with URL
/login/HEARTBEAT/…
that is not allowed by the engine because the logged user hasn’t the USER role.

In this way it didn’t worked just adding
.antMatchers(“/HEARTBEAT/**”).permitAll()
because the right one was
.antMatchers(“/login/HEARTBEAT/**”).permitAll()
.

Hi Big-Vienna,
this is a good news.

Glad I could help.

Marco