RESTEasy Reactive and security: invalid response after challenge and exception mapper, two Location headers

[FroMage]

I'm getting an auth challenge from HttpAuthenticationMechanism.ChallengeSender which sets the response code and adds a Location header directly to the Vert.x response, and then an AuthenticationFailedException is thrown, resulting in my @ServerExceptionMapper being called and also setting a Location by returning a Response.seeOther() and we end up with two Location headers:

HTTP/1.1 303 See Other
Location: http://localhost:8080/_renarde/security/login
Location: http://localhost:8080/
Set-Cookie: QuarkusUser=;Version=1;Path=/;Max-Age=0
content-length: 0
set-cookie: _renarde_flash=eyJtZXNzYWdlIjoiSW52YWxpZCBzZXNzaW9uIChiYWQgc2lnbmF0dXJlKSwgeW91J3ZlIGJlZW4gbG9nZ2VkIG91dCJ9; Path=/; HTTPOnly; SameSite=Lax
set-cookie: quarkus-redirect-location=http://localhost:8080/; Path=/

I suspect that at the very least, any Response data set by the exception mapper should override the ones set previously, if only because the Response is not meant to come on top of anything prior to it, but override it from scratch. So, the exception mapper's Location should "win" and override the security challenge one.

I wonder what other headers are set directly on the Vert.x response, before we translate the Response headers onto it?

This was first reported in quarkiverse/quarkus-renarde#194

[quarkus-bot]

/cc @geoand (resteasy-reactive), @sberyozkin (security), @stuartwdouglas (resteasy-reactive)

[sberyozkin]

Hi @FroMage Where is the Location header set in Quarkus, which code set its value to http://location:8080/ ?

I suspect that at the very least, any Response data set by the exception mapper should override the ones set previously, if only because the Response is not meant to come on top of anything prior to it, but override it from scratch.

It does appear to be the right thing to do

[FroMage]

Hi @FroMage Where is the Location header set in Quarkus, which code set its value to http://location:8080/ ?

HttpAuthenticationMechanism.ChallengeSender

[sberyozkin]

@FroMage Sorry, yes, you mentioned it, I wonder why are header values different, looks like some authentication mechanism (which one ?) and the custom exception mapper use different Location header value calculation... Just curious if there is something in Quarkus that may need to be tuned...
Duplication is still a problem though...

[FroMage]

That's not really the point, the issue is that RESTEasy Reactive should overwrite any header already set in the vert.x response, when it maps the JAX-RS Response onto the Vert.x response.

[geoand]

I agree, although I do have a fear that we've faced the inverse problem in the past and hence the current behavior

[FroMage]

If that's the case, I pray we added a test for the behaviour, which we'll break and find the issue we wanted to fix with this behaviour. Then discuss this further :)

[geoand]

Yeah, I have to check

[geoand]

@FroMage can you try #38554 ?