jboss-jira November 2009

jboss-jira@lists.jboss.org

1 participants
2015 discussions

[JBoss JIRA] Created: (JBXB-228) extract start/end repeatable particle handling from SundaycontentHandler into a handler

by Alexey Loubyansky (JIRA)

extract start/end repeatable particle handling from SundaycontentHandler into a handler --------------------------------------------------------------------------------------- Key: JBXB-228 URL: https://jira.jboss.org/jira/browse/JBXB-228 Project: JBoss XML Binding (JBossXB) Issue Type: Task Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: JBossXB-2.0.2.GA SundayContentHandler collects values of repeatable terms into a ValueList. It should be extracted to a handler for repeatable terms and make ValueList just one of the possible ways to collect values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7076) DeploymentTemplate temp file url is not escaped properly

by Scott M Stark (JIRA)

DeploymentTemplate temp file url is not escaped properly -------------------------------------------------------- Key: JBAS-7076 URL: https://jira.jboss.org/jira/browse/JBAS-7076 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ProfileService Affects Versions: JBossAS-5.1.0.GA Reporter: Scott M Stark Assignee: Scott M Stark The DsDataSourceTemplate applyTemplate method is creating a temp file, but somewhere the file url is not being properly escaped (at least on mac os x), as a temp file name of /var/folders/jY/jY1BDqLkHKO+a4nm+GooZE+++TI/-Tmp-/DsDataSourceTemplate9162352335796065232-ds.xml is created, but when the file is accessed by the vfs, it fails with: java.io.FileNotFoundException: /var/folders/jY/jY1BDqLkHKO a4nm GooZE TI/-Tmp-/DsDataSourceTemplate9162352335796065232-ds.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

3
2
0 / 0

[JBoss JIRA] Created: (JBID-206) Add JBossSTSLoginModule from JBossESB project

by Daniel Bevenius (JIRA)

Add JBossSTSLoginModule from JBossESB project --------------------------------------------- Key: JBID-206 URL: https://jira.jboss.org/jira/browse/JBID-206 Project: JBoss Identity Issue Type: Task Components: Identity-Federation Reporter: Daniel Bevenius Assignee: Daniel Bevenius Priority: Minor Fix For: IDFED-1.0.0.beta3 The JBossESB project created a JBossSTSLoginModule for their SAML integration which uses JBoss Identity. This LM (Login Module) will validate a security token provided by a callbackhandler and upon a successful validation add a new SamlCredential containing the validated assertion to the set of public credentials on the Subject. This task should add this login module to jboss-identity-fed-core. A SamlCredential will also be added as will a simpel TokenCallback class -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
9
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1755) Support Separate Integration Support for EAP 5 and AS 5

by Howard Gao (JIRA)

Support Separate Integration Support for EAP 5 and AS 5 ------------------------------------------------------- Key: JBMESSAGING-1755 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1755 Project: JBoss Messaging Issue Type: Task Affects Versions: EAP/SOA-P Integration, AS 5.0 Integration Reporter: Howard Gao Fix For: EAP/SOA-P Integration, AS 5.0 Integration Now EAP 5 will be more and more different from AS 5 releases, it requires JBM to support them separately. That means we need separate set of build targets for each of them. Currently JBM only have one AS5 target that serves both releases. This may not possible in the future as the two are becoming further apart. The worse could happen when the two requires different JBM changes on source code level. For example, JGroups 2.8 update now requires JBM to change its source code to accommodate it (AS5), but EAP 5 so far still using jgroups 2.6. So, adding one more target (EAP5) is a solution to the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2462) PortalNode permissions check problem for child Windows

by Andy Pemberton (JIRA)

PortalNode permissions check problem for child Windows ------------------------------------------------------ Key: JBPORTAL-2462 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2462 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.7.2 Final, 2.6.8 Final Reporter: Andy Pemberton Attachments: portalnode-permissions.patch I believe there is an issue in the PortalNode API when building the map of children for a given node. The issue lies in the strategy for checking the permissions on a Page (PortalObjectPermission - configured in *-object.xml) vs. Window (InstancePermission - configured in portlet-instances.xml). The current implementation: PortalNodeImpl.NodeList.buildChildMap(PortalNodeImpl objectNode) checks permissions for each child node as follows: ... if (!visible) { visible = portalAuthorizationManager.checkPermission(new PortalObjectPermission(childObject.getId(), PortalObjectPermission.VIEW_MASK)); } ... The problem here is that when building the child map for a page, the children may be either other Pages or portlet Windows; the current code only correctly checks permissions for child Pages. I think the above code should check the permissions as follows: ... if (!visible) { if (childObject.getType() == PortalObject.TYPE_WINDOW) { visible = objectNode.portalAuthorizationManager.checkPermission(new InstancePermission(((WindowImpl) childObject).getURI(), InstancePermission.VIEW_ACTION)); } else { visible = objectNode.portalAuthorizationManager.checkPermission(new PortalObjectPermission(childObject.getId(), PortalObjectPermission.VIEW_MASK)); } } ... This issue may be less apparent because the implementation first checks the 'viewrecursive' permission on pages and if it exists, doesn't check the window permissions at all. One way to reproduce the issue is to ensure a given page is secured with 'view' permission only and then use the PortalNode API to create a link from one portlet to another on the same page (as suggested in section 13.9.3 of the reference guide: 'Link to other pages' http://docs.jboss.com/jbportal/v2.7.1/referenceGuide/html_single/#d0e7436). I've checked that this issue exists in JBP 2.6 and 2.7; I've attached a patch that I've tested against 2.6.5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

1
2
0 / 0

← Newer
1
...
199
200
201
202
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2009