Hi,

On Mon, Jul 28, 2014 at 1:37 AM, Stuart Douglas <sdouglas@redhat.com> wrote:

I think I have fixes for both these issues.

https://github.com/wildfly/wildfly/pull/6539/files

Should fix the NPE (I was not sure what security domain config your example needed in order to reproduce).

Okay great, I'll give it a shot. The security domain configured in standalone.xml is a dummy one that's unfortunately needed to trick Undertow into activating JASPIC (it shouldn't be needed, but for now it is). It's the following one that's used I think in pretty much all WildFly JASPIC examples:

<security-domain name="jaspitest" cache-type="default">
    <authentication-jaspi>
        <login-module-stack name="dummy">
            <login-module code="Dummy" flag="optional"/>
        </login-module-stack>
        <auth-module code="Dummy"/>
    </authentication-jaspi>
</security-domain>

The timeout issues should be fixed in Undertow upstream, it looks like there was two issues:
- The timeout was running in an IO thread
- ThreadLocals where not being properly set up before dispatching to the error page

This sounds like it could well be the issue I was seeing. Timeout was indeed running in an IO thread and it for some reason didn't see that the response was committed and/or dispatched, even when asyncContext.complete() had been called.

Regards,
Arjan

Stuart

arjan tijms wrote:

Hi,

When using a basic async servlet, where the request processing is
transferred to an @Asynchronous method, there's a NPE at the end of the
request:

Exception in thread "default task-107" java.lang.NullPointerException
at
org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism.wasAuthExceptionThrown(JASPIAuthenticationMechanism.java:164)
at
org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism.access$100(JASPIAuthenticationMechanism.java:72)
at
org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism$1.wrap(JASPIAuthenticationMechanism.java:240)
at
org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism$1.wrap(JASPIAuthenticationMechanism.java:234)
at
io.undertow.server.HttpServerExchange$WrapperStreamSinkConduitFactory.create(HttpServerExchange.java:2017)
at
io.undertow.server.HttpServerExchange.getResponseChannel(HttpServerExchange.java:1167)
at
io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:619)
at
io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
at
io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
at
io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:294)
at
io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:432)

The direct cause is that
JASPIAuthenticationMechanism#wasAuthExceptionThrown tries to access the
security context as-in the following line:

SecurityContextAssociation.getSecurityContext().getData().get(AuthException.class.getName())
!= null

Only, for an async request processing thread
SecurityContextAssociation.getSecurityContext() is always null, causing
the NPE. I created a test that functions as a reproducer here:
https://github.com/arjantijms/javaee7-samples/tree/master/jaspic/async-authentication
It also looks like there's something not entirely right with the async
time out on Undertow, but I haven't nailed that one down yet.

Kind regards,
Arjan

_______________________________________________
undertow-dev mailing list
undertow-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev