November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1992) CLI inconsistently parse {} in another object as UNDEFINED

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1992?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1992: ----------------------------------------- Priority: Major (was: Minor) > CLI inconsistently parse {} in another object as UNDEFINED > ---------------------------------------------------------- > > Key: WFCORE-1992 > URL: https://issues.jboss.org/browse/WFCORE-1992 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha12 > Reporter: Jan Kalina > Assignee: Jean-Francois Denise > > CLI interprets {} as blank object in resource attribute (correct), but as UNDEFINED in object attribute. (in model parameter of *performRuntime* of ADD operation) > {code:java} > /subsystem=elytron/properties-realm=realm:add(users-properties={path=$SOME_PATH},groups-properties={}) > => groups-properties = OBJECT {} > {code} > {code:java} > /subsystem=elytron/ldap-realm=ldap-realm8:add(dir-context=local-ldap,identity-mapping={rdn-identifier=uid,otp-credential-mapper={}}) > => otp-credential-mapper=UNDEFINED > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1992) CLI inconsistently parse {} in another object as UNDEFINED

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1992?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1992: ---------------------------------------------- That is a bug in the custom parser that is in use for non DMR syntax. identity-mapping={rdn-identifier=uid,otp-credential-mapper={}} is not DMR although groups-properties={} is DMR. > CLI inconsistently parse {} in another object as UNDEFINED > ---------------------------------------------------------- > > Key: WFCORE-1992 > URL: https://issues.jboss.org/browse/WFCORE-1992 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha12 > Reporter: Jan Kalina > Assignee: Jean-Francois Denise > Priority: Minor > > CLI interprets {} as blank object in resource attribute (correct), but as UNDEFINED in object attribute. (in model parameter of *performRuntime* of ADD operation) > {code:java} > /subsystem=elytron/properties-realm=realm:add(users-properties={path=$SOME_PATH},groups-properties={}) > => groups-properties = OBJECT {} > {code} > {code:java} > /subsystem=elytron/ldap-realm=ldap-realm8:add(dir-context=local-ldap,identity-mapping={rdn-identifier=uid,otp-credential-mapper={}}) > => otp-credential-mapper=UNDEFINED > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1992) CLI inconsistently parse {} in another object as UNDEFINED

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1992?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1992: -------------------------------------------- Assignee: Jean-Francois Denise > CLI inconsistently parse {} in another object as UNDEFINED > ---------------------------------------------------------- > > Key: WFCORE-1992 > URL: https://issues.jboss.org/browse/WFCORE-1992 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha12 > Reporter: Jan Kalina > Assignee: Jean-Francois Denise > Priority: Minor > > CLI interprets {} as blank object in resource attribute (correct), but as UNDEFINED in object attribute. (in model parameter of *performRuntime* of ADD operation) > {code:java} > /subsystem=elytron/properties-realm=realm:add(users-properties={path=$SOME_PATH},groups-properties={}) > => groups-properties = OBJECT {} > {code} > {code:java} > /subsystem=elytron/ldap-realm=ldap-realm8:add(dir-context=local-ldap,identity-mapping={rdn-identifier=uid,otp-credential-mapper={}}) > => otp-credential-mapper=UNDEFINED > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7578) Inconsistencies in using fileType/path+relative-to in Elytron XSD/DMR

by Ondrej Kotek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7578?page=com.atlassian.jira.plugin.... ] Ondrej Kotek commented on WFLY-7578: ------------------------------------ There are two inconsistencies. One in the XSD, and the second one in management model: * To support comprehensibility of XSD, {{basicFileType}} and {{fileType}} complex types should be used, (x)or {{path}} and {{relative-to}} attributes should be used, but not both. * To support comprehensibility of DMR, files should be represented as objects, (x)or files should be represented as attributes, but not both. Should I create separate JIRA issues? > Inconsistencies in using fileType/path+relative-to in Elytron XSD/DMR > --------------------------------------------------------------------- > > Key: WFLY-7578 > URL: https://issues.jboss.org/browse/WFLY-7578 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Kotek > Assignee: Darran Lofthouse > Labels: user_experience > > *Issue description:* > In _wildfly-elytron_1_0.xsd_, a file type is represented inconsistently. There are {{basicFileType}} and {{fileType}} complex types used, but there are also {{path}} and {{relative-to}} attributes used ({{providerLoadersType}}, {{kerberosSecurityFactory}}). > In DMR, file is represented as object (e.g. {{properties-realm}}) or as attributes (e.g. {{filesystem-realm}}, {{key-store}}). > *Suggestions for improvement:* > The file representation should be consistent in XSD/DMR. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-627: -------------------------------------- TLS 1.3 is already in there today. But yes new values should go in by RFE. > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: ELY-627 > URL: https://issues.jboss.org/browse/ELY-627 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.1.0.Beta8 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta12 > > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ] Martin Choma commented on ELY-627: ---------------------------------- Just to clarify. How will new values get into this list in future? I mean TLSv1.3 or DTLS. Throught RFE? Is it enough one from OpenSSL / JSSE implementation will support it? Or both have to be supported? > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: ELY-627 > URL: https://issues.jboss.org/browse/ELY-627 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.1.0.Beta8 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta12 > > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7150) EJB injection with indirection via web.xml is ignored

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7150?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7150: ----------------------------------------------- Petr Jurak <pjurak(a)redhat.com> changed the Status of [bug 1377705|https://bugzilla.redhat.com/show_bug.cgi?id=1377705] from NEW to ASSIGNED > EJB injection with indirection via web.xml is ignored > ----------------------------------------------------- > > Key: WFLY-7150 > URL: https://issues.jboss.org/browse/WFLY-7150 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Web (Undertow) > Reporter: Wolf-Dieter Fink > Assignee: Stuart Douglas > Fix For: 11.0.0.Alpha1 > > > If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected. > This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code. > Reproducer can be found here: > git@github.com:wfink/jboss-eap-quickstarts.git > BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2 > SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) > see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7140) Injection with @EJB is not working as expected with CDI (REST) beans

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7140: ----------------------------------------------- Petr Jurak <pjurak(a)redhat.com> changed the Status of [bug 1377705|https://bugzilla.redhat.com/show_bug.cgi?id=1377705] from NEW to ASSIGNED > Injection with @EJB is not working as expected with CDI (REST) beans > -------------------------------------------------------------------- > > Key: WFLY-7140 > URL: https://issues.jboss.org/browse/WFLY-7140 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, EJB > Reporter: Wolf-Dieter Fink > Assignee: Tomas Remes > Fix For: 11.0.0.Alpha1 > > > The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet. > @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne") > is not working correct if used in a CDI Bean in the reproducer example. > Reproducer can be found here: > git@github.com:wfink/jboss-eap-quickstarts.git > BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection > SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) > see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-760) Elytron Ldap Realm searches roles before validating password

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-760?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-760: ----------------------------- Affects Version/s: 1.1.0.Beta13 > Elytron Ldap Realm searches roles before validating password > ------------------------------------------------------------ > > Key: ELY-760 > URL: https://issues.jboss.org/browse/ELY-760 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > In Ldap Realm roles are searched before actual user password is validated. Ldap Realm uses following flow: > # searching for username > # searching for roles (i.e. searching for attributes) > # validating password for username > It means even if wrong password is used then roles in LDAP are searched. Password should be validated before some roles are searched. Current behavior can result to performance issues. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-760) Elytron Ldap Realm searches roles before validating password

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-760?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-760: ----------------------------- Component/s: Realms > Elytron Ldap Realm searches roles before validating password > ------------------------------------------------------------ > > Key: ELY-760 > URL: https://issues.jboss.org/browse/ELY-760 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > In Ldap Realm roles are searched before actual user password is validated. Ldap Realm uses following flow: > # searching for username > # searching for roles (i.e. searching for attributes) > # validating password for username > It means even if wrong password is used then roles in LDAP are searched. Password should be validated before some roles are searched. Current behavior can result to performance issues. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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