Re: EJB & Web App losing Subject
djencks wrote:
>
> Subject subject = getSpringAuthenticatedSubject();
> ContextManager.registerSubject(subject); //if the subject is cached in
> a session this should only happen once when the subject is first
> authenticated/constructed.
>
> //the following should happen on every request
> ContextManager.setCallers(subject, subject);
> try {
> //process request
> } finally {
>ContextManager.clearCallers();
> }
>
Our custom Spring authenticator contains calls to ContextManager.login and
setCallers. If we need to call setCallers for every request, then that
would explain this bug. We only call it once, and don't call clearCallers,
so the subject is staying around in the original thread but subsequent
threads never get initialized properly.
Sounds like the proper solution is just a simple filter that does the
setCallers and clearCallers. Thanks for all the help.
--
View this message in context:
http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24502831.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: EJB & Web App losing Subject
djencks wrote: > > OK, this is weird, I've never seen a bug in this area. What kind of > authentication does the web app use? Can you show the entire stack > trace to the ejb security exception? > If that's the case then my gut is that the bug is somewhere in the web app, but as I didn't write it and have never seen this kind of error before I'm at a bit of a loss on where to look. Time to get creative I guess. We are using Spring's authentication framework with a custom authenticator. The exception stack itself is bog-standard so I doubt it will reveal anything, but here it is: javax.ejb.EJBAccessException: Unauthorized Access by Principal Denied at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:144) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:245) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy39.getMyFavorites(Unknown Source) at ourcode.SomeStatelessBean.getMyFavorites(SomeStatelessBean.java:58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:158) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:141) at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy35.getMyFavorites(Unknown Source) at ourcode.dao.impl.MyFavoritesDaoImpl.getFavoriteList(MyFavoritesDaoImpl.java:42) at ourcode.service.impl.MyFavoritesServiceImpl.getFavoriteList(MyFavoritesServiceImpl.java:30) at ourcode.web.controller.MyFavoritesController.getFavoriteList(MyFavoritesController.java:32) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doInvokeMethod(HandlerMethodInvoker.java:409) at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:132) at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:310) at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:297) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378) at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109) at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java
Re: EJB & Web App losing Subject
djencks wrote: > What creates the new non-working thread? In geronimo we generally > don't assume anything about the relationship between threads so if you > want the new thread to get a particular security context you'll have > to install it youself. Just to clarify, we aren't trying to create new threads. I just assumed that geronimo/tomcat was doing it to service multiple connections or something. Looking at the bottom of the stack dump for the exception, it looks like a tomcat worker thread: at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) The snipped part is all the valve, filter, controller and openejb stuff, pretty standard. Oh, and I forgot to mention in the original post that we're using 2.1.4. -- View this message in context: http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24487458.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
EJB & Web App losing Subject
A web app (built with Spring & GWT) we're building is currently having issues with security and EJBs. Some calls made by the app to EJBs are throwing "Unauthorized Access by Principal Denied" exceptions. Investigating this it seems that whenever a new thread in geronimo is started to service the call the auth credentials aren't being copied. For example, ContextManager.login is called in thread "http-0.0.0.0-8443-1", and subsequent EJB calls work correctly. Some time later a new thread "http-0.0.0.0-8443-2" is created and the EJB call takes place in it. Geronimo notices that there isn't a subject and installs the default subject (using ContextManager.setCallers), which of course doesn't have the required principals. I'm assuming the thread spawning is normal though I don't know that. We do have another web app, using Spring but not GWT, that is working correctly. Both web apps use custom LoginModules, though not the same ones. Could this be caused by the web app? Where could I look to get more information? -- View this message in context: http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24485373.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Eclipse Utility Projects with 2.1.2
Turns out due to a bug in WTP I couldn't go to the J2EE Dependencies page, which meant I couldn't add the project to the classpath correctly. I've since worked around the WTP bug and all is well. Thanks again for the quick turnaround with this. Tim McConnell-2 wrote: > > Hi Kory, are you using the Eclipse all-in-one bundle (e.g., > eclipse-jee-ganymede-win32.zip for windows) ?? > -- > Thanks, > Tim McConnell > > -- View this message in context: http://www.nabble.com/Eclipse-Utility-Projects-with-2.1.2-tp19402144s134p19498402.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Eclipse Utility Projects with 2.1.2
Should we move this into the JIRA? I was able to create the Utility Project successfully. If I export the EAR, then Eclipse bundles it correctly into the EAR file (whether it is put into the root or the lib directory depends on a setting in the EAR's project.) However inside Eclipse the contents of the project are not being found. Specifically, the project does not appear in the WTP's "EAR Libraries" classpath container. Here's the confusing part. We have 3 utility projects (I hadn't noticed these before) that were working in 2.0.2 and are still working in 2.1.2. I tried everything I could think of comparing these (which work fine) to the one I created above (which doesn't work) and manually modifying files outside of Eclipse, etc.. I couldn't get the new one to work no matter what I did. I even cloned one of the working projects, changed it's name, and it wouldn't work. I'll look into this more tomorrow, hopefully something will come to me in the meantime. I did notice that going to the "Java EE Module Dependencies" page in the properties of any project other than the EAR project (including EJB, WEB and utility projects) would give a "Could not accept changes" "The currently displayed page contains invalid values" error message. Not sure if this is new or not. Tim McConnell-2 wrote: > > Hi Kory, sorry for the misunderstanding. I though you were actually using > the > geronimo-service.xml file, when you were in fact just using Java EE > Utility > projects. So obviously we erroneously removed support for utility projects > having > Geronimo as a target runtime when we removed support for > geronimo-service.xml > files (via GERONIMODEVTOOLS-356). This support has been added back. Would > you be > able to test it out to ensure it works now for you ?? I've placed the zip > on our > unstable site, but you'll have to uninstall your current GEP before > unzipping it > into your current installation. Or better yet, you might want to test it > with a > new Eclipse installation so we don't adversely impact you yet again. > Thanks much > for you help and patience. > > -- View this message in context: http://www.nabble.com/Eclipse-Utility-Projects-with-2.1.2-tp19402144s134p19446786.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Eclipse Utility Projects with 2.1.2
Done, and thanks. https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-513 Tim McConnell-2 wrote: > > Hi Kory, yes please open a JIRA and I'll fix it today. > > -- View this message in context: http://www.nabble.com/Eclipse-Utility-Projects-with-2.1.2-tp19402144s134p19442964.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Eclipse Utility Projects with 2.1.2
Sure. Basically you can include static jars in any web/connector/application project, but that means that if you need to modify the code in that jar you need to go through a manual compile and update step. So instead of using a static jar you create a utility project and reference that in any other project that would have used the jar. When Eclipse does it's automatic compiling and publishing, the contents of the utility project become a jar in the war/ear/rar as desired. I can't tell you the exact way it bundles everything into the EAR though as the only server I have installed is geronimo. So my plan was to use a utility project for the custom login module code, and to put the gbean specific stuff in the geronimo-application.xml. I think I can workaround this by putting the code into an EJB project, but it's not as clean as there will be extra EJB baggage involved. Going back to my last message, I don't think WTP has a concept to map to geronimo-service (though I'm no WTP expert) while utility projects are really just the Eclipse way to organize non-static jar's for an ear/war. djencks wrote: > > > On Sep 11, 2008, at 1:26 PM, Kory Markevich wrote: > > Do you have any idea what that means in non-eclipse-speak? To me it > means nothing :-( > > in ee-land, you can have jars in an ear that are in the classpath of > everything in the ear (typically by putting them in the lib/ dir of > the ear). Does this have anything to do with eclipse utility jars? > > -- View this message in context: http://www.nabble.com/Eclipse-Utility-Projects-with-2.1.2-tp19402144s134p19440968.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Eclipse Utility Projects with 2.1.2
Well, Eclipse assists by having utility projects. From the WTP documentation: An enterprise application can contain utility JAR files that are to be used by the contained modules. This allows sharing of code at the application level by multiple Web, EJB, or application client modules. These JAR files are commonly referred to as utility JAR files. The utility JAR files defined for an enterprise application project can be actual JAR files in the project, or you can include utility Java projects that are designated to become the utility JAR files during assembly and deployment. So it sounds to me that having the geronimo-service.xml in such projects in the first place was a mistake, as these projects are not meant to be deployed by themselves. I don't think the JIRA Tim mentioned should have removed support for utility projects altogether, just geronimo-service.xml. Now I know that geronimo has it's own robust module support, but since that's not exposed to Eclipse directly I'd like to use utility projects. Should I create a JIRA to get this support back in? djencks wrote: > > > I don't know how eclipse assists with this but you can include > configuration for gbeans in any kind of geronimo plan, including that > for ears (geronimo-application.xml or external plan), ejb modules > (openejb-jar.xml), or web modules (geronimo-web.xml). META-INF/ > geronimo-service.xml would only get detected if you were deploying a > jar directly not as a javaee application. > > Generally gbean config is at the end of the plan after all the javaee > stuff. > > thanks > david jencks > > -- View this message in context: http://www.nabble.com/Eclipse-Utility-Projects-with-2.1.2-tp19402144s134p19440108.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Eclipse Utility Projects with 2.1.2
It wasn't in active use, but it is what I was using for the code for a custom application-scoped login module. I had assumed that this was the correct type of project to use for such a beast, as none of the other types seemed correct (it's not an ejb, nor connector, etc.) Is there a preferred way to do this using Geronimo and WTP, or do I have to do some kind of manual project-reference work? Thanks for the help. Tim McConnell-2 wrote: > > Hi Kory, Now I understand. It didn't occur to me that you were generating > a > geronimo-service.xml file. We removed support for that geronimo deployment > plan > since the GEP didn't do anything with it once it was generated. Were you > actually > using the geronimo-service.xml file for something or just generating it ?? > I > suspect you were just generating it and then not using it, in which case > you can > just delete that project without impacting the other projects in your > workspace. > Can you please verify that ?? > -- View this message in context: http://www.nabble.com/Eclipse-Utility-Projects-with-2.1.2-tp19402144s134p19424830.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Eclipse Utility Projects with 2.1.2
Unfortunately there is none. In the normal case, the option is simply not available in the GUI. The error message I received after modifying the XML files manually appears in the Problems view, not the error log. I don't have the original project anymore as I edited one of the XML files manually. It was however dirt simple, which is why I'm fine with simply starting over. It was just a Utility project with one source file, and only one dependency in the geronimo-service.xml file. It should be easy to recreate this case, simply take a 3.4 install with a 2.1.2 server, and try to create a Java EE->Utility Project while choosing the 2.1.2 runtime in the Target Runtime field. In my case the runtime isn't even listed, whereas previously (Eclipse 3.4M6, 2.0.2 server) it worked as expected. Tim McConnell-2 wrote: > > Hi Kory, your configuration sounds fine to me. Could you attach your .log > file > from the workspace .metadata directory so I can hopefully get more > information > about the failure ?? Also, would it be possible to export your old WTP > Utility > Project and email it to me (or attach it if it's not very large) ?? Thanks > much > > -- > Thanks, > Tim McConnell > > -- View this message in context: http://www.nabble.com/Eclipse-Utility-Projects-with-2.1.2-tp19402144s134p19415054.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Eclipse Utility Projects with 2.1.2
We recently upgraded our server from 2.0.2 to 2.1.2, as well as the Eclipse plugin. One project in our application is a WTP Utility Project, and it no longer works. When I attempted to create a new utility project to replace it, I was unable to attach the new project to the installed Geronimo runtime (the list of available runtimes in the project wizard was blank.) No error messages anywhere to give me any clue as to why. At this point I went and edited the fact xml file for the original project directly to point to the correct runtime, etc., but Eclipse gives an error: "Project facet Utility Module is not supported by target runtime Apache Geronimo v2.1" The only info I could find about this was an old JIRA from the 1.0 days. Is this a bug, or is something wrong with my configuration? I'm using the latest release version (2.1.2) of the Eclipse plugin, installed by dumping into the dropins directory. We're using the Eclipse 3.4 release. -- View this message in context: http://www.nabble.com/Eclipse-Utility-Projects-with-2.1.2-tp19402144s134p19402144.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: EJB Authentication Problem
Kevan Miller <[EMAIL PROTECTED]> writes: > Kory, > You can give the latest 2.0.2-SNAPSHOT build a try (http:// > people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/ > assemblies/geronimo-tomcat6-jee5/2.0.2-SNAPSHOT/geronimo-tomcat6- > jee5-2.0.2-20070922.184612-1-bin.zip or similarly named jetty > assembly). It contains a more recent build of OpenEJB. > > We're nearly ready for a new fix release... > > --kevan Login via JNDI worked great, thanks. Looking forward to 2.0.2! Kory Markevich Tech Lead ACL Services Ltd. 1550 Alberni Street | Vancouver | BC | V6G 1A5 Tel: 604 669 4225 Email: [EMAIL PROTECTED] | Web: www.acl.com The contents of this email are confidential and are for the intended recipient(s) named above only. If you are not the intended recipient, any copying, distribution or use of this email is prohibited. If you have received this email in error, please notify the sender and delete the email.
Re: EJB Authentication Problem
David Jencks <[EMAIL PROTECTED]> writes: > I think this is what you need to do. With openejb standalone the > login-by-getting-jndi might work better. We could fix it in geronimo > by having you supply a realm name I guess what I need to know is whether I'm missing something, because from what I can tell both login via JNDI and via JAAS (using org.apache.openejb.client.ClientLoginModule) from a stand-alone client cannot work in 2.0.1 because they both send null as the realm name, which Geronimo rejects. Both of these methods have changed in the latest OpenEJB to allow the realm name to be passed; any idea when those features or equivalent will end up in Geronimo? A workaround is to call ClientSecurity.directAuthorization myself and store the returned identity. This *seems* to work fine, I just had hoped to be able to do something a bit more standard. > If you have a better idea I'm all ears. The problem I see with > configuring the realm name in the server is that you are getting a > global jndi tree containing all ejbs. I think we need to support > each ejb app being deployed to a different security realm, but all of > them accessing the ejbs through the same global jndi tree and network > port. I haven't figured out how to resolve these conflicting needs > without having the client supply the realm name it intends to use to > log in. I don't really have an issue with the realm name being supplied by the client (and your use cases make sense,) it just surprised me that the server didn't have default behaviour for the case when the realm wasn't passed. I had assumed that something like this would be covered by the spec, but I'm inexperienced with EE security. > I think this is a bug. For web apps we won't deploy them if they > have security in the spec dd but no geronimo security configured. > Want to open a jira? It's not an issue for me, so that would be up to you guys. > Sorry I know nothing about eclipse. No problem, I just wanted to let someone know about them. Thanks for the help! Kory Markevich Tech Lead ACL Services Ltd. 1550 Alberni Street | Vancouver | BC | V6G 1A5 Tel: 604 669 4225 Email: [EMAIL PROTECTED] | Web: www.acl.com The contents of this email are confidential and are for the intended recipient(s) named above only. If you are not the intended recipient, any copying, distribution or use of this email is prohibited. If you have received this email in error, please notify the sender and delete the email.
EJB Authentication Problem
I've been doing some research into using Geronimo 2.0.1 to host some EJB3 session beans, interacting with a stand-alone client. I can connect to the server and call methods fine, but I've encountered some difficulties with security. Specifically I've tried using Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS when creating the InitialContext, but this seems to be broken. After some tracing it seems that org.apache.geronimo.openejb.GeronimoSecurityService.login( ) tries to create a LoginContext with a null security realm, which throws an exception and prevents authentication. I noticed that the latest version of OpenEJB has added the key openejb.authentication.realmName, but this is not available in 2.0.1 (and it seems a bit backward having to have the client specify the security realm.) I have been able to use org.apache.openejb.client.ClientSecurity.directAuthentication( ) to successfully authenticate, but it seems a bit hacky and is very OpenEJB specific (and also requires the client to provide the realm name.) Is there something I'm missing or doing wrong? I'm fairly new to EE stuff so hopefully it's just some newbie mistake. BTW, a couple other things I noticed: - EJB security is disabled if the geronimo-application.xml doesn't at least have an empty entry. This means any security annotations are completely ignored, which surprised me. - EJB3 EAR's will not deploy using the Eclipse plugin unless they contain an application.xml file. Renaming the ZIP file to an EAR and manually deploying works fine. - When creating new EJB3 projects in Eclipse, all geronimo-*.xml files reference the old schemas. If the schemas are changed to the 2.0.1 versions, then the editors fail (I'm assuming this is due to the EMF JIRA entry?) - When starting Eclipse, there are 3 warnings in the log compaining about 'org.apache.geronimo.deployment.model' and 'org.apache.geronimo.v11.deployment.model'. I tried to disable the 1.0 and 1.1 features to get rid of the warnings (since I didn't need those versions,) but then Geronimo 2.0 wouldn't be listed as an option when creating new projects. The feature wasn't flagged as being broken however. Kory Markevich Tech Lead ACL Services Ltd. 1550 Alberni Street | Vancouver | BC | V6G 1A5 Tel: 604 669 4225 Email: [EMAIL PROTECTED] | Web: www.acl.com The contents of this email are confidential and are for the intended recipient(s) named above only. If you are not the intended recipient, any copying, distribution or use of this email is prohibited. If you have received this email in error, please notify the sender and delete the email.
