July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6776) Unclear error message when creating multiple thread pools of the same type for a workmanager

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-6776?page=com.atlassian.jira.plugin.... ] Lin Gao commented on WFLY-6776: ------------------------------- Done in commit: https://github.com/gaol/wildfly/commit/65f36600689bd8ac2b60c4491893457fdf..., will fire the PR once the main WildFly consumes master branch(3.0.x) of WildFly Core. > Unclear error message when creating multiple thread pools of the same type for a workmanager > -------------------------------------------------------------------------------------------- > > Key: WFLY-6776 > URL: https://issues.jboss.org/browse/WFLY-6776 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.0.0.Final > Reporter: Lin Gao > Assignee: Lin Gao > > When there is already a long-running thread pool for a work manager and you try to create another one: > {{/subsystem=jca/workmanager=default/long-running-threads=custom:add(max-threads=30, queue-length=30)}} > you only get an opaque error message: > {{"failure-description" => "WFLYCTL0086: Failed to persist configuration change: WFLYCTL0084: Failed to marshal configuration",}} with a, also useless, {{java.lang.IllegalArgumentException}} in the server log. > It should be more obvious that the error is that you cannot create two long-running thread pools -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6782) Unable to add JGroups protocol at a given index via CLI

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/WFLY-6782?page=com.atlassian.jira.plugin.... ] Ladislav Thon edited comment on WFLY-6782 at 7/14/16 2:14 AM: -------------------------------------------------------------- This is very nice, thanks! What would be even better IMHO is an ability to add a protocol into the stack _before_ or _after_ a given protocol. Something like {{/subsystem=jgroups/stack=udp/protocol=XXX:add(before-protocol=pbcast.GMS)}}. With {{add-index}}, I first have to compute the correct index, which is unfriendly, error-prone and can change in time. EDIT: I see that this is only one of multiple JIRAs that cover this functionality. If you think I should add the comment to a different JIRA or open a whole new JIRA, I'd gladly do so. was (Author: lthon): This is very nice, thanks! What would be even better IMHO is an ability to add a protocol into the stack _before_ or _after_ a given protocol. Something like {{/subsystem=jgroups/stack=udp/protocol=XXX:add(before-protocol=pbcast.GMS)}}. With {{add-index}}, I first have to compute the correct index, which is unfriendly, error-prone and can change in time. > Unable to add JGroups protocol at a given index via CLI > ------------------------------------------------------- > > Key: WFLY-6782 > URL: https://issues.jboss.org/browse/WFLY-6782 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.1.Final, 9.0.2.Final, 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 10.1.0.Final > > > Unable to use this via CLI, tests pass since they use management client which won't check against the operation description: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add(add-index=4) > 'add-index' is not found among the supported properties: [socket-binding, module, properties, type] > {noformat} > add index is missing in the description, after the fix: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=MPING:read-operation-description(name=add > { > "outcome" => "success", > "result" => { > "operation-name" => "add", > "description" => "Add a protocol to a protocol stack.", > "request-properties" => { > "add-index" => { > "type" => INT, > "description" => "If specified inserts the protocol at the given (zero-based) index. If null it will add at the end.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true > }, > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6782) Unable to add JGroups protocol at a given index via CLI

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/WFLY-6782?page=com.atlassian.jira.plugin.... ] Ladislav Thon commented on WFLY-6782: ------------------------------------- This is very nice, thanks! What would be even better IMHO is an ability to add a protocol into the stack _before_ or _after_ a given protocol. Something like {{/subsystem=jgroups/stack=udp/protocol=XXX:add(before-protocol=pbcast.GMS)}}. With {{add-index}}, I first have to compute the correct index, which is unfriendly, error-prone and can change in time. > Unable to add JGroups protocol at a given index via CLI > ------------------------------------------------------- > > Key: WFLY-6782 > URL: https://issues.jboss.org/browse/WFLY-6782 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.2.1.Final, 9.0.2.Final, 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 10.1.0.Final > > > Unable to use this via CLI, tests pass since they use management client which won't check against the operation description: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add(add-index=4) > 'add-index' is not found among the supported properties: [socket-binding, module, properties, type] > {noformat} > add index is missing in the description, after the fix: > {noformat} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=MPING:read-operation-description(name=add > { > "outcome" => "success", > "result" => { > "operation-name" => "add", > "description" => "Add a protocol to a protocol stack.", > "request-properties" => { > "add-index" => { > "type" => INT, > "description" => "If specified inserts the protocol at the given (zero-based) index. If null it will add at the end.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true > }, > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5739) Subject not populated with groups/roles when authenticated via JASPIC

by arjan tijms (JIRA)

[ https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin.... ] arjan tijms commented on WFLY-5739: ----------------------------------- {quote}I have just sent PR https://github.com/wildfly/wildfly/pull/9003 that fixes it (for me){quote} I think you meant https://github.com/wildfly/wildfly/pull/9030 ;) I checked the latest change and it looks quite good, but I must say I'm also not the WildFly internals specialist. But indeed, because registerSession is handled in the {{AuthenticationMechanism}}, it makes much more sense that the handler only uses one approach to set the groups/roles data, and then the mechanism copies this to all other places. Perhaps it would be even cleaner if the handler only stored the raw data as set by the SAM via the callbacks in a private simple TLS variable, and then let the authentication mechanism install that in the 3 places you identified (i.e. including {{JbossSecurityContext}}). Now there may be the small weirdness that after calling the handler, but before returning from {{validateRequest}} the caller is sort of partially authenticated. But alas, that's unrelated to this particular PR. Those 3 places to store the authentication data have been a frequent source of bugs. More than a handful of previous bugs has been related to those 3 not being kept in perfect sync. (This is incidentally also why for JSR 375 I really didn't want to introduce a JSR 375 specific place to store this same data, as it would mean yet another location that can get out of sync with whatever the container is using.) I would like to thank the both of you again for helping out with these issues. Great work ;) > Subject not populated with groups/roles when authenticated via JASPIC > --------------------------------------------------------------------- > > Key: WFLY-5739 > URL: https://issues.jboss.org/browse/WFLY-5739 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.CR4 > Reporter: Arjan t > Assignee: Darran Lofthouse > Labels: jacc, jaspic > Attachments: CustomAuth.zip, picketbox.zip > > > After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails. > For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role: > {code:java} > Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container"); > > boolean hasAccess = Policy.getPolicy().implies( > new ProtectionDomain( > new CodeSource(null, (Certificate[]) null), > null, null, > subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()]) > ), > new WebResourcePermission("/protected/Servlet", "GET")) > ; > {code} > As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles. > This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject": > {code:java} > String[] rolesArray = groupPrincipalCallback.getGroups(); > int sizeOfRoles = rolesArray != null ? rolesArray.length : 0; > > if( sizeOfRoles > 0 ) > { > List<Role> rolesList = new ArrayList<Role>(); > for( int i = 0; i < sizeOfRoles ; i++ ) > { > Role role = new SimpleRole( rolesArray[ i ] ); > rolesList.add( role ); > } > RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList ); > // if the current security context already has roles, we merge them with the incoming roles. > RoleGroup currentRoles = currentSC.getUtil().getRoles(); > // *** ROLES ARE ONLY SET HERE *** > if (currentRoles != null) { > currentRoles.addAll(roles.getRoles()); > } > else { > currentSC.getUtil().setRoles( roles ); > } > } > // *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE > // *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO > Subject subject = groupPrincipalCallback.getSubject(); > if( subject != null ) > { > // if the current security context already has an associated subject, we merge it with the incoming subject. > Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject(); > if (currentSubject != null) { > subject.getPrincipals().addAll(currentSubject.getPrincipals()); > subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials()); > subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials()); > } > currentSC.getSubjectInfo().setAuthenticatedSubject(subject); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6833) Upgrade JBossWS to 5.1.5.Final

by Alessio Soldano (JIRA)

Alessio Soldano created WFLY-6833: ------------------------------------- Summary: Upgrade JBossWS to 5.1.5.Final Key: WFLY-6833 URL: https://issues.jboss.org/browse/WFLY-6833 Project: WildFly Issue Type: Component Upgrade Components: Web Services Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 10.1.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6817) JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6817?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-6817: -------------------------------------- Assignee: Aaron Ogburn (was: Stuart Douglas) > JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6817 > URL: https://issues.jboss.org/browse/WFLY-6817 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > Fix For: 10.1.0.Final > > Attachments: standalone.xml > > > JASPICSecureResponseHandler.handleRequest can throw a NPE for a redirect from a CONFIDENTIAL transport guarantee: > {code} > java.lang.NullPointerException > at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:35) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) > 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) > {code} > This occurs because io.undertow.security.handlers.AbstractConfidentialityHandler generates the redirect before any JASPICContext is placed on the request, so JASPICSecureResponseHandler sees the null. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6416) CVE-2015-0254: XXE and RCE via XSL extension in JSTL XML tags

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6416?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-6416: --------------------------------- Assignee: Tomaz Cerar (was: Jason Greene) > CVE-2015-0254: XXE and RCE via XSL extension in JSTL XML tags > -------------------------------------------------------------- > > Key: WFLY-6416 > URL: https://issues.jboss.org/browse/WFLY-6416 > Project: WildFly > Issue Type: Bug > Components: XML Frameworks > Affects Versions: 10.0.0.Final > Environment: Testing with OpenJDK 1.8.0_73 > Reporter: Jason Shepherd > Assignee: Tomaz Cerar > > When an application uses <x:parse> or <x:transform> tags to process untrusted XML documents, a request may utilize external entity references to access resources on the host system or utilize XSLT extensions that may allow remote execution. > Red Hat Flaw bug: https://bugzilla.redhat.com/show_bug.cgi?id=1198606 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1652) Server.log should include applied patches related information on startup

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created WFCORE-1652: ----------------------------------------- Summary: Server.log should include applied patches related information on startup Key: WFCORE-1652 URL: https://issues.jboss.org/browse/WFCORE-1652 Project: WildFly Core Issue Type: Feature Request Components: Patching , Server Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 3.0.0.Alpha4 Users would appreciate seeing information about the patching state of the installation in the startup log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1590) Default parameter length validating ignores setMinSize(0)

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1590?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1590: ------------------------------------------ This is a borderline RFE, as it's not clear how this functionality can consistently be provided. In the end the AD needs to call the user provided validator, and if that isn't configured correctly it will reject things regardless of how setMinSize()/setMaxSize() are set on the AD. For allowNull and allowExpressions we can get around that by not calling the provided validator for undefined or expression values but if there's a value we have to call the provided validator. We can however improve things some by better handling cases where no validator is provided. I think that's your real goal here anyway. > Default parameter length validating ignores setMinSize(0) > --------------------------------------------------------- > > Key: WFCORE-1590 > URL: https://issues.jboss.org/browse/WFCORE-1590 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha1 > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 3.0.0.Alpha4 > > > With the following attribute definition: - > {code:java} > static final SimpleAttributeDefinition REPLACEMENT = new SimpleAttributeDefinitionBuilder(ElytronDescriptionConstants.REPLACEMENT, ModelType.STRING, false) > .setAllowExpression(true) > .setMinSize(0) > .setFlags(AttributeAccess.Flag.RESTART_RESOURCE_SERVICES) > .build(); > {code} > The following error is reported if an empty string is used as a parameter: - > {noformat} > [standalone@localhost:9990 /] ./subsystem=elytron/regex-name-rewriter=strip-realm:add(pattern="@ELYTRON.ORG", replacement="", replace-all=true) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0113: '' is an invalid value for parameter replacement. Values must have a minimum length of 1 characters", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1651) --keep-content is not taken into account when undeploying in domain mode

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1651: -------------------------------------------- Summary: --keep-content is not taken into account when undeploying in domain mode Key: WFCORE-1651 URL: https://issues.jboss.org/browse/WFCORE-1651 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise In domain mode, the --keep-content is not taken into account. undeploy * --keep-content is identical as undeploy * The deployments are disabled and the references are removed from the server groups. This should be changed to respect option semantic. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 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 July 2016