August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-854) Fallback to FORM authentication when an invalid kerberos token is used

by Derek Horton (JIRA)

[ https://issues.jboss.org/browse/SECURITY-854?page=com.atlassian.jira.plug... ] Derek Horton updated SECURITY-854: ---------------------------------- Assignee: Darran Lofthouse (was: Derek Horton) > Fallback to FORM authentication when an invalid kerberos token is used > ---------------------------------------------------------------------- > > Key: SECURITY-854 > URL: https://issues.jboss.org/browse/SECURITY-854 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Derek Horton > Assignee: Darran Lofthouse > > Negotiation will not fallback to FORM authentication if the client has a kerberos token from a different KDC than what JBoss is configured to use. > This results in the user getting presented with a 401 error and no way to login. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3468) Managed server shutdown unexpectedly when timeout during connection request to HC

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFLY-3468?page=com.atlassian.jira.plugin.... ] James Livingston edited comment on WFLY-3468 at 8/14/14 7:50 PM: ----------------------------------------------------------------- To reproduce: 1) Uncomment the debugging example for server-one in domain/configuration/host.xml 2) Run domain.sh, and connect your debugger (port 8787 out of box) 3) Either suspend the "main" thread and use Step Out, or put a breakpoint on the line after StreamUtils.readUTFZBytes() 4) Run "kill -STOP $SERVER_ONE_PID" to suspend the process 5) Wait until the HC reports ReadTimeoutException 6) Use "kill -CONT $SERVER_ONE_PID", and it will drop into the debugger 7) Suspend the HC process as above 8) Step over the calls until it enters client.reconnect() 9) After it times out contacting the HC, it will catch an IOException (ConnectException if you reproduce this way, but others can occur) 10) Resume the HC process and do whatever debugging you want was (Author: jameslivingston): To reproduce: 1) Uncomment the debugging example for server-one in domain/configuration/host.xml 2) Run domain.sh, and connect your debugger (port 8787 out of box) 3) Either suspect the "main" thread and use Step Out, or put a breakpoint on the line after StreamUtils.readUTFZBytes() 4) Run "kill -STOP $SERVER_ONE_PID" to suspend the process 5) Wait until the HC reports ReadTimeoutException 6) Use "kill -CONT $SERVER_ONE_PID", and it will drop into the debugger 7) Suspend the HC process as above 8) Step over the calls until it enters client.reconnect() 9) After it times out contacting the HC, it will catch an IOException (ConnectException if you reproduce this way, but others can occur) 10) Resume the HC process and do whatever debugging you want > Managed server shutdown unexpectedly when timeout during connection request to HC > --------------------------------------------------------------------------------- > > Key: WFLY-3468 > URL: https://issues.jboss.org/browse/WFLY-3468 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.Final > Reporter: Takayoshi Kimura > Assignee: Emanuel Muckenhuber > Priority: Minor > > Sometimes managed server shutdown unexpectedly when managed server tries to connect to the HC and got lengthly Full GC. > {quote} > java.io.IOException: JBAS012175: Channel closed > at org.jboss.as.server.mgmt.domain.HostControllerConnection.getChannel(HostControllerConnection.java:101) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:100) > at org.jboss.as.server.mgmt.domain.HostControllerConnection.reConnect(HostControllerConnection.java:171) > at org.jboss.as.server.mgmt.domain.HostControllerClient.reconnect(HostControllerClient.java:98) > at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:138) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:292) > at org.jboss.modules.Main.main(Main.java:455) > {quote} > The current DomainServerMain exits on the connetion error. > The scenario is: > # server tries to connect to the HC > # server Full GC > # HC is waiting a request from server, read timeout, closes the sock > # server resumed from GC, failed to send the req to the HC and exit -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3468) Managed server shutdown unexpectedly when timeout during connection request to HC

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFLY-3468?page=com.atlassian.jira.plugin.... ] James Livingston commented on WFLY-3468: ---------------------------------------- To reproduce: 1) Uncomment the debugging example for server-one in domain/configuration/host.xml 2) Run domain.sh, and connect your debugger (port 8787 out of box) 3) Either suspect the "main" thread and use Step Out, or put a breakpoint on the line after StreamUtils.readUTFZBytes() 4) Run "kill -STOP $SERVER_ONE_PID" to suspend the process 5) Wait until the HC reports ReadTimeoutException 6) Use "kill -CONT $SERVER_ONE_PID", and it will drop into the debugger 7) Suspend the HC process as above 8) Step over the calls until it enters client.reconnect() 9) After it times out contacting the HC, it will catch an IOException (ConnectException if you reproduce this way, but others can occur) 10) Resume the HC process and do whatever debugging you want > Managed server shutdown unexpectedly when timeout during connection request to HC > --------------------------------------------------------------------------------- > > Key: WFLY-3468 > URL: https://issues.jboss.org/browse/WFLY-3468 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.Final > Reporter: Takayoshi Kimura > Assignee: Emanuel Muckenhuber > Priority: Minor > > Sometimes managed server shutdown unexpectedly when managed server tries to connect to the HC and got lengthly Full GC. > {quote} > java.io.IOException: JBAS012175: Channel closed > at org.jboss.as.server.mgmt.domain.HostControllerConnection.getChannel(HostControllerConnection.java:101) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:100) > at org.jboss.as.server.mgmt.domain.HostControllerConnection.reConnect(HostControllerConnection.java:171) > at org.jboss.as.server.mgmt.domain.HostControllerClient.reconnect(HostControllerClient.java:98) > at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:138) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:292) > at org.jboss.modules.Main.main(Main.java:455) > {quote} > The current DomainServerMain exits on the connetion error. > The scenario is: > # server tries to connect to the HC > # server Full GC > # HC is waiting a request from server, read timeout, closes the sock > # server resumed from GC, failed to send the req to the HC and exit -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3697) Custom http handlers support

by Nicky Mølholm (JIRA)

[ https://issues.jboss.org/browse/WFLY-3697?page=com.atlassian.jira.plugin.... ] Nicky Mølholm commented on WFLY-3697: ------------------------------------- [~ctomc] Super - looking forward to see it on v9. I would like to volunteer for backporting the filtering functionality to v8.x - would that be possible? > Custom http handlers support > ---------------------------- > > Key: WFLY-3697 > URL: https://issues.jboss.org/browse/WFLY-3697 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > We need support for custom handlers & filters > something along the lines > {code:xml} > <handlers> > <handler name="myhandler" class="full.class.name" module"full.module.name" /> > <handlers> > <filters> > <filter name="myfilter" class="full.class.name" module"full.module.name" /> > <filters> > {code} > There should also be a way to pass in arbitrary config options -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3734) Misrepresentation of connection.createSession

by John Ament (JIRA)

John Ament created WFLY-3734: -------------------------------- Summary: Misrepresentation of connection.createSession Key: WFLY-3734 URL: https://issues.jboss.org/browse/WFLY-3734 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS Affects Versions: 8.1.0.Final Reporter: John Ament Assignee: Jeff Mesnil The current interpretation of connection.createSession(boolean,int) seems to be not handled correctly. passing in true,Session.TRANSACTED is being treated as Session.CLIENT_ACK. It should be created as connection.createSession() which should default to transaction if it's invoked within a JTA transaction. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-854) Fallback to FORM authentication when an invalid kerberos token is used

by Derek Horton (JIRA)

Derek Horton created SECURITY-854: ------------------------------------- Summary: Fallback to FORM authentication when an invalid kerberos token is used Key: SECURITY-854 URL: https://issues.jboss.org/browse/SECURITY-854 Project: PicketBox Issue Type: Bug Security Level: Public (Everyone can see) Components: Negotiation Reporter: Derek Horton Assignee: Derek Horton Negotiation will not fallback to FORM authentication if the client has a kerberos token from a different KDC than what JBoss is configured to use. This results in the user getting presented with a 401 error and no way to login. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-54) Add Keycloak authentication/authorization to http management endpoint

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/WFCORE-54?page=com.atlassian.jira.plugin.... ] Stan Silvert updated WFCORE-54: ------------------------------- Security: Public (was: Security Issue) > Add Keycloak authentication/authorization to http management endpoint > --------------------------------------------------------------------- > > Key: WFCORE-54 > URL: https://issues.jboss.org/browse/WFCORE-54 > Project: WildFly Core > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Stan Silvert > Assignee: Stan Silvert > Fix For: 1.0.0.Alpha5 > > > This is here to track the core changes needed for WFLY-3591. See that jira for details. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3716) Upgrade JAXB to 2.2.5.jboss-2 for bug fixes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3716?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3716: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1127326|https://bugzilla.redhat.com/show_bug.cgi?id=1127326] from POST to MODIFIED > Upgrade JAXB to 2.2.5.jboss-2 for bug fixes > ------------------------------------------- > > Key: WFLY-3716 > URL: https://issues.jboss.org/browse/WFLY-3716 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: XML Frameworks > Reporter: Paul Gier > Assignee: Paul Gier > > Upgrade jaxb to 2.2.5.jboss-2 to include some bug fixes. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-53) Include registered attributes with no model representation in read-resource results

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-53?page=com.atlassian.jira.plugin.... ] Emmanuel Hugonnet moved WFLY-202 to WFCORE-53: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-53 (was: WFLY-202) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Alpha5 (was: 9.0.0.CR1) > Include registered attributes with no model representation in read-resource results > ----------------------------------------------------------------------------------- > > Key: WFCORE-53 > URL: https://issues.jboss.org/browse/WFCORE-53 > Project: WildFly Core > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha5 > > > Following situation: > 1) resource includes attribute xyz > 2) No read-handler is registered for xyz (i.e. default read semantic Resource.getModel().get("xyz") is to be used) > 3) Poorly coded "add" handler for the resource doesn't call model.get("xyz") for some reason. > The effect of this is the read-resource result will not include "xyz" => undefined in the output. Nothing for xyz will appear at all, hiding the existence of the attribute from the caller. > The read-resource handler can deal with a check in its loop through the AttributeAccess registration for the "no read-handler" case. (This check is already there; an 'else' clause is needed.) If no read-handler, see if there is an entry in the directAttributes map for the attribute; if not, add one with a value of new ModelNode(). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-52) Create alternative to /core-service=module-loading:list-resource-loader-paths for identifying what module a jar came from

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-52: -------------------------------------- Summary: Create alternative to /core-service=module-loading:list-resource-loader-paths for identifying what module a jar came from Key: WFCORE-52 URL: https://issues.jboss.org/browse/WFCORE-52 Project: WildFly Core Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry The /core-service=module-loading:list-resource-loader-paths used to be a mechanism for identifying from what module a resource was loaded, because the path would point the the module. GSS made use of that for analyzing where things come from in a situation with multiple module roots (e.g. a layered product.) But with the addition in module.xml of the "artifact" element alternative to the "resource" element, the returned path may no longer point to the module; it may point to a maven repo path. So we need some other API method to meet the use case of identifying from what module root a module was loaded. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014