[JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-4618:
---------------------------------
Fix Version/s: 10.0.0.Alpha4
> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
> Key: WFLY-4618
> URL: https://issues.jboss.org/browse/WFLY-4618
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (JBoss Web), Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Gernot Müller
> Assignee: Stuart Douglas
> Fix For: 10.0.0.Alpha4
>
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4618.
----------------------------------
Assignee: Stuart Douglas (was: Darran Lofthouse)
Resolution: Done
It is now possible to disable proactive auth in jboss-web.xml:
<proactive-authentication>false</proactive-authentication>
> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
> Key: WFLY-4618
> URL: https://issues.jboss.org/browse/WFLY-4618
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (JBoss Web), Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Gernot Müller
> Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFLY-4778) WebSocket connection failed because of Unexpected response code: 501
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4778?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4778:
--------------------------------------
I think this is more likely to be an atmosphere or vaadin issue, rather than a WF one. Have you tried with a newer version of Atmosphere?
> WebSocket connection failed because of Unexpected response code: 501
> --------------------------------------------------------------------
>
> Key: WFLY-4778
> URL: https://issues.jboss.org/browse/WFLY-4778
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Mike Mike
> Assignee: Stuart Douglas
>
> I am trying to use Wilfly 9 RC with Vaadins Server Push. The Push works but I get always following message in the java script log:
> Vaadin push loaded
> vaadinPush.js:21 WebSocket connection to 'ws://localhost:8080/abc-ui/PUSH/?v-uiId=0&v-csrfToken=9592bfe8-549f-4713-85b4-8ddae0163407&X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.0.3.vaadin2-jquery&X-Atmosphere-Transport=websocket&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application/json;%20charset=UTF-8' failed: Error during WebSocket handshake: Unexpected response code: 501
> vaadinPush.js:21 Websocket failed. Downgrading to Comet and resending
> The HTTP 501 (Not Implemented) is really irritating. Which side is implementing and who specifies?
> I found this topic related here: http://atmosphere-framework.2306103.n4.nabble.com/Websocket-Connection-Fa...
> Does anybody know here, if it is a bug in WildFly or atmosphere?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFLY-4589) java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4589?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4589:
--------------------------------------
Is is caused by Undertow not waiting for all the close messages to be received when it shuts down the deployment. The server starts shutting down and OnClose is invoked while the server is in an inconsistent state.
I have added some code to Undertow so it will attempt to wait for all the close messages to be received.
> java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4589
> URL: https://issues.jboss.org/browse/WFLY-4589
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.CR1
> Environment: java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
> cheffamille:wildfly-9.0.0.CR1 jfarcand$
> Reporter: Jeanfrancois Arcand
> Assignee: Stuart Douglas
> Priority: Minor
>
> Deploy atmosphere-chat.war (download it from Maven). Deploy, use WebSockets, then shutdown Wildfly 9.0.0.CR1
> 08:47:41,792 ERROR [io.undertow.websockets.jsr.request] (default task-17) UT026006: Exception running web socket method: java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
> at org.jboss.security.plugins.mapping.JBossMappingManager.getMappingContext(JBossMappingManager.java:67)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.setup(SecurityContextThreadSetupAction.java:110)
> at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42)
> at io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod(ServerWebSocketContainer.java:416)
> at io.undertow.websockets.jsr.ServerWebSocketContainer$3.run(ServerWebSocketContainer.java:403)
> at io.undertow.websockets.jsr.OrderedExecutor$ExecutorTask.run(OrderedExecutor.java:67)
> 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)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFLY-4429) Refactor JCA subsystems
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-4429?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen updated WFLY-4429:
----------------------------------
Description: Make use of PASSIVE services in :jca:, :datasources: and :resource-adapters: (was: Make use of PASSIVE services, and PersistentResource in :jca:, :datasources: and :resource-adapters:)
> Refactor JCA subsystems
> -----------------------
>
> Key: WFLY-4429
> URL: https://issues.jboss.org/browse/WFLY-4429
> Project: WildFly
> Issue Type: Task
> Components: JCA
> Reporter: Jesper Pedersen
> Assignee: Stefano Maestri
> Priority: Critical
> Fix For: 10.0.0.Alpha4
>
>
> Make use of PASSIVE services in :jca:, :datasources: and :resource-adapters:
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFCORE-671) Configuration change reporting
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-671?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-671:
------------------------------------------
Do you mean model write operations only ? Do you want to query the N operations done per user or globally ?
> Configuration change reporting
> ------------------------------
>
> Key: WFCORE-671
> URL: https://issues.jboss.org/browse/WFCORE-671
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 2.0.0.Beta1
>
>
> Allow administrators to view the last N (configurable) changes in the domain/server configurations made by other authorized administrators.
> Proper RBAC eliding of information should be done, a la what was done with the boot error reporting feature.
> I see this as being very similar to the boot error reporting.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFLY-4696) OutOfMemory DirectByteBuffer XNIO
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4696?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4696.
----------------------------------
Fix Version/s: 10.0.0.Alpha3
9.0.0.CR2
Resolution: Done
This should be fixed now, the buffer will be freed on exception
> OutOfMemory DirectByteBuffer XNIO
> ---------------------------------
>
> Key: WFLY-4696
> URL: https://issues.jboss.org/browse/WFLY-4696
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Carlos Rodríguez Aguado
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 10.0.0.Alpha3, 9.0.0.CR2
>
>
> I get this errors constantly in my server when a web connection is interrupted from the browser for instance:
> 11:50:45,301 ERROR [stderr] (default task-339) Exception in thread "default task-339" java.nio.BufferOverflowException
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:150)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpResponseConduit.java:629)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:205)
> 11:50:45,301 ERROR [stderr] (default task-339) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:201)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.lang.Thread.run(Thread.java:745)
> And then, I think this errors lead to a OutOfMemory crash:
> 14:23:09,592 ERROR [org.xnio.listener] (default I/O-3) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:143) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> I also have found that if I perform a full GC manually the server recovers, but it can not recover by itself, by performing other types of GCs.
> This is the trace for version 8.2 of WildFly:
> 17:17:16,957 ERROR [io.undertow.request] (default task-49) Undertow request failed HttpServerExchange{ GET /modulab/servlet/ShowPDFReportServlet}: java.nio.BufferOverflowException
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.put(ByteBuffer.java:859) [rt.jar:1.8.0_20]
> at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:166)
> at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:564)
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:106)
> at org.xnio.conduits.Conduits.writeFinalBasic(Conduits.java:132) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.writeFinal(AbstractFixedLengthStreamSinkConduit.java:175)
> at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:194)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.writeFinal(HttpServerExchange.java:1829)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:565)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:497)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:581)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:308)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> 10:57:12,389 ERROR [org.xnio.listener] (default I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:146) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.3.0.Final.jar:3.3.0.Final]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month