Hi everyone,
I think I may have found a regression in the latest Jmix release.
TL;DR: The authorization process using grant_type=authorization_code no longer proceeds as before and gets stuck.
I’ve built a small project where Jmix serves as the backend application, exposing REST services to a frontend application. My setup includes the following Jmix add-ons:
- REST API
- Authorization Server
Regarding the Authorization Server, I’ve configured authorization_code and refresh_token grant types. Everything worked fine until I upgraded Jmix to the latest version.
Now, authentication completes successfully, but instead of being redirected to http://localhost:8080/oauth2/authorize (which should continue the authorization process and generate the access_code), I get redirected to http://localhost:8080, effectively breaking the flow.
Debugging Insights
Digging deeper, I found that in previous versions (<2.5.0), the application stored the initial authentication URL (oauth2/authorize) at the start of the authentication process. Once the user was authenticated, it would redirect correctly, allowing the access_code to be generated.
Now, this URL is no longer saved, preventing the correct redirect. This seems to be due to a change in how URLs are stored in the request cache. Previously, all URLs were stored, but now only specific ones are saved. The relevant code snippet is:
public class FlowuiVaadinWebSecurity extends VaadinWebSecurity {
....
@Autowired
public void setVaadinDefaultRequestCache(VaadinDefaultRequestCache vaadinDefaultRequestCache) {
// Configure request cache to do not save resource
// requests as they are not valid redirect routes.
vaadinDefaultRequestCache.setDelegateRequestCache(getDelegateRequestCache());
}
.....
protected RequestCache getDelegateRequestCache() {
HttpSessionRequestCache cache = new HttpSessionRequestCache();
cache.setRequestMatcher(createViewPathRequestMatcher(viewRegistry));
return cache;
}
protected RequestMatcher createViewPathRequestMatcher(ViewRegistry viewRegistry) {
return new JmixViewPathRequestMatcher(viewRegistry);
}
}
Workaround
Currently, I’ve implemented a temporary workaround by overriding a method in an @Internal class (which isn’t ideal) to manually add the missing behavior:
@Configuration
@EnableWebSecurity
public class MyAppSecurityConfiguration extends FlowuiVaadinWebSecurity {
@Override
protected RequestMatcher createViewPathRequestMatcher(ViewRegistry viewRegistry) {
return new MyAppPathRequestMatcher(viewRegistry);
}
}
public class MyAppPathRequestMatcher extends JmixViewPathRequestMatcher {
public MyAppPathRequestMatcher(ViewRegistry viewRegistry) {
super(viewRegistry);
}
@Override
public boolean matches(HttpServletRequest request) {
// FIXME superclass Business Logic prevents saving oauth2/authorize requests causing wrong redirection when authentication is successful.
String path = LocationUtil.ensureRelativeNonNull(request.getServletPath());
if (path.startsWith("oauth2/authorize")) return true;
return super.matches(request);
}
}
Possible Bug / Regression
I suspect this is a bug or regression in the latest Jmix release.
Steps to Reproduce
- Create a new Jmix project with the REST API and Authorization Server add-ons.
- Replace the default
client_credentialsconfiguration withauthorization_codegrant type configuration (as documented in Jmix Authorization Server Docs). - Test the authentication flow using OAuth Debugger.
Can anyone confirm this issue? Would appreciate any insights from the Jmix team. Thanks!