Loading...

XML

Word

Printable

Steps to Reproduce:
Hide

Run FormAuthUnitTestCase in AS TS with Elytron profile (against full distribution due to ~~WFLY-8228~~):

cd testsuite/integration/web mvn clean install -Dtest=org.jboss.as.test.integration.web.formauth.FormAuthUnitTestCase#testPostDataFormAuth -Delytron -Dwildfly.tmp.enable.elytron.profile.tests=true -Djboss.dist=/path/to/eap-or-wildfly-full-distro
Show
Run FormAuthUnitTestCase in AS TS with Elytron profile (against full distribution due to WFLY-8228 ): cd testsuite/integration/web mvn clean install -Dtest=org.jboss.as.test.integration.web.formauth.FormAuthUnitTestCase#testPostDataFormAuth -Delytron -Dwildfly.tmp.enable.elytron.profile.tests= true -Djboss.dist=/path/to/eap-or-wildfly-full-distro
Git Pull Request:
https://github.com/wildfly-security/wildfly-elytron/pull/720

Form authentication backed by Elytron in the web applications uses status code 303 (See Other) to redirect user after processing /j_security_check.

We see two serious issues here:

Legacy security uses status code 302 (Moved Temporarily/Found) to handle this redirect and existing applications/clients may behave differently for these different codes. (e.g. default behavior of Apache HTTP client is to follow redirect for 303, but not to follow for 302)
The 303 status code was introduced in HTTP 1.1 so it's not part of HTTP 1.0, but the 303 is returned also for HTTP/1.0 request as a HTTP/1.0 response, which is wrong.

clones

JBEAP-9109 When Elytron is used redirect from j_security_check uses HTTP code 303