[ELY-2144] null 'error page' can cause NPE from web component #1734
Conversation
| TestingHttpServerResponse response = request.getResponse(); | ||
|
|
||
| Assert.assertEquals(response.getStatusCode(), HttpConstants.FOUND); | ||
| Assert.assertEquals("http://localhost:8080/application", response.getLocation()); |
There was a problem hiding this comment.
Hello @petrberan , sorry for the delay in my review. IIUC, if the authentication fails and there is no error page to redirect to, we will redirect to the context path after this change right?
Not sure if this is correct approach or we should redirect to the login page instead, which could be handled here
@fjuma WDYT?
There was a problem hiding this comment.
@Skyllarr @petrberan What was the behaviour before with WildFly and legacy security?
There was a problem hiding this comment.
Hi @petrberan , do you happen to know what was the legacy security behaviour?
There was a problem hiding this comment.
Completely missed this thread, sorry about that @fjuma . As for the behaviour, I can't say I know. I'll try looking into it tomorrow.
There was a problem hiding this comment.
Finally caught up with this issue after the work on 7.4.14 and got some findings @fjuma @Skyllarr
I reproduced the issue on Wildfly 9 (aka before Elytron) using the modified servlet-security quickstart, where I changed the authentication to FORM and copied error and login pages from ELY-921. There it worked just fine, once I removed the error page I got an NPE as well. Meaning that the behavior between WFLY 9 and now hasn't changed.
I also find out why. The form-login-config in web.xml requires form-error-page attribute, which is missing in the reproducer for this issue. The behavior is not only consistent over releases, but requires invalid configuration.
I wasn't able to find out how is the behavior supposed to be in specs or anywhere else. As such, I believe we can define our own behavior in such a case.
|
@petrberan Thank you for the PR! This will need a rebase. I wanted to try it locally and there were very minor changes in the test I had to do during rebase which you can see here if it helps: Skyllarr@ceb56ee |
|
Hi @petrberan, looks like this is waiting on a response to this question here: |
|
@petrberan According to the last comment, we need a response to #1734 (comment) Thanks! |
|
Hi @ivassile I was under the impression that I responded to that comment in #1734 (comment) and now I'm waiting for the ELY team. Please let me know if I'm missing something there. |
|
@fjuma Do you need more info to be provided by @petrberan on the question here #1734 (comment) ? |
| @@ -51,6 +51,9 @@ public FormMechanismFactory() { | |||
| public FormMechanismFactory(final Provider provider) { | |||
| } | |||
|
|
|||
| public FormMechanismFactory(final Provider... providers) { | |||
| } | |||
There was a problem hiding this comment.
Where does this change come from? It seems unrelated to the Jira being addressed - is GitHub showing something it shouldn't or has this come in from a rebase?
|
@petrberan Can you answer Darrans question and rebase? Thanks! |
|
Superseded by #2199. |
|
Sorry for the wait @fjuma , wanted to resolve this once I have some time, but @rsearls was a bit quicker :) As to answer @darranl question, I vaguely remember that it has something to do with https://github.com/wildfly-security/wildfly-elytron/pull/1734/files#diff-33a6ea720edc12f207551c1a3393b4d016ade67d5c374048d2f093ed51c14fe0R94 as I wasn't able to guarantee a single provider. Sorry, can't remember much after 2 years |
https://issues.redhat.com/browse/ELY-2144