July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6402: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1350355|https://bugzilla.redhat.com/show_bug.cgi?id=1350355] from ASSIGNED to POST > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > Labels: downstream_dependency > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. > This Jira ticket handles two PR's on WFLY: > https://github.com/wildfly/wildfly/pull/8824 (that is already merged) > and https://github.com/wildfly/wildfly/pull/8989 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1523) RestartParentResourceRemoveHandler should fail when removing non-existing resources

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1523?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-1523: ---------------------------------- Fix Version/s: 2.2.0.CR6 (was: 2.2.0.CR5) > RestartParentResourceRemoveHandler should fail when removing non-existing resources > ----------------------------------------------------------------------------------- > > Key: WFCORE-1523 > URL: https://issues.jboss.org/browse/WFCORE-1523 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.1.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Minor > Labels: 2.2 > Fix For: 3.0.0.Alpha1, 2.2.0.CR6 > > > In case when non-existent policy-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-6402: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/8824, https://github.com/wildfly/wildfly/pull/9009 (was: https://github.com/wildfly/wildfly/pull/8824, https://github.com/wildfly/wildfly/pull/8989, https://github.com/wildfly/wildfly/pull/9009) > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > Labels: downstream_dependency > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. > This Jira ticket handles two PR's on WFLY: > https://github.com/wildfly/wildfly/pull/8824 (that is already merged) > and https://github.com/wildfly/wildfly/pull/8989 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-6402: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/8824, https://github.com/wildfly/wildfly/pull/8989, https://github.com/wildfly/wildfly/pull/9009 (was: https://github.com/wildfly/wildfly/pull/8824, https://github.com/wildfly/wildfly/pull/8989) > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > Labels: downstream_dependency > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. > This Jira ticket handles two PR's on WFLY: > https://github.com/wildfly/wildfly/pull/8824 (that is already merged) > and https://github.com/wildfly/wildfly/pull/8989 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-234) Inconsistent synchronization in ConfigurationFile

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-234?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-234: ------------------------------------ Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Inconsistent synchronization in ConfigurationFile > ------------------------------------------------- > > Key: WFCORE-234 > URL: https://issues.jboss.org/browse/WFCORE-234 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha4 > > > ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir. > The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot. > The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-13: ----------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Alpha4 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-91) Review use of Locale in toLowerCase() calls

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-91?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-91: ----------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Review use of Locale in toLowerCase() calls > ------------------------------------------- > > Key: WFCORE-91 > URL: https://issues.jboss.org/browse/WFCORE-91 > Project: WildFly Core > Issue Type: Task > Components: CLI, Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha4 > > > There are places where we are converting strings to lower case without specifying Locale.ENGLISH. Some of these may be fine, but some are not and they should all be reviewed: > {code} > $ git grep "toLowerCase()" > cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase()); > cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase()); > controller/src/main/java/org/jboss/as/controller/operations/global/ReadResourceDescriptionHandler.java: final AccessControl value = localName != null ? MAP.get(local > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase(); > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase(); > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/standalone/root/StandaloneRootResourceTestCase.java: String hostName = NetworkUtils.canonize(InetAddress > domain-management/src/main/java/org/jboss/as/domain/management/security/adduser/ConfirmationChoice.java: String temp = response.toLowerCase(); // We now need to matc > domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AbstractAuditLogHandlerTestCase.java: PathElement.pathElement(PROTOCOL, transpor > host-controller/src/main/java/org/jboss/as/host/controller/DirectoryGrouping.java: final DirectoryGrouping directoryGrouping = localName != null ? MAP.get(localName.toLo > host-controller/src/main/java/org/jboss/as/host/controller/HostControllerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase(); > host-controller/src/main/java/org/jboss/as/host/controller/discovery/S3Util.java: String lk=hashKey.toLowerCase(); > server/src/main/java/org/jboss/as/server/ServerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase(); > testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: super("TestClient-" + id + " (" + type.toString().toLowerCase() + " > testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: this.description = "TestClient-" + id + " (" + type.toString().toLow > testsuite-core/shared/src/main/java/org/jboss/as/test/integration/management/interfaces/JmxInterfaceStringUtils.java: return string.replaceAll(regex, replacement).toLowe > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-273: ------------------------------------ Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Fix For: 3.0.0.Alpha4 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-306: ------------------------------------ Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Update add-user to use AESH or move it into the CLI > --------------------------------------------------- > > Key: WFCORE-306 > URL: https://issues.jboss.org/browse/WFCORE-306 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Scripts > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha4 > > > Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin > Switching to AESH would allow us to use the implementation there to handle this. > Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible. > Overall this is going to require further discussion so the comments here are just a starting point. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-301) Configuration of individual contexts for http management interface.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-301?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-301: ------------------------------------ Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Configuration of individual contexts for http management interface. > ------------------------------------------------------------------- > > Key: WFCORE-301 > URL: https://issues.jboss.org/browse/WFCORE-301 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha4 > > > At the moment all management requests are handled over the '/management' context, we also have a '/console' context to serve up the files for the admin console. > The '/management' context is secured using standard HTTP mechanisms, this decision was taken so that clients could be written in different languages and all they would need to know is how to use standard authentication mechanisms. Due to problems where web browsers could run malicious scripts cross origin resource sharing is completely disabled for this context. > We need to start to open up the handling of cross origin requests for a couple of reasons: - > - Enabling Keycloak SSO support. > - Alternative console distribution options > The '/management' context is going to be retained as-is for legacy clients, possibly even switched off by default. > A new context can then be added using non-browser based authentication, this could be SSO Keycloak or could be a form of Digest authentication where the response is handled by the console and not the web browser - either way as the browser is bypassed it is no longer at risk of sending malicious cross origin requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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