we are hosting the process engine via a spring-boot application. The application is set to authenticate with our custom identityprovider via Oauth2.0. Since we are not java/spring-boot-developers, it is possible that we completely oversee an aspect. In our Spring-Boot application we usually configured the SecurityConfig like following:
http .authorizeRequests() .antMatchers("/app/**", "/api/**").authenticated() .and() .oauth2Login() .and() .logout() .logoutUrl("/app/**/logout") // Listen for the logout-endpoints in the apps .logoutSuccessHandler(new OidcClientInitiatedLogoutSuccessHandler(clientRegistrationRepository));
With this configuration we achieved that the web-app itself requires a login from our identity-provider like intended. BUT: As soon as the Spring-Boot session expires and the front end does not get refreshed, the front end is showing strange errors (-1 responses). This is because the application tries to redirect the call to the identityprovider. Since ajax-requests cant handle 3xx status-codes this results in the strange error-messages.
What we’ve tried:
We’ve tried to secure the “/api/**” route separately with a jwt token which worked as intended. Now as soon as the session runs out, the server responds with a 401-errorcode. Normally a front end would handle this with either refreshing the token silently using the refresh-token(I don’t think this is applicable due to the jsessionid-mechanic from spring-security), or would redirect the user to the given identity-provider. In the Camunda-web-apps, the user is getting redirected to the default login form of the web-apps. Since we aren’t using the local user-management, we don’t want this form to show up.
So here are my questions:
How is it intended to handle session-expiration in the Process Engine hosted via Spring-Boot?
Did we do anything completely wrong?
How do you guys handle this?