March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6717) Upgrade HIbernate version to 4.2.0.CR2

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6717?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated AS7-6717: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=920700 > Upgrade HIbernate version to 4.2.0.CR2 > -------------------------------------- > > Key: AS7-6717 > URL: https://issues.jboss.org/browse/AS7-6717 > Project: Application Server 7 > Issue Type: Task > Components: JPA / Hibernate > Reporter: Dave Stahl > Assignee: Scott Marlow > > Upgrade hibernate version used in AS7 from 4.2.0.CR1 to 4.2.0.CR2 -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6717) Upgrade HIbernate version to 4.2.0.CR2

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6717?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6717: ---------------------------------------------- Dave Stahl <dstahl(a)redhat.com> made a comment on [bug 920700|https://bugzilla.redhat.com/show_bug.cgi?id=920700] Description of problem: Upgrade hibernate version to 4.2.0.CR2 Version-Release number of selected component (if applicable): 4.2.0.CR2 Additional info: JBOSS Jira AS7-6717 > Upgrade HIbernate version to 4.2.0.CR2 > -------------------------------------- > > Key: AS7-6717 > URL: https://issues.jboss.org/browse/AS7-6717 > Project: Application Server 7 > Issue Type: Task > Components: JPA / Hibernate > Reporter: Dave Stahl > Assignee: Scott Marlow > > Upgrade hibernate version used in AS7 from 4.2.0.CR1 to 4.2.0.CR2 -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6714) Update to console 1.5.2

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/AS7-6714?page=com.atlassian.jira.plugin.s... ] Heiko Braun updated AS7-6714: ----------------------------- Labels: console_1.5.2 (was: ) > Update to console 1.5.2 > ----------------------- > > Key: AS7-6714 > URL: https://issues.jboss.org/browse/AS7-6714 > Project: Application Server 7 > Issue Type: Feature Request > Components: Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Labels: console_1.5.2 > Fix For: 8.0.0.Alpha1 > > > Maintenance release -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6719) Get rid of external .index files

by David Lloyd (JIRA)

David Lloyd created AS7-6719: -------------------------------- Summary: Get rid of external .index files Key: AS7-6719 URL: https://issues.jboss.org/browse/AS7-6719 Project: Application Server 7 Issue Type: Task Components: Build System Reporter: David Lloyd Fix For: 8.0.0.Alpha1 The external {{*.index}} files have become a problem for distribution. In 8 we should switch to using internal {{META-INF/PATHS.LIST}} files. These files should be embedded during build. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6717) Upgrade HIbernate version to 4.2.0.CR2

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-6717?page=com.atlassian.jira.plugin.s... ] Scott Marlow resolved AS7-6717. ------------------------------- Resolution: Duplicate Issue Duplicate of AS7-6707, but thanks for reporting this. Next time, I'll wait for you to create the jira. :) > Upgrade HIbernate version to 4.2.0.CR2 > -------------------------------------- > > Key: AS7-6717 > URL: https://issues.jboss.org/browse/AS7-6717 > Project: Application Server 7 > Issue Type: Task > Components: JPA / Hibernate > Reporter: Dave Stahl > Assignee: Scott Marlow > > Upgrade hibernate version used in AS7 from 4.2.0.CR1 to 4.2.0.CR2 -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6718) HTTP Management interface "IllegalArgumentException: Invalid string contents" where realm has key and trust store but interface does not have https

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-6718: ------------------------------------- Summary: HTTP Management interface "IllegalArgumentException: Invalid string contents" where realm has key and trust store but interface does not have https Key: AS7-6718 URL: https://issues.jboss.org/browse/AS7-6718 Project: Application Server 7 Issue Type: Bug Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 8.0.0.Alpha1 Using a security realm with a key and trust store defined causes the following error to be reported when the http interface is accessed if no https socket binding is also specified: - {code} ERROR [io.undertow.request] (XNIO-1 read-3) UNDERTOW005001: An exception occurred processing the request: java.lang.IllegalArgumentException: Invalid string contents {code} -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-709) Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available

by Anil Saldhana (JIRA)

[ https://issues.jboss.org/browse/SECURITY-709?page=com.atlassian.jira.plug... ] Anil Saldhana commented on SECURITY-709: ---------------------------------------- [~yichen] I created a thread for discussion in the community list. http://lists.jboss.org/pipermail/security-dev/2013-March/000910.html > Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available > --------------------------------------------------------------------------------------- > > Key: SECURITY-709 > URL: https://issues.jboss.org/browse/SECURITY-709 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_v4_0_7 > Reporter: Yi Chen > Assignee: Anil Saldhana > > I am using the LdapLoginModule from PicketBox in JBoss AS 7.1.1 to enable authentication against our company's LDAP server. However, I always get a HTTP 401 back no matter what kind of problem caused the authentication failure. Tracing through the Picketbox and JBoss code, I found that the problem seems to be from the private method "proceedWithJaasLogin" in "JBossCachedAuthenticationManager". At the end of this method: > ... > catch (LoginException e) > { > // Don't log anonymous user failures unless trace level logging is on > if (principal != null && principal.getName() != null || trace) > log.error("Login failure", e); > authException = e; > } > // Set the security association thread context info exception > SubjectActions.setContextInfo("org.jboss.security.exception", authException); > return authenticated; > } > So basically, whatever exception that was sent up from the login modules is simply store in the thread context. The methods then simply returns true or false to indicate whether an authentication is successful or not. Whatever exception is store in the thread context doesn't appear to be used to generate a more appropriate error code to the client. > Steps to reproduce: > Just set up a LdapLoginModule and verify that it can be used to authenticate some users for a web application. Then shut down the LDAP server and try again. The client of the web application will always get back HTTP 401. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-709) Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available

by Anil Saldhana (JIRA)

[ https://issues.jboss.org/browse/SECURITY-709?page=com.atlassian.jira.plug... ] Anil Saldhana edited comment on SECURITY-709 at 3/12/13 10:18 AM: ------------------------------------------------------------------ [~yichen] JBossAS using JAAS authentication, we cannot tie the container security to individual errors of the login modules. I understand the non-availability of an LDAP server is a big factor. But those situations can be handled better by infrastructure monitoring solutions. We are planning to deprecate JAAS login and move toward a data store centric authentication in future versions of the AS. But until that happens, we cannot tie the HTTP response code to an error in the LDAP login module. This can be fixed on your end easily by writing a simple tomcat authenticator that extends the Tomcat Form Authenticator which returns the appropriate response code you desire, based on the error in ldap login module. https://community.jboss.org/wiki/JBossAS7SecurityDomainModel#Deploying_Cu... was (Author: anil.saldhana): [~yi chen] JBossAS using JAAS authentication, we cannot tie the container security to individual errors of the login modules. I understand the non-availability of an LDAP server is a big factor. But those situations can be handled better by infrastructure monitoring solutions. We are planning to deprecate JAAS login and move toward a data store centric authentication in future versions of the AS. But until that happens, we cannot tie the HTTP response code to an error in the LDAP login module. This can be fixed on your end easily by writing a simple tomcat authenticator that extends the Tomcat Form Authenticator which returns the appropriate response code you desire, based on the error in ldap login module. https://community.jboss.org/wiki/JBossAS7SecurityDomainModel#Deploying_Cu... > Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available > --------------------------------------------------------------------------------------- > > Key: SECURITY-709 > URL: https://issues.jboss.org/browse/SECURITY-709 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_v4_0_7 > Reporter: Yi Chen > Assignee: Anil Saldhana > > I am using the LdapLoginModule from PicketBox in JBoss AS 7.1.1 to enable authentication against our company's LDAP server. However, I always get a HTTP 401 back no matter what kind of problem caused the authentication failure. Tracing through the Picketbox and JBoss code, I found that the problem seems to be from the private method "proceedWithJaasLogin" in "JBossCachedAuthenticationManager". At the end of this method: > ... > catch (LoginException e) > { > // Don't log anonymous user failures unless trace level logging is on > if (principal != null && principal.getName() != null || trace) > log.error("Login failure", e); > authException = e; > } > // Set the security association thread context info exception > SubjectActions.setContextInfo("org.jboss.security.exception", authException); > return authenticated; > } > So basically, whatever exception that was sent up from the login modules is simply store in the thread context. The methods then simply returns true or false to indicate whether an authentication is successful or not. Whatever exception is store in the thread context doesn't appear to be used to generate a more appropriate error code to the client. > Steps to reproduce: > Just set up a LdapLoginModule and verify that it can be used to authenticate some users for a web application. Then shut down the LDAP server and try again. The client of the web application will always get back HTTP 401. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-709) Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available

by Anil Saldhana (JIRA)

[ https://issues.jboss.org/browse/SECURITY-709?page=com.atlassian.jira.plug... ] Anil Saldhana commented on SECURITY-709: ---------------------------------------- [~yi chen] JBossAS using JAAS authentication, we cannot tie the container security to individual errors of the login modules. I understand the non-availability of an LDAP server is a big factor. But those situations can be handled better by infrastructure monitoring solutions. We are planning to deprecate JAAS login and move toward a data store centric authentication in future versions of the AS. But until that happens, we cannot tie the HTTP response code to an error in the LDAP login module. This can be fixed on your end easily by writing a simple tomcat authenticator that extends the Tomcat Form Authenticator which returns the appropriate response code you desire, based on the error in ldap login module. https://community.jboss.org/wiki/JBossAS7SecurityDomainModel#Deploying_Cu... > Auth. using LdapLoginModule does not return HTTP 500 when the LDAP server not available > --------------------------------------------------------------------------------------- > > Key: SECURITY-709 > URL: https://issues.jboss.org/browse/SECURITY-709 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_v4_0_7 > Reporter: Yi Chen > Assignee: Anil Saldhana > > I am using the LdapLoginModule from PicketBox in JBoss AS 7.1.1 to enable authentication against our company's LDAP server. However, I always get a HTTP 401 back no matter what kind of problem caused the authentication failure. Tracing through the Picketbox and JBoss code, I found that the problem seems to be from the private method "proceedWithJaasLogin" in "JBossCachedAuthenticationManager". At the end of this method: > ... > catch (LoginException e) > { > // Don't log anonymous user failures unless trace level logging is on > if (principal != null && principal.getName() != null || trace) > log.error("Login failure", e); > authException = e; > } > // Set the security association thread context info exception > SubjectActions.setContextInfo("org.jboss.security.exception", authException); > return authenticated; > } > So basically, whatever exception that was sent up from the login modules is simply store in the thread context. The methods then simply returns true or false to indicate whether an authentication is successful or not. Whatever exception is store in the thread context doesn't appear to be used to generate a more appropriate error code to the client. > Steps to reproduce: > Just set up a LdapLoginModule and verify that it can be used to authenticate some users for a web application. Then shut down the LDAP server and try again. The client of the web application will always get back HTTP 401. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6717) Upgrade HIbernate version to 4.2.0.CR2

by Dave Stahl (JIRA)

Dave Stahl created AS7-6717: ------------------------------- Summary: Upgrade HIbernate version to 4.2.0.CR2 Key: AS7-6717 URL: https://issues.jboss.org/browse/AS7-6717 Project: Application Server 7 Issue Type: Task Components: JPA / Hibernate Reporter: Dave Stahl Assignee: Scott Marlow Upgrade hibernate version used in AS7 from 4.2.0.CR1 to 4.2.0.CR2 -- 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

13 years, 4 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 March 2013