November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4968) Deployment Level Principal Role Mapping should be transferred to the authorization layer

by Anil Saldhana (JIRA)

Deployment Level Principal Role Mapping should be transferred to the authorization layer ---------------------------------------------------------------------------------------- Key: JBAS-4968 URL: http://jira.jboss.com/jira/browse/JBAS-4968 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: EJB2, EJB3, Security, Web (Tomcat) service Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta3 Need an update to the metadata model such that we can get a principal versus rolename(s) map (basically a reverse hashmap) from JBossAssemblyDescriptorMetaData. The original call was "AssemblyDescriptor ad = container.getAssemblyDescriptor()". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4751) JBossWebRealm has redundant threadlocal activeRequest

by Anil Saldhana (JIRA)

JBossWebRealm has redundant threadlocal activeRequest ----------------------------------------------------- Key: JBAS-4751 URL: http://jira.jboss.com/jira/browse/JBAS-4751 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Security, Web (Tomcat) service Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta3 There has been an introduction of a threadlocal in SecurityAssociationValve to store the current request. This thread local can be used in JBossWebRealm to remove its own threadlocal that stores the servletName. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPM-1080) Limit BAM Query to input data for simulation to time range doesn't work

by Bernd Ruecker (JIRA)

Limit BAM Query to input data for simulation to time range doesn't work ----------------------------------------------------------------------- Key: JBPM-1080 URL: http://jira.jboss.com/jira/browse/JBPM-1080 Project: JBoss jBPM Issue Type: Feature Request Components: Simulation Affects Versions: jBPM jPDL 3.2.2 Reporter: Bernd Ruecker Assigned To: Tom Baeyens Priority: Minor The GetSimulationInputCommand has a parameter "fromTimeOfDay" and "tillTimeOfDay". This should be included in the hibernate quries to supprto to query statistical data only for special times (for example shifts). Unfortunately, comparing the time is not really easy with supporting different databases. In MySQL, there is a TIME(xxx) function, HSQL only supports HOUR(xxx) and MINUTE(xxx). Si I skipped it for the moment. The mySQL ready statements are commented out in the queries file. Co currently, ALL statistics from all 24 hours are returned. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3976) Stateful Session Bean throws a Null Security Context exception with no login

by Anil Saldhana (JIRA)

Stateful Session Bean throws a Null Security Context exception with no login ---------------------------------------------------------------------------- Key: JBAS-3976 URL: http://jira.jboss.com/jira/browse/JBAS-3976 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1, JBossAS-4.0.5.SP1 Since the stateful session bean instance interceptor happens before the security interceptor (security exceptions need to invalidate the session), the call to set the principal on the enterprise context can fail when the bean was invoked with no login. Remember the getCallerPrincipal call on the context needs to always return a non-null principal. If the setting of the principal on the context happens after the security checks have been made via the security interceptor, there is security domain settings reflected via the unauthenticated principal setting on the domain into the principal to be set on the context. Of course the user can always specify the unauthenticated-principal tag in jboss-app.xml/jboss.xml DD but this should not be mandatory. There is a need for a new interceptor after the security interceptor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 8 months

4
5
0 / 0

[JBoss JIRA] Updated: (JBAS-2482) Investigate integration of FORM auth with a SAML style identity provider

by Anil Saldhana (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2482?page=all ] Anil Saldhana updated JBAS-2482: -------------------------------- Component/s: Security Web (Tomcat) service Fix Version/s: JBossAS-5.0.1.CR1 (was: JBossAS-5.0.0.Beta3) > Investigate integration of FORM auth with a SAML style identity provider > ------------------------------------------------------------------------ > > Key: JBAS-2482 > URL: http://jira.jboss.com/jira/browse/JBAS-2482 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service, Security > Reporter: Scott M Stark > Assigned To: Anil Saldhana > Fix For: JBossAS-5.0.1.CR1 > > > We need to investigate how one can update the FORM authentication layer to delegate the authentication to an identity provider. Issues include: > 1. authentication of the form username/password > 2. authentication of an existing login from another app using SSO > 3. reauthentication if the web session outlives the IDP token validity > 4. propagation of the identity to other secure components. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4950) Transaction failover authorisation is broken within UnifiedInvokerHAProxy

by Galder Zamarreno (JIRA)

Transaction failover authorisation is broken within UnifiedInvokerHAProxy ------------------------------------------------------------------------- Key: JBAS-4950 URL: http://jira.jboss.com/jira/browse/JBAS-4950 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Remoting Affects Versions: JBossAS-4.2.2.GA, JBossAS-5.0.0.Beta2 Reporter: Galder Zamarreno Assigned To: Brian Stansberry UnifiedInvokerHAProxy.invoke() only calls invocationHasReachedAServer(Invocation invocation) if GenericClusteringException is received and the exception is not GenericClusteringException.COMPLETED_NO This is not correct because invocationHasReachedAServer(Invocation invocation) needs to be called on successful returns as well. If we don't, the code never remembers that a call within a transaction was successful and therefore, never adds the potential transaction (with JBAS-4455, this will transaction propagation context) associated with the call to the failover map authorisations. Example: - ok call 1 within tx1 - ok call 2 within tx1 - ok call 3 within tx1 - fail call 4 with GenericClusteringException.COMPLETED_NO None of the successfull calls updated the map, so when the 4 call occurs, txContextAllowsFailover(invocation) is called, but the map is empty, so would allow failover when it shouldn't. A transaction reached the server already in any of the previous calls associated with that transaction. JRMPInvokerProxyHA does not have this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 8 months

2
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1108) The EJB3 Consumer test is not thread safe

by Adrian Brock (JIRA)

The EJB3 Consumer test is not thread safe ----------------------------------------- Key: EJBTHREE-1108 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1108 Project: EJB 3.0 Issue Type: Task Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: AS 5.0.0.Beta3 The EJB3 Consumer testQueueXA appears to be checking that method2 is invoked after method1. However, it creates an ActivationSpec with the default maxSession=15 which means methods can compete with each other to be delivered on upto 15 threads. It needs changing to be single threaded delivery to consistently pass this test. @Consumer(activationConfig = { @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"), @ActivationConfigProperty(propertyName="destination", propertyValue="queue/mdbtest"), + @ActivationConfigProperty(propertyName="maxSession", propertyValue="1") }) public class QueueTestConsumer implements QueueTestRemote, QueueTestXA, QueueTestLocal -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBFORUMS-265) duplicated id JSF/Facelets issue

by Ryszard Kozmik (JIRA)

duplicated id JSF/Facelets issue -------------------------------- Key: JBFORUMS-265 URL: http://jira.jboss.com/jira/browse/JBFORUMS-265 Project: JBoss Forums Issue Type: Bug Components: Forum View Layer Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Priority: Critical Fix For: 1.0.1 RC, 1.1.0 Alpha After adding a new forum a duplicated id exception is being thrown. Same issue appears in edit mode of notification type for a subscribed forum in MyForums view. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 8 months

2
2
0 / 0

[JBoss JIRA] Commented: (JBAS-2235) Server Controller Tasks: Throw error if normal shutdown fails

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2235?page=comments#action_12387340 ] Dimitris Andreadis commented on JBAS-2235: ------------------------------------------ Let me recap my take: 1) I want the build to continue. When the whole testsuite takes 4+ hours to complete I don't want a small mistake in one custom configuration to ruin all the results. Now if we can somehow highlight that we have a server start/stop problem, that would be nice. 2) Adrian's idea should be tried out. - try a normal shutdown (with a timeout) - try a -H shutdown (force the JVM to halt) - kill the process > Server Controller Tasks: Throw error if normal shutdown fails > ------------------------------------------------------------- > > Key: JBAS-2235 > URL: http://jira.jboss.com/jira/browse/JBAS-2235 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Test Suite > Environment: jboss-4.0 tip > Reporter: Ryan Campbell > Assigned To: Martin Vecera > Fix For: JBossAS-5.0.0.Beta3 > > > Currently, when a server fails to respond to a shutdown request, the process is killed and the tests continue. > There should be an error thrown if the server fails to shutdown within the timeout period. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 8 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-2235) Server Controller Tasks: Throw error if normal shutdown fails

by Aleksandar Kostadinov (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2235?page=comments#action_12387314 ] Aleksandar Kostadinov commented on JBAS-2235: --------------------------------------------- So if we allow test suite to continue execution, then how will we notice that a server failed to shutdown? I think we should do one of: 1. fail the build 2. generate a simple junit xml report file indicating what's wrong > Server Controller Tasks: Throw error if normal shutdown fails > ------------------------------------------------------------- > > Key: JBAS-2235 > URL: http://jira.jboss.com/jira/browse/JBAS-2235 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Test Suite > Environment: jboss-4.0 tip > Reporter: Ryan Campbell > Assigned To: Martin Vecera > Fix For: JBossAS-5.0.0.Beta3 > > > Currently, when a server fails to respond to a shutdown request, the process is killed and the tests continue. > There should be an error thrown if the server fails to shutdown within the timeout period. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 8 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 2007