May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1203) Elytron AuthenticationConfiguration uses SASL mechanism from incorrect security Provider in some cases

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1203?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1203: ---------------------------------- Fix Version/s: 1.1.0.Beta48 > Elytron AuthenticationConfiguration uses SASL mechanism from incorrect security Provider in some cases > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1203 > URL: https://issues.jboss.org/browse/ELY-1203 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta48 > > > In our tests for PLAIN SASL mechanism in the AS testsuite we realized a wrong SaslClient implementation is used. Instead of the Elytron one, the JDK provided one is used ({{com.sun.security.sasl.PlainClient}}). > The Elytron client builds the AuthenticationContext and runs executed code in this way: > {code:java} > AuthenticationConfiguration authnCfg = AuthenticationConfiguration.EMPTY.allowSaslMechanisms(MECHANISM_PLAIN) > .useName(USERNAME).usePassword("wrongPassword") > .useProviders(() -> new Provider[] { new WildFlyElytronProvider() }); > AuthenticationContext.empty().with(MatchRule.ALL, authnCfg).run(...) > {code} > It seems to be related to what's included on classpath. When we use the same code in [elytron-client-demo|https://github.com/jboss-security-qe/elytron-client-demo] the correct mechanism is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1203) Elytron AuthenticationConfiguration uses SASL mechanism from incorrect security Provider in some cases

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1203?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1203. ----------------------------------- Resolution: Done > Elytron AuthenticationConfiguration uses SASL mechanism from incorrect security Provider in some cases > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1203 > URL: https://issues.jboss.org/browse/ELY-1203 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta48 > > > In our tests for PLAIN SASL mechanism in the AS testsuite we realized a wrong SaslClient implementation is used. Instead of the Elytron one, the JDK provided one is used ({{com.sun.security.sasl.PlainClient}}). > The Elytron client builds the AuthenticationContext and runs executed code in this way: > {code:java} > AuthenticationConfiguration authnCfg = AuthenticationConfiguration.EMPTY.allowSaslMechanisms(MECHANISM_PLAIN) > .useName(USERNAME).usePassword("wrongPassword") > .useProviders(() -> new Provider[] { new WildFlyElytronProvider() }); > AuthenticationContext.empty().with(MatchRule.ALL, authnCfg).run(...) > {code} > It seems to be related to what's included on classpath. When we use the same code in [elytron-client-demo|https://github.com/jboss-security-qe/elytron-client-demo] the correct mechanism is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2060) Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-2060?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-2060: ----------------------------------------------- Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1330729|https://bugzilla.redhat.com/show_bug.cgi?id=1330729] from POST to MODIFIED > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2060 > URL: https://issues.jboss.org/browse/JGRP-2060 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.9 > Reporter: Brad Maxwell > Assignee: Bela Ban > Fix For: 3.6.10, 4.0 > > > Remove jgroups.logging.log_factory_class or have LogFactory.setCustomLogFactory take precedence to avoid issues with multiple jgroups in the same JVM -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2888) Upgrade CLI to use aesh 0.66.18 and jansi 1.16

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2888?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2888: ------------------------------- Issue Type: Component Upgrade (was: Bug) > Upgrade CLI to use aesh 0.66.18 and jansi 1.16 > ---------------------------------------------- > > Key: WFCORE-2888 > URL: https://issues.jboss.org/browse/WFCORE-2888 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > Today jansi 1.11 breaks the rule of being source code 1.6. > jansi 1.16 has been upgraded. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2889) Upgrade CLI to use aesh 0.66.18 and jansi 1.16

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-2889: ---------------------------------- Summary: Upgrade CLI to use aesh 0.66.18 and jansi 1.16 Key: WFCORE-2889 URL: https://issues.jboss.org/browse/WFCORE-2889 Project: WildFly Core Issue Type: Component Upgrade Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Today jansi 1.11 breaks the rule of being source code 1.6. jansi 1.16 has been upgraded. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2888) Upgrade CLI to use aesh 0.66.18 and jansi 1.16

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-2888: -------------------------------------------- Summary: Upgrade CLI to use aesh 0.66.18 and jansi 1.16 Key: WFCORE-2888 URL: https://issues.jboss.org/browse/WFCORE-2888 Project: WildFly Core Issue Type: Bug Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Today jansi 1.11 breaks the rule of being source code 1.6. jansi 1.16 has been upgraded. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2880) remove-alias should fail when remove non-existent alias from credential store.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2880?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2880: ------------------------------------------ IMHO it's debatable whether this is a bug. I can see both sides of it, and for something like this where a typo in what you are removing can result in leaving something behind there's a stronger case for being strict. In general though it's quite normal for APIs to allow people to try and remove things that may not exist, since the user may not care if the thing was there, so long as it's no longer there at the end. This also needs to consider things like the use of this operation on a /profile=x/subsystem=elytron/... resource, as that may increase the odds of the thing not being there on a particular server and the user being fine with that. > remove-alias should fail when remove non-existent alias from credential store. > ------------------------------------------------------------------------------ > > Key: WFCORE-2880 > URL: https://issues.jboss.org/browse/WFCORE-2880 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Critical > > remove-alias should fail when remove non-existent alias from credential store. > There is expected fail when we try to remove non-existent alias from credential store. > *How to reproduce* > *create credential store* > {code} > /subsystem=elytron/credential-store=cs001:add(create=true, credential-reference={clear-text=pass123},location=cs001.jceks) > {code} > *Try to remove alias from empty credential store* > {code} > /subsystem=elytron/credential-store=cs001:remove-alias(alias=alias001) > { > "outcome" => "success", > "result" => undefined > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2885) list-remove operation succeeds when removing non-existent item

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2885?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2885: ------------------------------------------ Yes, we're not exactly consistent. For sure for this one I don't want to fail as this is a general purpose API that should work like java.util.Collection.remove. An enhancement request to return true/false depending on whether something was removed would be reasonable though. For other remove-xxx one off operations, they are not general purpose so there's more scope for arguing that they should fail given the context of the op. For example WFCORE-2880 involves a security object. > list-remove operation succeeds when removing non-existent item > -------------------------------------------------------------- > > Key: WFCORE-2885 > URL: https://issues.jboss.org/browse/WFCORE-2885 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Michal Petrov > Assignee: Michal Petrov > > When removing an item from a list the operation should fail if the item doesn't exist. E.g. > {code} > /subsystem=logging/root-logger=ROOT:list-remove(name=handlers,value="ABC") > {code} > the operation already fails when using an invalid index. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2886) remove-handler operation succeeds when removing non-existent handler

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2886?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-2886: --------------------------------------- Scratch that, I read it wrong. Sorry not the resource the handler itself does not exist. I guess not failing, the current behavior, makes the most sense really. Having it fail could potentially break scripts. I don't *think* a user could care if the handler didn't exist they're trying to remove. The end goal is to not have the handler in the list and that is accomplished if the handler doesn't exist. > remove-handler operation succeeds when removing non-existent handler > -------------------------------------------------------------------- > > Key: WFCORE-2886 > URL: https://issues.jboss.org/browse/WFCORE-2886 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Michal Petrov > Assignee: Michal Petrov > > When trying to remove a handler that doesn't exist the operation should fail. E.g. > {code} > /subsystem=logging/root-logger=ROOT:remove-handler(name="ABC") > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2886) remove-handler operation succeeds when removing non-existent handler

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2886?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-2886: --------------------------------------- Unless I'm missing something this already fails in WildFly Core: {code} [standalone@localhost:9990 /] /subsystem=logging/root-logger=ROOT:remove-handler(name=FILE) { "outcome" => "failed", "failure-description" => "WFLYCTL0216: Management resource '[ (\"subsystem\" => \"logging\"), (\"root-logger\" => \"ROOT\") ]' not found", "rolled-back" => true } {code} > remove-handler operation succeeds when removing non-existent handler > -------------------------------------------------------------------- > > Key: WFCORE-2886 > URL: https://issues.jboss.org/browse/WFCORE-2886 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Michal Petrov > Assignee: Michal Petrov > > When trying to remove a handler that doesn't exist the operation should fail. E.g. > {code} > /subsystem=logging/root-logger=ROOT:remove-handler(name="ABC") > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017