November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1489) Expose (un)registerNotificationHandler() on OperationContext

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1489: ------------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Alpha3) > Expose (un)registerNotificationHandler() on OperationContext > ------------------------------------------------------------ > > Key: WFCORE-1489 > URL: https://issues.jboss.org/browse/WFCORE-1489 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Kabir Khan > Assignee: Jeff Mesnil > Fix For: 4.0.0.Alpha4 > > > Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL dependencies usage

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2589?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2589: ------------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Alpha3) > Eliminate MSC OPTIONAL dependencies usage > ----------------------------------------- > > Key: WFCORE-2589 > URL: https://issues.jboss.org/browse/WFCORE-2589 > Project: WildFly Core > Issue Type: Task > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 4.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2497: ------------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Alpha3) > Convert *-authentication-factory resources to be child resources of security-domain > ----------------------------------------------------------------------------------- > > Key: WFCORE-2497 > URL: https://issues.jboss.org/browse/WFCORE-2497 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Fix For: 4.0.0.Alpha4 > > > This is a good example of where child resources work. > The authentication factory resources have a mandatory dependency on a single security domain. > The configuration within the factory is related to it's security domain. > There is only a single resource that can provide security domains. > The behaviour of the parent is unaffected by the existence or configuration of the child. > The parent and child manage their own services independently with the child's service depending on the parent's service. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2496) Functionality in WildFly to encrypt database passwords

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2496?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2496: ------------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Alpha3) > Functionality in WildFly to encrypt database passwords > ------------------------------------------------------ > > Key: WFCORE-2496 > URL: https://issues.jboss.org/browse/WFCORE-2496 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Carlton Zachary > Fix For: 4.0.0.Alpha4 > > > Is it possible to add functionality to WildFly to encrypt a data source password when the data source is being created? Currently WildFly/EAP stores the password as plain text in the domain.xml/standalone.xml. > Thanks -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2365) Review custom-modifiable-realm resource in Elytron subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2365?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2365: ------------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Alpha3) > Review custom-modifiable-realm resource in Elytron subsystem > ------------------------------------------------------------ > > Key: WFCORE-2365 > URL: https://issues.jboss.org/browse/WFCORE-2365 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Fix For: 4.0.0.Alpha4 > > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2746: ------------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Alpha3) > Move elytron management security tests from full to core > -------------------------------------------------------- > > Key: WFCORE-2746 > URL: https://issues.jboss.org/browse/WFCORE-2746 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security, Test Suite > Reporter: Brian Stansberry > Fix For: 4.0.0.Alpha4 > > > Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested. > Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723 > There are a number of aspects to this, for which I'll create subtasks. > Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list. > -org.jboss.as.test.integration.security.perimeter.* [2]- > -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase- > -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]- > -org.jboss.as.test.integration.security.credentialreference [2]- > integration/elytron/ > [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now. > [2] Currently using Arquillian. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2688) RestartParentWriteAttributeHandler.isResourceServiceRestartAllowed should check the AttributeDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2688?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2688: ------------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Alpha3) > RestartParentWriteAttributeHandler.isResourceServiceRestartAllowed should check the AttributeDefinition > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2688 > URL: https://issues.jboss.org/browse/WFCORE-2688 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha4 > > > Besides checking with the context as to whether the allow-resource-service-restart header is set, if there is an AD available, it should be checked. > At one stroke this will turn off this ability for everything that doesn't specifically allow it. > Needs checks though to fix attributes that are meant to allow this but don't say so. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2687) Expose the current step operation's name and parameters via the OperationContext

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2687?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2687: ------------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Alpha3) > Expose the current step operation's name and parameters via the OperationContext > -------------------------------------------------------------------------------- > > Key: WFCORE-2687 > URL: https://issues.jboss.org/browse/WFCORE-2687 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha4 > > > Remove the need to pass the 'operation' ModelNode to a method for it to be able to learn about the currently effective operation. > OperationContext already exposes getCurrentAddress(). Add getCurrentOperationName() and getCurrentOperationParameter(String name). > The latter returns null if !operation.has(name) otherwise it returns whatever the node was. Or perhaps return undefined with an overloaded variant with a boolean param that lets the caller turn on getting null. > The getCurrentOperationParameter should reject 'name', 'address', 'operation-headers' etc as legal param names; only expose true parameters. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3181) Review CustomCredentialSecurityFactoryTestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3181?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3181: ------------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Alpha3) > Review CustomCredentialSecurityFactoryTestCase > ---------------------------------------------- > > Key: WFCORE-3181 > URL: https://issues.jboss.org/browse/WFCORE-3181 > Project: WildFly Core > Issue Type: Bug > Components: Security, Test Suite > Reporter: Darran Lofthouse > Fix For: 4.0.0.Alpha4 > > > The test case CustomCredentialSecurityFactoryTestCase appears to be testing that the 'code does what it does' rather than testing the 'code is doing what it should'. > The test is testing a custom credential security factory can be called but the test is using HTTP Basic authentication and relying on SPNEGO authentication being triggered as this is the only mechanism that currently uses this factory. > Should a minor change be required to the SPNEGO authentication mechanism which affects when this credential factory is called this test case could subsequently fail. > If possible it would be better to convert this test to be a SPNEGO test and then test the behaviour of the credential security factory affects the mechanism as expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3167) option to filter out aged out patches from the patching history

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3167?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3167: ------------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Alpha3) > option to filter out aged out patches from the patching history > --------------------------------------------------------------- > > Key: WFCORE-3167 > URL: https://issues.jboss.org/browse/WFCORE-3167 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Patching > Affects Versions: 3.0.0.Beta30 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 4.0.0.Alpha4 > > > show-history management operation (and patch history cli command) returns all the patches that have been applied to the installation even if some of them have been aged out by executing ageout-history management operation. > In some cases it would be useful to filter out the aged out patches from the result, leaving only the patches that can actually be rolled back by a user. > That could be achieved by adding an optional boolean parameter exclude-agedout (with default value false to preserve the current behavior) to show-history operation. > The high level CLI command patch history could include an equivalent --exclude-agedout argument. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 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 November 2017