July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6373) Update to fasterxml jackson-2.8 to align with camel-2.18

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-6373?page=com.atlassian.jira.plugin.... ] Thomas Diesler updated WFLY-6373: --------------------------------- Summary: Update to fasterxml jackson-2.8 to align with camel-2.18 (was: Update to fasterxml jackson-2.7 to align with camel-2.17) > Update to fasterxml jackson-2.8 to align with camel-2.18 > -------------------------------------------------------- > > Key: WFLY-6373 > URL: https://issues.jboss.org/browse/WFLY-6373 > Project: WildFly > Issue Type: Task > Reporter: Thomas Diesler > Assignee: Jason Greene > Fix For: 10.1.0.Final > > > CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1143 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2042) Improve performance of Message#writeHeader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2042?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2042 at 7/14/16 3:09 AM: --------------------------------------------------------- Hmm, we could create an abstract method {{Header.getMagicId()}} which returns a constant magic ID. When {{ClassConfigurator}} is initialized, it would check that the magic IDs defined in {{jg-magic-map.xml}} actually match the ones returned by {{getMagicId()}}. In case of a mismatch, an exception would be thrown. Downside: when IDs change, the corresponding header classes have to be changed, too. Upside: faster serialization (eliminating 1 hashmap lookup for the magic ID). We only have a limited number of header classes anyway. was (Author: belaban): Hmm, we could create an abstract method {{Header.getMagicId()}} which returns a constant magic ID. When {{ClassConfigurator}} is initialized, it would check that the magic IDs defined in {{jg-magic-map.xml}} actually match the ones returned by {{getId()}}. In case of a mismatch, an exception would be thrown. Downside: when IDs change, the corresponding header classes have to be changed, too. Upside: faster serialization (eliminating 1 hashmap lookup for the magic ID). We only have a limited number of header classes anyway. > Improve performance of Message#writeHeader > ------------------------------------------ > > Key: JGRP-2042 > URL: https://issues.jboss.org/browse/JGRP-2042 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.11, 4.0 > > > The following stacktrace, taken with JFR, is highlighting a CPU consumer which could be optimised. > {noformat}Stack Trace Sample Count Percentage(%) > java.util.IdentityHashMap.get(Object) 66 2.224 > org.jgroups.conf.ClassConfigurator.getMagicNumber(Class) 66 2.224 > org.jgroups.Message.writeHeader(Header, DataOutput) 66 2.224 > {noformat} > One idea could be to use an ad-hoc implementation of Map which takes advantage of the key being a {{Class}}. An interesting alternative would be to avoid the map lookup altogether, by having the Header expose a method like "writeMagicNumber(DataInput to)". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2042) Improve performance of Message#writeHeader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2042?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2042 at 7/14/16 3:08 AM: --------------------------------------------------------- Hmm, we could create an abstract method {{Header.getMagicId()}} which returns a constant magic ID. When {{ClassConfigurator}} is initialized, it would check that the magic IDs defined in {{jg-magic-map.xml}} actually match the ones returned by {{getId()}}. In case of a mismatch, an exception would be thrown. Downside: when IDs change, the corresponding header classes have to be changed, too. Upside: faster serialization (eliminating 1 hashmap lookup for the magic ID). We only have a limited number of header classes anyway. was (Author: belaban): Hmm, we could create an abstract method {{Header.getId()}} which returns a constant magic ID. When {{ClassConfigurator}} is initialized, it would check that the magic IDs defined in {{jg-magic-map.xml}} actually match the ones returned by {{getId()}}. In case of a mismatch, an exception would be thrown. Downside: when IDs change, the corresponding header classes have to be changed, too. Upside: faster serialization (eliminating 1 hashmap lookup for the magic ID). We only have a limited number of header classes anyway. > Improve performance of Message#writeHeader > ------------------------------------------ > > Key: JGRP-2042 > URL: https://issues.jboss.org/browse/JGRP-2042 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.11, 4.0 > > > The following stacktrace, taken with JFR, is highlighting a CPU consumer which could be optimised. > {noformat}Stack Trace Sample Count Percentage(%) > java.util.IdentityHashMap.get(Object) 66 2.224 > org.jgroups.conf.ClassConfigurator.getMagicNumber(Class) 66 2.224 > org.jgroups.Message.writeHeader(Header, DataOutput) 66 2.224 > {noformat} > One idea could be to use an ad-hoc implementation of Map which takes advantage of the key being a {{Class}}. An interesting alternative would be to avoid the map lookup altogether, by having the Header expose a method like "writeMagicNumber(DataInput to)". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

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