November 2008 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Re: Testing under a Security Manager

by ALRubinger

"anil.saldhana" wrote : JBAS acts as an integration platform and can bring out the issues that exist in the core code as well as dependent projects. EJB3 is different in that we don't have good representation within the AS TestSuite. Our integration is tested primarily within the jboss-ejb3-testsuite project, which runs against a full AS. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189222#4189222 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189222

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBContextImpl does not refresh the callerPrincipal

by ALRubinger

Hero, thanks. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189220#4189220 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189220

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Testing under a Security Manager

by anil.saldhana＠jboss.com

For the AS, very few (or none) external dependent projects test under the security manager. JBAS acts as an integration platform and can bring out the issues that exist in the core code as well as dependent projects. I would suggest external projects to have a test run with the security manager enabled. You cannot blindly add privileged blocks. You have to be careful of: | | PublicCoreClass: | | public void changeClassLoader(final ClassLoader cl) | { | AccessController.doPrivileged(new PrivilegedAction<Object>(){ | public Object run() | { | Thread.currentThread().setContextClassloader(cl); | } | } | Here PublicCoreClass is eating up the privileged check. So any callers of PublicCoreClass->changeClassLoader will be able to change tcl. So you have to be careful which operations go into privileged blocks. Make the call as to whether the caller needs to be shielded from having permissions for that sensitive operation or not. If an operation is the business of a particular class and the callers should not be aware of it, then those ops go into priv blocks. This includes get/set TCL, reflection etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189219#4189219 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189219

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBContextImpl does not refresh the callerPrincipal

by sguilhen＠redhat.com

Andrew, I'll check out jboss-ejb3-core and add a simple test there. Once I'm finished I'll create a JIRA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189217#4189217 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189217

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBContextImpl does not refresh the callerPrincipal

by ALRubinger

Thanks for reporting. If you could provide us with a Unit Test in jboss-ejb3-core, that'll speed resolution. ;) Either way we'll need a JIRA. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189216#4189216 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189216

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Testing under a Security Manager

by ALRubinger

Anil has located a few failures while running under a Security Manager: https://jira.jboss.org/jira/browse/EJBTHREE-1586 https://jira.jboss.org/jira/browse/EJBTHREE-1587 Which begs the question - what is testing EJB3 code under a Security Manager? At the moment, I think nothing. So I've opened an issue to run the EJB3 TestSuite server configs w/ a very permissive (mock) Policy just to check that we're getting access within privileged blocks where appropriate. https://jira.jboss.org/jira/browse/EJBTHREE-1588 S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189215#4189215 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189215

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - EJBContextImpl does not refresh the callerPrincipal

by sguilhen＠redhat.com

Current implementation of org.jboss.ejb3.EJBContextImpl caches the caller principal and never refreshes it again. As a result, getCallerPrincipal() keeps returning the same principal even if the client logs out and then logs back in with another identity. For example, consider the following session: | @Stateless | public class SimpleStatelessSessionBean implements SimpleSession | { | | @Resource | private SessionContext context; | | public Principal getCallerPrincipal() | { | return this.context.getCallerPrincipal(); | } | } | and this client code: | login("UserA", "PassA"); // calls the LoginContext to authenticate the UserA | | Object obj = getInitialContext().lookup("SimpleStatelessSessionBean/remote"); | SimpleSession session = (SimpleSession) PortableRemoteObject.narrow(obj, SimpleSession.class); | | Principal principal = session.getCallerPrincipal(); | System.out.println("Principal: " + principal.getName()); // prints "Principal: UserA | | logout(); | | // log back in with a different user | login("UserB", "PassB"); | principal = session.getCallerPrincipal(); | System.out.println("Principal: " + principal.getName()); // prints "Principal: UserA" | As we can see, the expected principal in the second call should be UserB, but we end up getting UserA because the EJBContextImpl has cached the previous principal and does not refresh it. When using EJB2x beans this situation doesn't happen because even though the EJBContextImpl caches the principal, there is an instance interceptor (like StatelessSessionInstanceInterceptor) that refreshes the context's principal with the identity it retrieves from the invocation. Thus, when a client switches to another identity, getCallerPrincipal() reflects the change. One way to fix the issue with the EJB3 beans would be to simply get rid of the beanPrincipal property that caches the caller principal and let the getCallerPrincipal() implementation invoke the SecurityContextAssociation to retrieve the updated principal. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189212#4189212 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189212

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: creating integration layer

by clebert.suconic＠jboss.com

"timfox" wrote : | Everyone - please always run tests locally before committing to prevent things like this. I "believe" that test would work if you didn't clean your build before running it. So.. maybe you should not only run tests locally, but also clean your workspace before running it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189211#4189211 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189211

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: creating integration layer

by timfox

Ok, I deleted it View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189209#4189209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189209

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: creating integration layer

by timfox

Jeff was supposed to have fixed this... Can you just delete the test for now, so we can get the build working again? Everyone - please always run tests locally before committing to prevent things like this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189202#4189202 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189202

17 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-dev-forums November 2008