Memory leak in undertow 1.3.11.Final
by Marc Boorshtein
I have undertow embedded into my application and for the most part its
working great, but unfortunately I've found a memory leak. The application
its self creates an Undertow server using SSL and then adds servlets and
filters. There are no custom handlers.
Throughout the logs I get the following NPEs:
2016-01-14 09:50:04,681][XNIO-2 task-28] ERROR request - UT005071: Undertow
request failed HttpServerExchange{ GET /wp-content/themes/Nexus/style.css
request {Accept=[text/css, */*], Connection=[Keep-Alive],
Accept-Language=[en-US,en;q=0.5], Accept-Encoding=[gzip, deflate],
Cookie=[nowwwsession=eyJpdiI6Ik5hV0xCWWR5VExzUEEzRTBVNUFKUkFcdTAwM2RcdTAwM2QiLCJlbmNyeXB0ZWRSZXF1ZXN0IjoiS2t0TENaVGZFb1NWNjlyVXB4aUxuQ2RHRmlTZzVDWm0veTFXLytXWlBQMEhpMDZKK3FaQWpQYnBGY0RnMW15RCJ9;
nvers-prod-session=eyJpdiI6Ikd2Wk5oTDVGbjdSTElGejlQSzFsalFcdTAwM2RcdTAwM2QiLCJlbmNyeXB0ZWRSZXF1ZXN0IjoiN2VldzBiT1lIWkZNaVgwTzV5b2tUSVNnaWwzTC9tRHpmeEdDOFZiQzh2a1RZN29ScElqbHFyZys3dmZMWUNhRSJ9],
Referer=[https://www.nvers.org/the-team/], User-Agent=[Mozilla/5.0 (Windows
NT 10.0; Trident/7.0; MALC; rv:11.0) like Gecko], Host=[www.nvers.org]}
response {Connection=[close], Last-Modified=[Thu, 26 Mar 2015 18:45:16
GMT], Server=[Apache/2.2.15 (CentOS)], Content-Type=[text/css],
Content-Language=[en-US], Accept-Ranges=[bytes], Date=[Thu, 14 Jan 2016
14:37:10 GMT]}}
java.lang.NullPointerException
at
io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpResponseConduit.java:713)
at
io.undertow.conduits.FinishableStreamSinkConduit.flush(FinishableStreamSinkConduit.java:83)
at
org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at
io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
at
io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:609)
at
io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:476)
at
io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:560)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Also, I see the following in System.out:
Exception in thread "XNIO-2 task-18" java.lang.NullPointerException
at
io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:605)
at
io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:267)
at
org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at
io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at
io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1652)
at
io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1630)
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:226)
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
After taking a heap dump and analyzing, I'm finding that a single thread is
holding all the objects:
The thread *org.xnio.nio.WorkerThread @ 0xc48cac70 XNIO-2 I/O-4* keeps
local variables with total size *578,543,888 (95.77%)* bytes.
The memory is accumulated in one instance of *"java.lang.Object[]"* loaded
by *"<system class loader>"*.
XNIO-2 I/O-4
at
sun.security.ssl.SSLEngineImpl.unwrap(Ljava/nio/ByteBuffer;[Ljava/nio/ByteBuffer;II)Ljavax/net/ssl/SSLEngineResult;
(SSLEngineImpl.java:781)
at
io.undertow.protocols.ssl.SslConduit.doUnwrap([Ljava/nio/ByteBuffer;II)J
(SslConduit.java:682)
at io.undertow.protocols.ssl.SslConduit.read(Ljava/nio/ByteBuffer;)I
(SslConduit.java:525)
at
org.xnio.conduits.ConduitStreamSourceChannel.read(Ljava/nio/ByteBuffer;)I
(ConduitStreamSourceChannel.java:127)
at
io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(Lorg/xnio/conduits/ConduitStreamSourceChannel;)V
(HttpReadListener.java:149)
at
io.undertow.server.protocol.http.HttpReadListener.handleEvent(Lorg/xnio/conduits/ConduitStreamSourceChannel;)V
(HttpReadListener.java:127)
at
io.undertow.server.protocol.http.HttpReadListener.handleEvent(Ljava/nio/channels/Channel;)V
(HttpReadListener.java:56)
at
org.xnio.ChannelListeners.invokeChannelListener(Ljava/nio/channels/Channel;Lorg/xnio/ChannelListener;)Z
(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady()V
(ReadReadyHandler.java:66)
at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady()V
(SslConduit.java:1054)
at io.undertow.protocols.ssl.SslConduit$1.run()V (SslConduit.java:225)
at org.xnio.nio.WorkerThread.safeRun(Ljava/lang/Runnable;)V
(WorkerThread.java:580)
at org.xnio.nio.WorkerThread.run()V (WorkerThread.java:464)
Any help would be appreciated. We didn't have any memory leak issues with
Jetty which is what we used prior so I don't think its an issue with our
internal code triggering this.
Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein(a)tremolosecurity.com
<marc.boorshtein(a)tremolosecurity.com>
8 years, 3 months
Help embedding undertow and TLS
by Marc Boorshtein
I'm trying to replace Jetty 7 with with Undertow 1.3.11.Final. In Jetty 7
I was able to create an
org.eclipse.jetty.util.ssl.SslContextFactory that let me:
1. determine if client auth is needed, allowed or required
2. disable sslv3
3. enable only certain ciphers
Looking at undertow I see that I can use Undertow.addHttpsListener with an
SSLContext but I don't see how set client auth, ciphers, etc.
Any help would be greatly appreciated.
Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein(a)tremolosecurity.com
<marc.boorshtein(a)tremolosecurity.com>
8 years, 3 months
SSE Close Task
by Fabian Mager
Hey,
I am using Undertow 1.3.11.Final and have problems with SSE connections
closed by the client. I already found
https://issues.jboss.org/browse/UNDERTOW-589 but I cannot observe that
behavior. It doesn't matter how many messages I send after the client
closed the connection, the close task is never called.
Another issue is the send(String data, EventCallback callback) function
from ServerSentEventConnection. The callback allows me to specify a
done(...) and failed(...) method that is called either when the data was
successfully submitted or not. In case it was, done(...) gets correctly
called but in case the client already closed the connection then I
assume failed(...) should be called but it gets never called.
I would appreciate any help in case I missed some things.
Cheers,
Fabian
8 years, 3 months
embedded undertow async hello world
by seth/nqzero
i'm doing a quick survey of java webserver performance baselines, with a
focus on async, inspired somewhat by the Techempower plaintext benchmark.
i've already done jetty (both sync and async), jetty-comsat (ie quasar),
the kilim (another bytecode based fiber implementation) http server, and
sync undertow (copied from the techempower github impl). i'd like to add an
undertow async
for jetty i've used the servlet api for async, since i didn't see any other
option. but i'd prefer the non-servlet api for undertow. the docs for
undertow seem limited, esp for async. so i wanted to vet my solution. i'm
more interested in being canonical than squeezing the last bit of
performance (because eg: all the solutions are plenty fast, it's a terrible
benchmark, ease of implementation is a bigger factor than absolute
performance)
open to any general comments, but specifically wondering:
- is my use of dispatch() correct
- do i need to be calling isInIoThread()
- is it safe to access the exchange directly in reply() ? ie, in a
non-undertow thread
this is a somewhat simplified example that gets 75-80k req/s vs 85-90 for
the more verbose version, but the use of the async api is the same
____my code is below___
import io.undertow.Handlers;
import io.undertow.Undertow;
import io.undertow.server.HttpHandler;
import io.undertow.server.HttpServerExchange;
import io.undertow.util.Headers;
import java.nio.ByteBuffer;
import java.util.Timer;
import java.util.TimerTask;
public final class UtowAsync implements HttpHandler {
public static void main(String[] args) throws Exception {
Undertow.builder()
.addHttpListener(9097,"0.0.0.0")
.setHandler(Handlers.path().addPrefixPath("/hello",new UtowAsync()))
.build()
.start();
}
int num = 0;
HttpServerExchange acv[] = new HttpServerExchange[10000];
byte [] bytes = "hello world".getBytes();
ByteBuffer buf = ByteBuffer.allocate(bytes.length).put(bytes);
{ buf.flip(); }
synchronized void store(HttpServerExchange async) {
if (async==null) while (num > 0) {
reply(acv[--num]);
acv[num] = null;
}
else acv[num++] = async;
}
void reply(HttpServerExchange exchange) {
exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
"text/plain");
exchange.getResponseSender().send(buf.duplicate());
}
public void handleRequest(final HttpServerExchange exchange) throws
Exception {
store(exchange);
exchange.dispatch();
}
{
new Timer().schedule(new TimerTask() { public void run() {
UtowAsync.this.store(null);
} },10,10);
}
}
8 years, 4 months
Re: [undertow-dev] Multiple logins under same user id in Wildfly 9.0.2 uses same subject
by arjan tijms
Hi,
On Thu, Jan 7, 2016 at 3:51 PM, Sony Abraham <sony.abraham(a)ibsplc.com>
wrote:
> Hi Arjan,
>
>
>
> Thanks again for your support and guidance.
>
>
>
> I have put my SAM module (jar) inside ear/lib.
>
If the SAM resides within the application then modifying standalone.xml is
not needed. A reference to a SAM in standalone.xml is only really needed if
the SAM is separate from the application, e.g. resides in a jar that you
put somewhere in the /modules folder of WildFly.
In this case you can just as well use the programmatic registration via a
listener as demonstrated by the samples.
> Also I am facing the below issues, when I try to access a protected
> resource, I want redirect to my login page. For this I have mentioned the
> login.jsp in the web.xml as below
>
> <login-config>
>
>
> <auth-method>FORM</auth-method>
>
>
> <form-login-config>
>
>
> <form-login-page>/login.jsp</form-login-page>
>
>
> <form-error-page>/login.jsp</form-error-page>
>
> </form-login-config>
>
> </login-config>
>
> But this is not happening automatically, I had to explicitly do
> response.sendRedirect to get my login page (otherwise “Unauthorized” error
> was coming). Is this the right thing to do ?
>
This is unfortunately not correct. A SAM is an authenticated mechanism, not
an identity store. So it replaces FORM. In other words the
entire login-config element can be removed here as its overridden when
using a SAM.
> After I provide my username / password and do j_security_check I am
> getting below error. Can you please let me know what I would had done wrong
>
j_security_check is the name in the URL that the build-in FORM
authentication mechanism happens to be listening to. j_security_check is
not some general mechanism by which security in Java EE is activated.
There is clearly a mismatch in Java EE security. There are build-in
authentication mechanisms and a standard API for custom authentication
mechanisms, but no standard API for the identity store (the artifact that
only focuses on {credentials in, caller data out}).
What's typical though here is building a SAM that only redirects to a login
page when a protected resource is requested and the user is not
authenticated, and otherwise relies on Servlet's programmatic authenticate
feature. So on /login.jsp you don't postback to a special URL, but post
back to /login.jsp. Then backing code of /login.jsp sets the credentials as
a request attribute and then calls HttpServletRequest.authenticate(). The
SAM can then do the authentication as shown in the samples.
Another option would be to re-use an existing authentication module that
implements FORM and then modify the part where it calls to the server
specific identity store. See e.g.
https://github.com/eclipse/jetty.project/blob/master/jetty-jaspi/src/main...
of
http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/...
(do take the license into account of these and take note that you may have
to do your own scrutiny of how secure those are)
If you absolutely want or need to use the existing build-in FORM, then
unfortunately JASPIC would not be the best option here. Unfortunately
setting up (custom) security in Java EE is currently not entirely trivial.
Kind regards,
Arjan Tijms
> *HTTP method POST is not supported by this URL*
>
>
>
> Regards
>
> Sony
>
>
>
> *From:* arjan tijms [mailto:arjan.tijms@gmail.com]
> *Sent:* 07 January 2016 18:29
> *To:* Sony Abraham
>
> *Subject:* Re: [undertow-dev] Multiple logins under same user id in
> Wildfly 9.0.2 uses same subject
>
>
>
> Hi,
>
>
>
> On Thu, Jan 7, 2016 at 8:10 AM, Sony Abraham <sony.abraham(a)ibsplc.com>
> wrote:
>
>
>
> Thank you for your reply. I am complete new to SAMPIC, do you have any
> sample implementation for custom JASPIC on wildfly that I can refer to ?
>
>
>
> Yes, there about 12 categories of samples for JASPIC here:
> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>
>
>
> The simplest sample can be found in
> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/basi...
>
>
>
> A very basic but fully working standalone application can be found here:
> https://github.com/arjantijms/mechanism-to-store
>
>
>
>
>
> I read though your blog
> http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentic...
> and
> http://arjan-tijms.omnifaces.org/2013/04/whats-new-in-java-ee-7s-authenti...
> , but configuring the SAM module alone in standalone.xml and mentioning
> that in jboss-web.xml invoked my login module. Could not exactly understand
> why the factory and context classes were required ( I assume those
> implementations are provided by jboss itself)
>
>
>
> The factory/config/context classes are there for when a fully in-app
> portable application archive is needed. The only standardised way to
> register a SAM is the programmatic way. The initial factory doesn't have a
> method that just takes a SAM, but instead wants all these wrapper classes.
> In hindsight this was perhaps not the most ideal decision and we hope to be
> able to rectify this in the Java EE security EG.
>
>
>
> The non-standard way, in this case the JBoss specific way via
> standalone.xml, does accept just a SAM. In that case the wrappers are
> indeed provided by JBoss.
>
>
>
>
>
> But it’s been invoked for all resources (even non secure resources)
>
>
>
> That's correct. JASPIC authentication modules are invoked for every
> resource, both secured (protected) and non-secured (public). Authentication
> is also not automatically tied to a session. Coming from some other
> proprietary mechanisms this may seem controversial, but it actually makes
> it really flexible and makes the creation of e.g. stateless header based
> authentication mechanisms trivial. See e.g.
> http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
>
>
>
> You can check whether the SAM *must* do authentication (which includes
> being called for a secured resource) via a helper method such as:
>
>
>
> public static boolean isProtectedResource(MessageInfo messageInfo) {
>
> return Boolean.valueOf((String) messageInfo.getMap().get(IS_MANDATORY));
>
> }
>
>
>
>
>
> and the values in the handler and MessagePolicy are all coming as null.
>
>
>
> That doesn't seem right. Perhaps this is a bug when registering a SAM via
> the standalone.xml method. Where did you put
> the com.test.TestServerAuthModule class? Is it inside a .jar that you put
> in your WildFly install (and if so, where?), or is this class inside your
> application archive (.war)?
>
>
>
> Kind regards,
>
> Arjan Tijms
>
>
>
>
>
>
>
>
>
> How can I configure the container not to invoke the SAM for non-secure
> resources and why is the handler and MessagePolicy coming as null ?
>
>
>
> My standalone.xml entry is as below
>
> <security-domain name="test" cache-type="default">
>
> <authentication-jaspi>
>
> <auth-module
> code="com.test.TestServerAuthModule" flag="optional"/>
>
> </authentication-jaspi>
>
> </security-domain>
>
>
>
> And jboss-web.xml as below
>
>
>
> <jboss-web>
>
> <security-domain>test</security-domain>
>
> </jboss-web>
>
>
>
> Regards,
>
> Sony
>
>
>
> *From:* arjan tijms [mailto:arjan.tijms@gmail.com]
> *Sent:* 05 January 2016 23:03
> *To:* Sony Abraham
> *Cc:* undertow-dev(a)lists.jboss.org
> *Subject:* Re: [undertow-dev] Multiple logins under same user id in
> Wildfly 9.0.2 uses same subject
>
>
>
> Hi,
>
>
>
> I remember that in older versions of JBoss there always was a
> (proprietary) API to explicitly clear the authentication cache. Maybe this
> could be of help here if that API is still there.
>
>
>
> An other option would be to try using the Java EE standard API for custom
> authentication modules. This is called JASPIC and WildFly has excellent
> support for those. Support is best in the latest version of WildFly, which
> is 10cr5.
>
>
>
> Kind regards,
>
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Jan 5, 2016 at 9:18 AM, Sony Abraham <sony.abraham(a)ibsplc.com>
> wrote:
>
> Hi,
>
>
>
> I am trying to port our existing application (in weblogic) to Jboss
> wildfly.
>
>
>
> Our application supports multiple logins under same user id but each
> logins need to be treated in different security context. For this we invoke
> the login modules by invoking j_security_check for each logins attempts. We
> use a custome Jaas login module from where the subject is created with a
> unique user token and set as name of the Principal after successful login.
> But when using wildfly, the login module is invoked only the first time and
> for the subsequent login attempts, the user subject is looked up from the
> domain cache inside JBossCachedAuthenticationManager.
>
>
>
> Further debugging into the issue i noticed below
>
> 1. After jaas login completes, the
> org.wildfly.extension.undertow.security.AccountImpl in exchange of
> ServletRequest gets updated with the new Principal (token set during jaas
> login) and the OriginalPrincipal remains the same as the user id. This is
> fine as expected (I hope).
>
> 2. org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(final
> AccountImpl account, final Object credential) uses the OriginalPrincipal to
> send to authenticationManager for validation. Since this is not updated, it
> will always be the original user id. Below source code from jboss.as
> uses account.getPrincipal() for getting the incomingPrincipal. But this
> is now changed to getOriginalPrincipal. I think this should be the
> principal (not the OriginalPrincipal).
>
> 3. org.jboss.security.authentication.JBossCachedAuthenticationManager
> caches the subject info against the OriginalPrincipal. Therefor it always
> returns from the cache after the first successful authentication for a user
> id and JAAS login module is never invoked after that. Shouldn't the caching
> happen against the authenticated principal set in the subject
> (CallerPrincipal).
>
>
>
> Can anyone please let me know whether this behavior change is possible ?
> Or is there any way I can configure custom class for
> org.wildfly.extension.undertow.security.JAASIdentityManagerImpl and
> org.jboss.security.authentication.JBossCachedAuthenticationManager in
> wildfly 9.0.2.
>
>
>
> Regards
>
> Sony
>
>
>
>
>
> DISCLAIMER: "The information in this e-mail and any attachment is
> intended only for the person to whom it is addressed and may contain
> confidential and/or privileged material. If you have received this e-mail
> in error, kindly contact the sender and destroy all copies of the original
> communication. IBS makes no warranty, express or implied, nor guarantees
> the accuracy, adequacy or completeness of the information contained in this
> email or any attachment and is not liable for any errors, defects,
> omissions, viruses or for resultant loss or damage, if any, direct or
> indirect."
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
>
>
> DISCLAIMER: "The information in this e-mail and any attachment is
> intended only for the person to whom it is addressed and may contain
> confidential and/or privileged material. If you have received this e-mail
> in error, kindly contact the sender and destroy all copies of the original
> communication. IBS makes no warranty, express or implied, nor guarantees
> the accuracy, adequacy or completeness of the information contained in this
> email or any attachment and is not liable for any errors, defects,
> omissions, viruses or for resultant loss or damage, if any, direct or
> indirect."
>
>
>
>
> DISCLAIMER: "The information in this e-mail and any attachment is
> intended only for the person to whom it is addressed and may contain
> confidential and/or privileged material. If you have received this e-mail
> in error, kindly contact the sender and destroy all copies of the original
> communication. IBS makes no warranty, express or implied, nor guarantees
> the accuracy, adequacy or completeness of the information contained in this
> email or any attachment and is not liable for any errors, defects,
> omissions, viruses or for resultant loss or damage, if any, direct or
> indirect."
>
8 years, 4 months
Multiple logins under same user id in Wildfly 9.0.2 uses same subject
by Sony Abraham
Hi,
I am trying to port our existing application (in weblogic) to Jboss wildfly.
Our application supports multiple logins under same user id but each logins need to be treated in different security context. For this we invoke the login modules by invoking j_security_check for each logins attempts. We use a custome Jaas login module from where the subject is created with a unique user token and set as name of the Principal after successful login. But when using wildfly, the login module is invoked only the first time and for the subsequent login attempts, the user subject is looked up from the domain cache inside JBossCachedAuthenticationManager.
Further debugging into the issue i noticed below
1. After jaas login completes, the org.wildfly.extension.undertow.security.AccountImpl in exchange of ServletRequest gets updated with the new Principal (token set during jaas login) and the OriginalPrincipal remains the same as the user id. This is fine as expected (I hope).
2. org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(final AccountImpl account, final Object credential) uses the OriginalPrincipal to send to authenticationManager for validation. Since this is not updated, it will always be the original user id. Below source code from jboss.as uses account.getPrincipal() for getting the incomingPrincipal. But this is now changed to getOriginalPrincipal. I think this should be the principal (not the OriginalPrincipal).
[cid:image001.png@01D147BF.BB5A7BD0]
3. org.jboss.security.authentication.JBossCachedAuthenticationManager caches the subject info against the OriginalPrincipal. Therefor it always returns from the cache after the first successful authentication for a user id and JAAS login module is never invoked after that. Shouldn't the caching happen against the authenticated principal set in the subject (CallerPrincipal).
Can anyone please let me know whether this behavior change is possible ? Or is there any way I can configure custom class for org.wildfly.extension.undertow.security.JAASIdentityManagerImpl and org.jboss.security.authentication.JBossCachedAuthenticationManager in wildfly 9.0.2.
Regards
Sony
DISCLAIMER: "The information in this e-mail and any attachment is intended only for the person to whom it is addressed and may contain confidential and/or privileged material. If you have received this e-mail in error, kindly contact the sender and destroy all copies of the original communication. IBS makes no warranty, express or implied, nor guarantees the accuracy, adequacy or completeness of the information contained in this email or any attachment and is not liable for any errors, defects, omissions, viruses or for resultant loss or damage, if any, direct or indirect."
8 years, 4 months
UNDERTOW-577 - response code from SAM
by arjan tijms
Hi,
I wonder if it would make sense to port the (small) fix for UNDERTOW-577
back to Undertow 1.3.x, and hopefully still include this with WF 10 final.
This concerns one of the last (known) larger bugs with JASPIC in WildFly.
Without this being fixed, something like the 403 or 404 from a SAM is not
possible, Returning a 403 is specifically needed for the BASIC scheme.
For instance, the following JSR 375 authentication mechanism now works on
GlassFish, but throws a "UT010019: Response already commited" on WildFly
10rc4/Undertow 1.3.11:
public AuthStatus validateRequest(HttpServletRequest request,
HttpServletResponse response, HttpMsgContext httpMsgContext) throws
AuthException {
String[] credentials = getCredentials(request);
if (!isEmpty(credentials)) {
IdentityStore identityStore =
CDI.current().select(IdentityStore.class).get();
CredentialValidationResult result = identityStore.validate(
new UsernamePasswordCredential(credentials[0], new
Password(credentials[1])));
if (result.getStatus() == VALID) {
return httpMsgContext.notifyContainerAboutLogin(
result.getCallerName(), result.getCallerGroups());
}
}
if (httpMsgContext.isProtected()) {
response.setHeader("WWW-Authenticate", basicHeaderValue);
return httpMsgContext.responseUnAuthorized();
}
return httpMsgContext.doNothing();
}
The problem is the "httpMsgContext.responseUnAuthorized();" which does:
try {
getResponse().sendError(SC_UNAUTHORIZED);
} catch (IOException e) {
throw new IllegalStateException(e);
}
return SEND_FAILURE;
I'm not really sure what the schedule is for Undertow 1.4 vs a potential WF
11 and/or EAP 7. If WF 11 is still far away and EAP 7 will be based on WF
10, then it would really be great if this small but rather important fix
could still be included in WF 10.
Kind regards,
Arjan Tijms
8 years, 4 months
