Repository navigation
keycloak quarkus: NullPointer exception during registration via anchor link in login page. #10684
Description
We migrated to keycloak quarkus, which introduced a bug/nullpointer in our buildPage method of our custom RegistrationUserCreation.
Normally you can use getDecodedFormParameters in all FormAction Implementations.
In the keycloak default RegistrationUserCreation, this method is also used in validate , but the buildPage is empty method implementation. We override this FormAction and have custom code that uses the getDecodedFormParameters.
In keycloak wildfly the implementation class HttpServletInputMessage handles this and that doesn't check for mediatype.
But now in keycloak quarkus, because the registration is done via a anchor link (like is also the default in keycloak), the VertHttpRequest handles this request , which doesn't have a getDecodedFormParameters implementation. Therefore it uses its abstract super class BaseHttpRequest. In here the mediaType is used but the mediaType is null, and causes a nullpointer exception.
Version
17.0.0 (quarkus)
Expected behavior
Avoid nullpointer exception OR handle request in HttpServletInputMessage in stead of VertxHttpRequest.
This because VertHttpRequest does not implement a getDecodedFormParameters method and therefore fallsback to the abstract class BaseHttpRequest getDecodedFormParameters.
Actual behavior
MediaType null causes Nullpoiner exception in BaseHttpRequest - getFormParameters.
How to Reproduce?
Make a custom implementation of the RegistrationUserCreation, and in the buildPage, add the following line:
context.getHttpRequest().getDecodedFormParameters()
This will cause a nullpointerexception within the getDecodedFormParameters()
Anything else?
no
Activity
DGuhr commentedon Mar 10, 2022
Hum, not sure if i understand the exact problem, but I remember we had some problems with the mediatype too bc. resteasy 4 behaves differently than resteasy 3 (wildfly). Fixed that e.g. here: https://github.com/keycloak/keycloak/pull/8582/files - would it help you to add a method like in the PR to your extension?
cc @pedroigor fyi ;)
rvanderboom commentedon Mar 10, 2022
we fixed it ourself in a simular way, but i think it is a bug because in all actionforms , also in default keycloak code getDecodedFormParams is used. I think this shouldn't result in a nulpointer exceptions..
i think the difference is dat in wildfly always the HttpServletInputMessage is used to handle the request for form submits as wel as a href (like the create account link)..
But now in quarkus it seems to use HttpServletInputMessage for form submits (that goes ok), and VertHttpRequest for handling request via a href links..
since VertHttpRequest doesn't have a getDecodedFormparameters, it falls back to its abstract class method, which says a mediatyp is mandatory, since it doesn't check the mediatyp for null.
MediaType mt = getHttpHeaders().getMediaType();
if (mt.isCompatible(MediaType.valueOf("application/x-www-form-urlencoded")))
or do you mean this issue is solved in a newer resteasy version ? We use 3.15.1 which is almost the latest.
version 4 is still in beta for reasteasy-jaxrs
What we done now to fix it, is check in all our custom action if the request is a VertHttpRequest or HttpServletInputMessage and handle correctly depending on situation..
pedroigor commentedon Mar 10, 2022
@rvanderboom As you stated, this is related to the differences between the two runtimes.
We can't do much to fix the issue but recommend the check as suggested by @DGuhr.
W.r.t. to the
validatemethod it should be called only when a POST happens so it shouldn't be a problem, I think.dasniko commentedon Mar 18, 2022
FWIW: I just recognized a very similar issue:
I have a custom authenticator. In the
authenticate()method I want to access the query parameters of the request. Therefore, I callcontext.getHttpRequest().getUri().getQueryParameters(), but the call to.getUri()fails, resp. returnsnullfrom theVertxHttpRequest.So far, so bad...
My "fix"(? workaround?) is to exclude the resteasy v3 resources from the pom.xml (exclude
org.jboss.resteasy:resteasy-multipart-providerfrom thekeycloak-servicesdependency) and adding theorg.jboss.resteasy:resteasy-core:4.7.5.Finaldependency manually to the pom file (compile scope).If I compile my custom authenticator with these settings, also the
VertxHttpRequestreturns anuriand I can access the query params. There's no change in my code needed, just excluding Resteasy v3 and including Resteasy v4.7.5 (the one which is available at runtime in Quarkus) at compile time solves the problem.This Resteasy dependency version hell is really annoying and should really be cleaned up immediately. It causes trouble and pain!!!
pedroigor commentedon Mar 31, 2022
@dasniko Agree. We should be better after #10917.
pedroigor commentedon Jun 14, 2022
Should be fixed by #10917.
etchepar commentedon Nov 9, 2022
The problem seems to be present even in KC 20.0.1 for the initial problem.
nullPointerException on context.getHttpRequest().getDecodedFormParameters() in a custom authenticator
so far, only the workaround of @DGuhr helped us, but we have to apply it in all the concerned authenticator
pedroigor commentedon Nov 10, 2022
@etchepar You're right. Resteasy v4 works differently and throws an error when parsing form data from a request without the expected media type.
We should be providing a better API for dealing with requests and responses so that you don't need to rely on Resteasy APIs directly. We should be doing that as part of #10713.