August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1348) LegacyPropertiesRealm should use spec passed into getCredential

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1348?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1348: ---------------------------- Description: As suggested in JBEAP-8700 comments, when DIGEST mechanism and plain-text properties realm used, realm should use digest realm name from HTTP mechanism - which is already passed into getCredential method but ignored by properties-realm yet. (was: There should be a possibility to retrieve additional information (e.g. Digest Realm name) in the realms when calling {{getCredential}} method. Currently such info has to be provided (duplicated) in the realm configuration. This issue is created as follow up for JBEAP-6003. See [this comment|https://issues.jboss.org/browse/JBEAP-6003?focusedCommentId=13359...] with HipChat discussion. ) > LegacyPropertiesRealm should use spec passed into getCredential > --------------------------------------------------------------- > > Key: ELY-1348 > URL: https://issues.jboss.org/browse/ELY-1348 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.2.0.Beta1 > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: security-realm > > As suggested in JBEAP-8700 comments, when DIGEST mechanism and plain-text properties realm used, realm should use digest realm name from HTTP mechanism - which is already passed into getCredential method but ignored by properties-realm yet. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1348) LegacyPropertiesRealm should use spec passed into getCredential

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1348?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1348: ---------------------------- Summary: LegacyPropertiesRealm should use spec passed into getCredential (was: Pass additional information to Elytron Realm getCredential method) > LegacyPropertiesRealm should use spec passed into getCredential > --------------------------------------------------------------- > > Key: ELY-1348 > URL: https://issues.jboss.org/browse/ELY-1348 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.2.0.Beta1 > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: security-realm > > There should be a possibility to retrieve additional information (e.g. Digest Realm name) in the realms when calling {{getCredential}} method. Currently such info has to be provided (duplicated) in the realm configuration. > This issue is created as follow up for JBEAP-6003. See [this comment|https://issues.jboss.org/browse/JBEAP-6003?focusedCommentId=13359...] with HipChat discussion. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1348) Pass additional information to Elytron Realm getCredential method

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1348?page=com.atlassian.jira.plugin.s... ] Jan Kalina moved JBEAP-12905 to ELY-1348: ----------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1348 (was: JBEAP-12905) Issue Type: Enhancement (was: Bug) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Realms (was: Security) Affects Version/s: 1.2.0.Beta1 (was: 7.1.0.DR11) > Pass additional information to Elytron Realm getCredential method > ----------------------------------------------------------------- > > Key: ELY-1348 > URL: https://issues.jboss.org/browse/ELY-1348 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.2.0.Beta1 > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: security-realm > > There should be a possibility to retrieve additional information (e.g. Digest Realm name) in the realms when calling {{getCredential}} method. Currently such info has to be provided (duplicated) in the realm configuration. > This issue is created as follow up for JBEAP-6003. See [this comment|https://issues.jboss.org/browse/JBEAP-6003?focusedCommentId=13359...] with HipChat discussion. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1348) Pass additional information to Elytron Realm getCredential method

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1348?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1348: ---------------------------- Labels: security-realm (was: authentication eap7.1.0-to-prd http sasl security-realm) > Pass additional information to Elytron Realm getCredential method > ----------------------------------------------------------------- > > Key: ELY-1348 > URL: https://issues.jboss.org/browse/ELY-1348 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.2.0.Beta1 > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: security-realm > > There should be a possibility to retrieve additional information (e.g. Digest Realm name) in the realms when calling {{getCredential}} method. Currently such info has to be provided (duplicated) in the realm configuration. > This issue is created as follow up for JBEAP-6003. See [this comment|https://issues.jboss.org/browse/JBEAP-6003?focusedCommentId=13359...] with HipChat discussion. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1717) Concurrency problems with enum constraints in MVEL

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1717?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1717: ------------------------------------- Sorry [~tzimanyi] but I'm missing the domain classes for the test case you pasted. Can you please add them? > Concurrency problems with enum constraints in MVEL > -------------------------------------------------- > > Key: DROOLS-1717 > URL: https://issues.jboss.org/browse/DROOLS-1717 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.2.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Labels: concurrency > > Having a test case like this [1], it sometimes fails on > java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] > [Near : {... enumValue == AnEnum.SECOND ....}] > ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. > Tested with mvel 2.2.8 on 6.5.x branch, 2.3.0 and 2.3.1 on master branch. > [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af > [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 > [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2061) TYPE_STRING does not handle unicode

by Cody Ebberson (JIRA)

[ https://issues.jboss.org/browse/JGRP-2061?page=com.atlassian.jira.plugin.... ] Cody Ebberson commented on JGRP-2061: ------------------------------------- Confirmed, this works for me. Appears fixed. Thanks! > TYPE_STRING does not handle unicode > ----------------------------------- > > Key: JGRP-2061 > URL: https://issues.jboss.org/browse/JGRP-2061 > Project: JGroups > Issue Type: Bug > Reporter: Cody Ebberson > Assignee: Bela Ban > Fix For: 4.0.6 > > > In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character. > For example, see objectToByteBuffer lines 561-567: > https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.... > {code:java} > case TYPE_STRING: > String str=(String)obj; > int len=str.length(); > ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING); > for(int i=0; i < len; i++) > retval.put((byte)str.charAt(i)); > return retval.array(); > {code} > This code will incorrectly encode any String with non ASCII encoding. > There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1805) It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1805: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1422216|https://bugzilla.redhat.com/show_bug.cgi?id=1422216] from ASSIGNED to CLOSED > It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1805 > URL: https://issues.jboss.org/browse/WFLY-1805 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > Labels: ejb > > With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors. > Since AS7 and WildFly the only possibility is to pass such context from the client to the server. > It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations. > This was used to return i.e. tracking or additional usefull informations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9240) WeldSecurityServices not able to obtain the current SecurityDomain anymore

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-9240?page=com.atlassian.jira.plugin.... ] Martin Kouba updated WFLY-9240: ------------------------------- Description: The integration code used by Weld 3 to propagate the security context of the current thread to different threads (needed for async events CDI 2.0 feature) is not able to obtain the current {{org.wildfly.security.auth.server.SecurityDomain}} anymore. The invocation of [SecurityDomain.getCurrent()|https://github.com/weld/wildfly/blob/11.0.0.B...] returns {{null}}. Note that this worked on WildFly *11.0.0.Alpha1*. It's also possible that the test (see also steps to reproduce) is wrong. A review/help from a security expert would be appreciated. was: The integration code used by Weld 3 to propagate the security context of the current thread to different threads (needed for async events CDI 2.0 feature) is not able to obtain the current {{org.wildfly.security.auth.server.SecurityDomain}} anymore. The invocation of [SecurityDomain.getCurrent()|https://github.com/weld/wildfly/blob/11.0.0.B...] returns {{null}}. Note that this worked on WildFly 11.0.0.Alpha1. It's also possible that the test (see also steps to reproduce) is wrong. A review/help from a security expert would be appreciated. > WeldSecurityServices not able to obtain the current SecurityDomain anymore > -------------------------------------------------------------------------- > > Key: WFLY-9240 > URL: https://issues.jboss.org/browse/WFLY-9240 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 11.0.0.Beta1, 11.0.0.CR1 > Reporter: Martin Kouba > Assignee: Darran Lofthouse > Priority: Critical > > The integration code used by Weld 3 to propagate the security context of the current thread to different threads (needed for async events CDI 2.0 feature) is not able to obtain the current {{org.wildfly.security.auth.server.SecurityDomain}} anymore. > The invocation of [SecurityDomain.getCurrent()|https://github.com/weld/wildfly/blob/11.0.0.B...] returns {{null}}. > Note that this worked on WildFly *11.0.0.Alpha1*. > It's also possible that the test (see also steps to reproduce) is wrong. A review/help from a security expert would be appreciated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9240) WeldSecurityServices not able to obtain the current SecurityDomain anymore

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-9240?page=com.atlassian.jira.plugin.... ] Martin Kouba updated WFLY-9240: ------------------------------- Steps to Reproduce: # clone Weld WildFly fork and build the project # clone Weld repo, build the project and run {{org.jboss.weld.tests.event.async.context.security.SecurityContextPropagationTest}} {noformat} $ git clone -b 11.0.0.CR1-weld3 git@github.com:weld/wildfly.git $ cd wildfly $ mvn clean install -DskipTests $ cd ../ $ git clone git@github.com:weld/core.git $ cd core $ mvn clean install -DskipTests $ export JBOSS_HOME=WFLYREPO/dist/target/wildfly-11.0.0.Beta1 $ mvn clean test -Dincontainer -Dtest=SecurityContextPropagationTest -f tests-arquillian/pom.xml {noformat} was: # clone Weld WildFly fork and build the project # clone Weld repo, build the project and run {{org.jboss.weld.tests.event.async.context.security.SecurityContextPropagationTest}} {noformat} $ git clone -b 11.0.0.Beta1-weld3 git@github.com:weld/wildfly.git $ cd wildfly $ mvn clean install -DskipTests $ cd ../ $ git clone git@github.com:weld/core.git $ cd core $ mvn clean install -DskipTests $ export JBOSS_HOME=WFLYREPO/dist/target/wildfly-11.0.0.Beta1 $ mvn clean test -Dincontainer -Dtest=SecurityContextPropagationTest -f tests-arquillian/pom.xml {noformat} > WeldSecurityServices not able to obtain the current SecurityDomain anymore > -------------------------------------------------------------------------- > > Key: WFLY-9240 > URL: https://issues.jboss.org/browse/WFLY-9240 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 11.0.0.Beta1, 11.0.0.CR1 > Reporter: Martin Kouba > Assignee: Darran Lofthouse > Priority: Critical > > The integration code used by Weld 3 to propagate the security context of the current thread to different threads (needed for async events CDI 2.0 feature) is not able to obtain the current {{org.wildfly.security.auth.server.SecurityDomain}} anymore. > The invocation of [SecurityDomain.getCurrent()|https://github.com/weld/wildfly/blob/11.0.0.B...] returns {{null}}. > Note that this worked on WildFly 11.0.0.Alpha1. > It's also possible that the test (see also steps to reproduce) is wrong. A review/help from a security expert would be appreciated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9240) WeldSecurityServices not able to obtain the current SecurityDomain anymore

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-9240?page=com.atlassian.jira.plugin.... ] Martin Kouba updated WFLY-9240: ------------------------------- Steps to Reproduce: # clone Weld WildFly fork and build the project # clone Weld repo, build the project and run {{org.jboss.weld.tests.event.async.context.security.SecurityContextPropagationTest}} {noformat} $ git clone -b 11.0.0.Beta1-weld3 git@github.com:weld/wildfly.git $ cd wildfly $ mvn clean install -DskipTests $ cd ../ $ git clone git@github.com:weld/core.git $ cd core $ mvn clean install -DskipTests $ export JBOSS_HOME=WFLYREPO/dist/target/wildfly-11.0.0.Beta1 $ mvn clean test -Dincontainer -Dtest=SecurityContextPropagationTest -f tests-arquillian/pom.xml {noformat} was: * clone Weld WildFly fork ({{git clone -b 11.0.0.Beta1-weld3 git@github.com:weld/wildfly.git}}) and build the project ({{mvn clean install -DskipTests}}) * clone Weld repo ({{git clone git@github.com:weld/core.git}}) and run {{org.jboss.weld.tests.event.async.context.security.SecurityContextPropagationTest}}: ## {{export JBOSS_HOME=WFLYREPO/dist/target/wildfly-11.0.0.Beta1}} ## {{mvn clean test -Dincontainer -Dtest=SecurityContextPropagationTest -f tests-arquillian/pom.xml}} > WeldSecurityServices not able to obtain the current SecurityDomain anymore > -------------------------------------------------------------------------- > > Key: WFLY-9240 > URL: https://issues.jboss.org/browse/WFLY-9240 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 11.0.0.Beta1, 11.0.0.CR1 > Reporter: Martin Kouba > Assignee: Darran Lofthouse > Priority: Critical > > The integration code used by Weld 3 to propagate the security context of the current thread to different threads (needed for async events CDI 2.0 feature) is not able to obtain the current {{org.wildfly.security.auth.server.SecurityDomain}} anymore. > The invocation of [SecurityDomain.getCurrent()|https://github.com/weld/wildfly/blob/11.0.0.B...] returns {{null}}. > Note that this worked on WildFly 11.0.0.Alpha1. > It's also possible that the test (see also steps to reproduce) is wrong. A review/help from a security expert would be appreciated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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