search

eclipse-ee4j / mojarra

Mojarra, a Jakarta Faces implementation
Other
166 stars 112 forks source link

Don't attempt to set response buffer size on a committed response #5532

Closed Pandrex247 closed 6 days ago

Pandrex247 commented 1 week ago

Changes made to fix https://github.com/eclipse-ee4j/mojarra/issues/5164 and https://github.com/eclipse-ee4j/mojarra/issues/5262 causes breakages in the Jakarta EE 10 Security TCK (specifically in the "old" bit).

[INFO]      [exec] [javatest.batch] FAILED........com/sun/ts/tests/securityapi/ham/customform/base/Client.java#testCustomFormHAMHasCorrectQualifier
[INFO]      [exec] [javatest.batch] FAILED........com/sun/ts/tests/securityapi/ham/customform/base/Client.java#testCustomFormHAMValidateRequest
[INFO]      [exec] [javatest.batch] FAILED........com/sun/ts/tests/securityapi/ham/customform/base/Client.java#testCustomFormLoginToContinueErrorPage

This is reproducible in Payara 6 and GlassFish 7 when using a Mojarra version higher than 4.0.0 (the first change was introduced in 4.0.1).

I'm not 100% certain if this is just a workaround for a dodgy flow, but it fixes the TCK.

The TCK fails because Mojarra is attempting to redirect from a login page after authentication and is attempting to set the response buffer size on the redirected request (which has been committed), causing the redirection to fail and the TCK to not find the correct content. If you refresh the page it has been authenticated, so that's working, it just specifically fails at the point of redirection because Mojarra appears to be too optimistically trying to set the response buffer size.

Pandrex247 commented 1 week ago

I am very open to changing the log level of the "skip" message, it may be better to have it at something like FINE.

pizzi80 commented 1 week ago

I've casual exceptions like this on my webapps, thanks

+1 for the Log level FINE

BalusC commented 6 days ago

The existing checks all log WARN and this is OK as it signals something dodgy is going on and therefore makes the developer aware that the flow the developer was using should be fixed/adjusted/improved. E.g. sending redirect instead of forward and calling responseComplete on FacesContext if it is available.