April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3067: ----------------------------------------------- Rostislav Svoboda <rsvoboda(a)redhat.com> changed the Status of [bug 1079084|https://bugzilla.redhat.com/show_bug.cgi?id=1079084] from ON_QA to VERIFIED > Webservices DUP is not scanning all visible classes for @WebService annotation > ------------------------------------------------------------------------------ > > Key: WFLY-3067 > URL: https://issues.jboss.org/browse/WFLY-3067 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.0.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 8.1.0.CR1 > > > Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this: > {noformat} > UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3048: ----------------------------------------------- Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1069127|https://bugzilla.redhat.com/show_bug.cgi?id=1069127] from ON_QA to VERIFIED > "Local" authentication fails when LDAP is used for ManagementRealm > ------------------------------------------------------------------ > > Key: WFLY-3048 > URL: https://issues.jboss.org/browse/WFLY-3048 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Environment: Ubuntu 13.04, Xeon-based VPS > Reporter: Matt Jensen > Assignee: Darran Lofthouse > Fix For: 8.1.0.CR1 > > > When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working. > I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows: > <security-realm name="ManagementRealm"> > <authentication> > <local default-user="$local" /> > <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false"> > ... > </ldap> > </authentication> > <authorization map-groups-to-roles="false"> > <ldap connection="..."> > ... > </ldap> > </authorization> > </security-realm> > I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command. > The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm. > If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password. > I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password. > The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up. > The documentation specifically mentions that <local/> should work along with <ldap/> here: > https://docs.jboss.org/author/display/WFLY8/Security+Realms -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3048: ----------------------------------------------- Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from ON_QA to VERIFIED > "Local" authentication fails when LDAP is used for ManagementRealm > ------------------------------------------------------------------ > > Key: WFLY-3048 > URL: https://issues.jboss.org/browse/WFLY-3048 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Environment: Ubuntu 13.04, Xeon-based VPS > Reporter: Matt Jensen > Assignee: Darran Lofthouse > Fix For: 8.1.0.CR1 > > > When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working. > I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows: > <security-realm name="ManagementRealm"> > <authentication> > <local default-user="$local" /> > <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false"> > ... > </ldap> > </authentication> > <authorization map-groups-to-roles="false"> > <ldap connection="..."> > ... > </ldap> > </authorization> > </security-realm> > I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command. > The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm. > If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password. > I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password. > The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up. > The documentation specifically mentions that <local/> should work along with <ldap/> here: > https://docs.jboss.org/author/display/WFLY8/Security+Realms -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should Not Fail for Non-existent User.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2660?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2660: ----------------------------------------------- Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from ON_QA to VERIFIED > LDAP Group Loading - Should Not Fail for Non-existent User. > ----------------------------------------------------------- > > Key: WFLY-2660 > URL: https://issues.jboss.org/browse/WFLY-2660 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Final > > > Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP. > One example is local authentication where the user may not exist. > Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3161) Optimize org.jboss.as.jmx.model.RootResourceIterator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3161?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3161: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1077536|https://bugzilla.redhat.com/show_bug.cgi?id=1077536] from ON_QA to VERIFIED > Optimize org.jboss.as.jmx.model.RootResourceIterator > ---------------------------------------------------- > > Key: WFLY-3161 > URL: https://issues.jboss.org/browse/WFLY-3161 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Domain Management, JMX > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.1.0.CR1 > > > RootResourceIterator is performing an access control check on a resource before confirming that the caller is in any way interested in that resource. This results in spurious access control checks. Fixing this can speed up queryMBeans and queryNames calls. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3228) ApplyRemoteMasterDomainHandler should use values sent from DC for root resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3228?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3228: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1085122|https://bugzilla.redhat.com/show_bug.cgi?id=1085122] from ON_QA to VERIFIED > ApplyRemoteMasterDomainHandler should use values sent from DC for root resource > ------------------------------------------------------------------------------- > > Key: WFLY-3228 > URL: https://issues.jboss.org/browse/WFLY-3228 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 8.1.0.CR1 > > > This is needed to keep the slave copy of the resource model actually the same, and popped up during mixed domain testing of EAP with a 6.2.0 slave. > Connect directly to to 6.1.1 slave - gets domain version from master > {code} > [domain@localhost:19999 /] :read-resource > { > "outcome" => "success", > "result" => { > "deployment" => undefined, > "deployment-overlay" => undefined, > "management-major-version" => 1, > "management-micro-version" => 0, > "management-minor-version" => 6, > "name" => "Unnamed Domain", > "namespaces" => [], > "path" => undefined, > "product-name" => "EAP", > "product-version" => "6.3.0.Alpha3", > "profile" => undefined, > "release-codename" => "Janus", > "release-version" => "7.4.0.Final-redhat-SNAPSHOT", > {code} > Connect directly to 6.2.0 slave - does not get domain version from master > {code} > [domain@localhost:19999 /] :read-resource > { > "outcome" => "success", > "result" => { > "management-major-version" => 1, > "management-micro-version" => 0, > "management-minor-version" => 5, > "name" => "Unnamed Domain", > "namespaces" => [], > "product-name" => "EAP", > "product-version" => "6.2.0.GA", > "release-codename" => "Janus", > "release-version" => "7.3.0.Final-redhat-14", > {code} > The 6.2.0 slave should look the same as the 6.1.1 slave for these attributes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-201) Improve Rule Removal

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-201?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-201: ------------------------------------------ Fix Version/s: 6.1.0.Beta4 (was: 6.1.0.Beta3) > Improve Rule Removal > -------------------- > > Key: DROOLS-201 > URL: https://issues.jboss.org/browse/DROOLS-201 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Mark Proctor > Fix For: 6.1.0.Beta4 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-88) Support generics in declared types' fields

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-88?page=com.atlassian.jira.plugin.... ] Michael Biarnes Kiefer updated DROOLS-88: ----------------------------------------- Fix Version/s: 6.1.0.Beta4 (was: 6.1.0.Beta3) > Support generics in declared types' fields > ------------------------------------------ > > Key: DROOLS-88 > URL: https://issues.jboss.org/browse/DROOLS-88 > Project: Drools > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Davide Sottara > Assignee: Davide Sottara > Priority: Minor > Fix For: 5.5.1.Final, 6.1.0.Beta4 > > > It should be possible to write: > declare Foo > list : List<String> > end > While not supported in rules using the mvel dialect, it makes declared types much more readable, and adds some type-safety to java rules. > Notice that this ticket is NOT related to the possibility of declaring generic classes, such as Foo<T>. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-115) Add support for strong negation

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-115?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-115: ------------------------------------------ Fix Version/s: 6.1.0.Beta4 (was: 6.1.0.Beta3) > Add support for strong negation > ------------------------------- > > Key: DROOLS-115 > URL: https://issues.jboss.org/browse/DROOLS-115 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Davide Sottara > Assignee: Davide Sottara > Priority: Minor > Fix For: 6.1.0.Beta4 > > > Drools "not" operator implements a type of "negation by failure", i.e. not X() behaves as the negation of "exists" or, in other words, translates as "it is NOT asserted that ...". > However, another form of stronger negation is needed to express conditionals such as "it is asserted that NOT ..." > It should be possible, then, to assert facts both in a "positive" and "negative" way, to assert THAT and THAT NOT. > The language should also support a "neg" CE to create "negative" patterns which will match with negative facts. I.e. it should be possible to write rules such as: > when $p : Person() and Car( owner == $p ) then > // a positive, matching Car is present in the WM > when $p : Person() and neg Car( owner == $p ) then > // a negative, matching Car is present in the WM > when $p : Person() and not Car( owner == $p ) then > // neither a positive nor a negative fact exists in the WM > For a more detailed description and motivation see e.g.: > https://oxygen.informatik.tu-cottbus.de/publications/wagner/WebRules2Neg.pdf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-198) Separate Rete and Phreak

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-198?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-198: ------------------------------------------ Fix Version/s: 6.1.0.Beta4 (was: 6.1.0.Beta3) > Separate Rete and Phreak > ------------------------ > > Key: DROOLS-198 > URL: https://issues.jboss.org/browse/DROOLS-198 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Mark Proctor > Fix For: 6.1.0.Beta4 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

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