June 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1580) PersistentResourceXMLDescription does not persist empty subsystems

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-1580?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-1580. ---------------------------------- Fix Version/s: 8.0.0.Alpha3 Resolution: Done > PersistentResourceXMLDescription does not persist empty subsystems > ------------------------------------------------------------------ > > Key: WFLY-1580 > URL: https://issues.jboss.org/browse/WFLY-1580 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.0.0.Alpha2 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.Alpha3 > > -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1546) Undertow is not wired up to use the correct temp location

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-1546?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-1546. ---------------------------------- Fix Version/s: 8.0.0.Alpha3 Resolution: Done > Undertow is not wired up to use the correct temp location > --------------------------------------------------------- > > Key: WFLY-1546 > URL: https://issues.jboss.org/browse/WFLY-1546 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Alpha1, 8.0.0.Alpha2 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.Alpha3 > > -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-179) Incremental builds involving process files: Previous errors not cleared

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-179?page=com.atlassian.jira.plugin... ] Michael Anstis updated DROOLS-179: ---------------------------------- Description: See the PR. Firstly a process file containing errors is added to KieBuilder and expected errors are generated. The process file is corrected (to contain zero errors) however the incremental build does not clear the errors. > Incremental builds involving process files: Previous errors not cleared > ----------------------------------------------------------------------- > > Key: DROOLS-179 > URL: https://issues.jboss.org/browse/DROOLS-179 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Michael Anstis > Assignee: Mark Proctor > > See the PR. > Firstly a process file containing errors is added to KieBuilder and expected errors are generated. > The process file is corrected (to contain zero errors) however the incremental build does not clear the errors. -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-179) Incremental builds involving process files: Previous errors not cleared

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-179?page=com.atlassian.jira.plugin... ] Michael Anstis updated DROOLS-179: ---------------------------------- Summary: Incremental builds involving process files: Previous errors not cleared (was: Incremental builds involving process files does not clear previous errors) > Incremental builds involving process files: Previous errors not cleared > ----------------------------------------------------------------------- > > Key: DROOLS-179 > URL: https://issues.jboss.org/browse/DROOLS-179 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Michael Anstis > Assignee: Mark Proctor > -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-179) Incremental builds involving process files does not clear previous errors

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-179?page=com.atlassian.jira.plugin... ] Michael Anstis commented on DROOLS-179: --------------------------------------- See https://github.com/droolsjbpm/drools/pull/217 > Incremental builds involving process files does not clear previous errors > ------------------------------------------------------------------------- > > Key: DROOLS-179 > URL: https://issues.jboss.org/browse/DROOLS-179 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Michael Anstis > Assignee: Mark Proctor > -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-744) WebJASPIAuthenticator doesn't populate Subject when building JBossGenericPrincipal

by Anil Saldhana (JIRA)

[ https://issues.jboss.org/browse/SECURITY-744?page=com.atlassian.jira.plug... ] Anil Saldhana reassigned SECURITY-744: -------------------------------------- Assignee: Stefan Guilhen (was: Anil Saldhana) Stefan - can you verify and incorporate? > WebJASPIAuthenticator doesn't populate Subject when building JBossGenericPrincipal > ---------------------------------------------------------------------------------- > > Key: SECURITY-744 > URL: https://issues.jboss.org/browse/SECURITY-744 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: arjan tijms > Assignee: Stefan Guilhen > Labels: authentication, ejb, jaspi, jaspic, security > > {{WebJASPIAuthenticator}} creates a new Subject that it passes to the JASPIC Auth Module (SAM): > {code} > Subject clientSubject = new Subject(); > if (sam != null) { > result = sam.isValid(messageInfo, clientSubject, messageLayer, appContext, cbh); > } > {code} > [Source|https://github.com/wildfly/wildfly/blob/master/web/src/main/java/o...] > Afterwards this Subject instance is put into the {{JBossGenericPrincipal}} when this is being build: > {code} > protected Principal buildJBossPrincipal(Subject subject, Principal principal, GroupPrincipalCallback gpc) { > // ... > // build and return the JBossGenericPrincipal. > return new JBossGenericPrincipal(realm, principal.getName(), null, roles, principal, null, null, null, subject); > } > {code} > [Source|https://github.com/wildfly/wildfly/blob/master/web/src/main/java/o...] > This seems to assume that the JASPIC Auth Module has populated the Subject (as happens with JAAS login modules), but this is not what happens. JASPIC Auth Modules unlike JAAS login modules are universal and have no knowledge of the container specific Subject layout. > The container should thus populate the Subject based on the callbacks. > {{WebJASPIAuthenticator}} does uses the callbacks to store the caller/user principal and roles directly into the {{JBossGenericPrincipal}}. Calls like {{HttpServletRequest#getUserPrincipal}} directly return {{JBossGenericPrincipal#getUserPrincipal}} and thus work. > However, {{EJBContext#getCallerPrincipal()}} which is implemented by {{org.jboss.as.security.service.SimpleSecurityManager#getCallerPrincipal}} works with {{securityContext.getSubjectInfo().getAuthenticatedSubject}} and does _not_ work. > This {{SubjectInfo}} is initialized in {{org.jboss.as.web.security.SecurityContextAssociationValve}} via the following code: > {code} > sc.getUtil().createSubjectInfo(new SimplePrincipal( > principal.getName()), > principal.getCredentials(), > principal.getSubject() // clientSubject from JASPIC SAM > ); > {code} > (principal here is the {{JBossGenericPrincipal}} that's returned by {{WebJASPIAuthenticator}}) > Because the Subject instance used here is still the empty instance, the authenticated identity will not be available in EJB beans. {{EJBContext#getCallerPrincipal()}} will always return the anonymous principal and every check for a role will return false. > Adding something like the following code to {{buildJBossPrincipal}} seems to propagate the authenticated identity correctly to the EJB module: > {code} > Subject authenticatedSubject = new Subject(); > // Add the caller principal to the Subject > Group callerPrincipalGroup = new SimpleGroup("CallerPrincipal"); > callerPrincipalGroup.addMember(principal); > authenticatedSubject.getPrincipals().add(callerPrincipalGroup); > > // Add the roles to the Subject > if (!roles.isEmpty()) { > Group rolesGroup = new SimpleGroup("Roles"); > for (String role : roles) { > rolesGroup.addMember(new SimplePrincipal(role)); > } > authenticatedSubject.getPrincipals().add(rolesGroup); > } > return new JBossGenericPrincipal(realm, principal.getName(), null, roles, principal, null, null, null, authenticatedSubject); > {code} > I've tested [locally|https://github.com/javaeekickoff/jboss-as-jaspic-patch/commit/31b...] with this patch and it indeed seems to work. -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-179) Incremental builds involving process files does not clear previous errors

by Michael Anstis (JIRA)

Michael Anstis created DROOLS-179: ------------------------------------- Summary: Incremental builds involving process files does not clear previous errors Key: DROOLS-179 URL: https://issues.jboss.org/browse/DROOLS-179 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Michael Anstis Assignee: Mark Proctor -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-744) WebJASPIAuthenticator doesn't populate Subject when building JBossGenericPrincipal

by arjan tijms (JIRA)

arjan tijms created SECURITY-744: ------------------------------------ Summary: WebJASPIAuthenticator doesn't populate Subject when building JBossGenericPrincipal Key: SECURITY-744 URL: https://issues.jboss.org/browse/SECURITY-744 Project: PicketBox Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: arjan tijms Assignee: Anil Saldhana {{WebJASPIAuthenticator}} creates a new Subject that it passes to the JASPIC Auth Module (SAM): {code} Subject clientSubject = new Subject(); if (sam != null) { result = sam.isValid(messageInfo, clientSubject, messageLayer, appContext, cbh); } {code} [Source|https://github.com/wildfly/wildfly/blob/master/web/src/main/java/o...] Afterwards this Subject instance is put into the {{JBossGenericPrincipal}} when this is being build: {code} protected Principal buildJBossPrincipal(Subject subject, Principal principal, GroupPrincipalCallback gpc) { // ... // build and return the JBossGenericPrincipal. return new JBossGenericPrincipal(realm, principal.getName(), null, roles, principal, null, null, null, subject); } {code} [Source|https://github.com/wildfly/wildfly/blob/master/web/src/main/java/o...] This seems to assume that the JASPIC Auth Module has populated the Subject (as happens with JAAS login modules), but this is not what happens. JASPIC Auth Modules unlike JAAS login modules are universal and have no knowledge of the container specific Subject layout. The container should thus populate the Subject based on the callbacks. {{WebJASPIAuthenticator}} does uses the callbacks to store the caller/user principal and roles directly into the {{JBossGenericPrincipal}}. Calls like {{HttpServletRequest#getUserPrincipal}} directly return {{JBossGenericPrincipal#getUserPrincipal}} and thus work. However, {{EJBContext#getCallerPrincipal()}} which is implemented by {{org.jboss.as.security.service.SimpleSecurityManager#getCallerPrincipal}} works with {{securityContext.getSubjectInfo().getAuthenticatedSubject}} and does _not_ work. This {{SubjectInfo}} is initialized in {{org.jboss.as.web.security.SecurityContextAssociationValve}} via the following code: {code} sc.getUtil().createSubjectInfo(new SimplePrincipal( principal.getName()), principal.getCredentials(), principal.getSubject() // clientSubject from JASPIC SAM ); {code} (principal here is the {{JBossGenericPrincipal}} that's returned by {{WebJASPIAuthenticator}}) Because the Subject instance used here is still the empty instance, the authenticated identity will not be available in EJB beans. {{EJBContext#getCallerPrincipal()}} will always return the anonymous principal and every check for a role will return false. Adding something like the following code to {{buildJBossPrincipal}} seems to propagate the authenticated identity correctly to the EJB module: {code} Subject authenticatedSubject = new Subject(); // Add the caller principal to the Subject Group callerPrincipalGroup = new SimpleGroup("CallerPrincipal"); callerPrincipalGroup.addMember(principal); authenticatedSubject.getPrincipals().add(callerPrincipalGroup); // Add the roles to the Subject if (!roles.isEmpty()) { Group rolesGroup = new SimpleGroup("Roles"); for (String role : roles) { rolesGroup.addMember(new SimplePrincipal(role)); } authenticatedSubject.getPrincipals().add(rolesGroup); } return new JBossGenericPrincipal(realm, principal.getName(), null, roles, principal, null, null, null, authenticatedSubject); {code} I've tested [locally|https://github.com/javaeekickoff/jboss-as-jaspic-patch/commit/31b...] with this patch and it indeed seems to work. -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1587) Formatter configuration is not correctly checked for a changed value

by James Perkins (JIRA)

James Perkins created WFLY-1587: ----------------------------------- Summary: Formatter configuration is not correctly checked for a changed value Key: WFLY-1587 URL: https://issues.jboss.org/browse/WFLY-1587 Project: WildFly Issue Type: Bug Components: Logging Reporter: James Perkins Assignee: James Perkins Fix For: 8.0.0.Alpha3 When handlers are added via the logging subsystem the current configuration is checked and only changed attributes are updated. The {{FORMATTER}} attribute checks the value of the formatter, but does not check the formatter name on the handler. -- 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

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1645) MuxMessageDispatcher drops exclusion list during cast

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-1645?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated JGRP-1645: ------------------------------- Priority: Major (was: Critical) > MuxMessageDispatcher drops exclusion list during cast > ----------------------------------------------------- > > Key: JGRP-1645 > URL: https://issues.jboss.org/browse/JGRP-1645 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3.1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 3.3.2 > > > During call to MuxMessageDispatcher.castMessage(...) any exclusion list defined in the RequestOptions get lost in MuxMessageDispatcher's overridden cast(...) methods. -- 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

12 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 June 2013