Announcement Announcement Module
Collapse
No announcement yet.
Spring Security 2 not working with WebSphere? Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by inkspot23 View Post
    The instructions and links worked for our cluster and j_security session issue. Our version is 6.1.0.15 and it worked. Thanks for the followup.
    Hi inkspot23,
    Could you give me some details on how you got this work on a cluster environment?
    We are facing the situation where we can have this worked in our local environments using WAS 6.1.0.21, but when we deploy to production environment where we have a cluster environment, it does not work. The settings are the same on both environments: (1) Defining the custom property for Web container; (2) The fix pack PK33090 should already be included in WAS 6.1.0.21; (3) Classloaders set to PARENT_FIRST

    Thank you very much in advance.

    Comment


    • #17
      I have a web app that works on tomcat. But it does not work on both Websphere 6.1.0.17 and 6.1.0.21 with com.ibm.ws.webcontainer.invokefilterscompatibility set to true. It complains
      Error 404: SRVE0190E: File not found: /j_spring_security_check. I'm not sure how to work around this one. Any help/advice would be much appreciated.

      Comment


      • #18
        Spring Security also not working on WebSphere

        Originally posted by nsjxu View Post
        I have a web app that works on tomcat. But it does not work on both Websphere 6.1.0.17 and 6.1.0.21 with com.ibm.ws.webcontainer.invokefilterscompatibility set to true. It complains
        Error 404: SRVE0190E: File not found: /j_spring_security_check. I'm not sure how to work around this one. Any help/advice would be much appreciated.
        I'm in the same boat: a WAS 6.1.0.21 clustered environment. App & security work fine under Tomcat, do not in WebSphere.

        I've set the com.ibm.ws.webcontainer.invokefilterscompatibility customer parameter to true and put a dummy "blank" j_acegi_security_check file in the root of the application.

        So it's no longer throwing the file not found exception, but it throws the following error/stack trace:

        Error Message: Filter [springSecurityFilterChain]: filter is unavailable.
        Error Code: 500
        Target Servlet: null

        java.lang.NullPointerException
        at com.xxx.orderlink.model.MenuFactory.isAuthorized(M enuFactory.java:257)
        at com.xxx.orderlink.model.MenuFactory.getSessionMenu Code(MenuFactory.java:124)
        at com.xxx.p3.service.security.AuthenticationProcessi ngFilter.initializeMenu(AuthenticationProcessingFi lter.java:128)
        at com.xxx.p3.service.security.AuthenticationProcessi ngFilter.onSuccessfulAuthentication(Authentication ProcessingFilter.java:47)
        at org.springframework.security.ui.AbstractProcessing Filter.successfulAuthentication(AbstractProcessing Filter.java:367)
        at org.springframework.security.ui.AbstractProcessing Filter.doFilterHttp(AbstractProcessingFilter.java: 263)
        at org.springframework.security.ui.SpringSecurityFilt er.doFilter(SpringSecurityFilter.java:53)
        at org.springframework.security.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java :371)
        at org.springframework.security.ui.logout.LogoutFilte r.doFilterHttp(LogoutFilter.java:87)
        at org.springframework.security.ui.SpringSecurityFilt er.doFilter(SpringSecurityFilter.java:53)
        at org.springframework.security.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java :371)
        at org.springframework.security.ui.SessionFixationPro tectionFilter.doFilterHttp(SessionFixationProtecti onFilter.java:68)
        at org.springframework.security.ui.SpringSecurityFilt er.doFilter(SpringSecurityFilter.java:53)
        at org.springframework.security.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java :371)
        at org.springframework.security.context.HttpSessionCo ntextIntegrationFilter.doFilterHttp(HttpSessionCon textIntegrationFilter.java:235)
        at org.springframework.security.ui.SpringSecurityFilt er.doFilter(SpringSecurityFilter.java:53)
        at org.springframework.security.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java :371)
        at org.springframework.security.concurrent.Concurrent SessionFilter.doFilterHttp(ConcurrentSessionFilter .java:97)
        at org.springframework.security.ui.SpringSecurityFilt er.doFilter(SpringSecurityFilter.java:53)
        at org.springframework.security.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java :371)
        at org.springframework.security.util.FilterChainProxy .doFilter(FilterChainProxy.java:174)
        at org.springframework.web.filter.DelegatingFilterPro xy.invokeDelegate(DelegatingFilterProxy.java:183)
        at org.springframework.web.filter.DelegatingFilterPro xy.doFilter(DelegatingFilterProxy.java:138)
        at com.ibm.ws.webcontainer.filter.FilterInstanceWrapp er.doFilter(FilterInstanceWrapper.java:190)
        at com.ibm.ws.webcontainer.filter.WebAppFilterChain.d oFilter(WebAppFilterChain.java:130)
        at org.springframework.orm.jpa.support.OpenEntityMana gerInViewFilter.doFilterInternal(OpenEntityManager InViewFilter.java:112)
        at org.springframework.web.filter.OncePerRequestFilte r.doFilter(OncePerRequestFilter.java:75)
        at com.ibm.ws.webcontainer.filter.FilterInstanceWrapp er.doFilter(FilterInstanceWrapper.java:190)
        at com.ibm.ws.webcontainer.filter.WebAppFilterChain.d oFilter(WebAppFilterChain.java:130)
        at com.ibm.ws.webcontainer.filter.WebAppFilterChain._ doFilter(WebAppFilterChain.java:87)
        at com.ibm.ws.webcontainer.filter.WebAppFilterManager .doFilter(WebAppFilterManager.java:832)
        at com.ibm.ws.webcontainer.filter.WebAppFilterManager .doFilter(WebAppFilterManager.java:679)
        at com.ibm.ws.webcontainer.servlet.FileServletWrapper .handleRequest(FileServletWrapper.java:418)
        at com.ibm.ws.wswebcontainer.servlet.StaticFileServle tWrapper.handleRequest(StaticFileServletWrapper.ja va:164)
        at com.ibm.ws.webcontainer.extension.DefaultExtension Processor.handleRequest(DefaultExtensionProcessor. java:717)
        at com.ibm.ws.wswebcontainer.extension.DefaultExtensi onProcessor.handleRequest(DefaultExtensionProcesso r.java:113)
        at com.ibm.ws.webcontainer.webapp.WebApp.handleReques t(WebApp.java:3444)
        at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequ est(WebGroup.java:267)
        at com.ibm.ws.webcontainer.WebContainer.handleRequest (WebContainer.java:815)
        at com.ibm.ws.wswebcontainer.WebContainer.handleReque st(WebContainer.java:1466)
        at com.ibm.ws.webcontainer.channel.WCChannelLink.read y(WCChannelLink.java:119)
        at com.ibm.ws.http.channel.inbound.impl.HttpInboundLi nk.handleDiscrimination(HttpInboundLink.java:458)
        at com.ibm.ws.http.channel.inbound.impl.HttpInboundLi nk.handleNewInformation(HttpInboundLink.java:387)
        at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCa llback.complete(HttpICLReadCallback.java:102)
        at com.ibm.ws.tcp.channel.impl.AioReadCompletionListe ner.futureCompleted(AioReadCompletionListener.java :165)
        at com.ibm.io.async.AbstractAsyncFuture.invokeCallbac k(AbstractAsyncFuture.java:217)
        at com.ibm.io.async.AsyncChannelFuture.fireCompletion Actions(AsyncChannelFuture.java:161)
        at com.ibm.io.async.AsyncFuture.completed(AsyncFuture .java:136)
        at com.ibm.io.async.ResultHandler.complete(ResultHand ler.java:195)
        at com.ibm.io.async.ResultHandler.runEventProcessingL oop(ResultHandler.java:743)
        at com.ibm.io.async.ResultHandler$2.run(ResultHandler .java:873)
        at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.j ava:1473)

        Comment


        • #19
          Are you completely ignoring the first few lines of your own stack trace? The NPE you are getting is happening in your own code. Set a breakpoint and fire up the debugger.

          Comment


          • #20
            Originally posted by krancour View Post
            Are you completely ignoring the first few lines of your own stack trace? The NPE you are getting is happening in your own code. Set a breakpoint and fire up the debugger.
            Since the code works fine across multiple versions of Tomcat, I'm not convinced the problem is there.

            The NPE is thrown the first time the user object stored in the session is referenced. So the symptom of a null user is just that.

            The user object gets inserted into the session by a class that extends org.springframework.security.ui.webapp.Authenticat ionProcessingFilter. That part works (you can see that the onSuccessfulAuthentication method is called). So it ought to be available to the session.

            And yet for some reason it isn't, but only on WebSphere.

            Comment


            • #21
              Originally posted by GojiraDeMonstah View Post
              The NPE is thrown the first time the user object stored in the session is referenced.
              So is it the UserDetails object itself that is null? That's not clear from your description.

              Also...

              The HttpSessionContextIntegrationFilter has sole responsibility for retrieving any SecurityContext that's been cached in the HttpSession and then poking that into the SecurityContextHolder (which is essentially a threadbound container for your SecurityContext, which in turn contains an Authentication object, which in turn contains the UserDetails object).

              When the NPE occurs in your code, how exactly are you accessing the UserDetails object? Are you grabbing it directly from the session yourself, or taking it from the SecurityContextHolder?

              Can you post the code for the component that's throwing the NPE? That would help a lot.

              Comment


              • #22
                Problem solved - JNDI error

                After authenticating w/Spring Security, there is some legacy code that does a JNDI lookup. That lookup was failing immediately after the user was authenticated. I was thrown off by the filter unavailable error message - looking at the WAS logs uncovered the real problem.

                Apologies if this is O/T but here is the fix I made to my lookup to work with both Tomcat 6.0.16 and WAS 6.1.0.21:
                Code:
                try{
                				// assume we're running on WebSphere
                				java.util.Properties parms = new java.util.Properties();
                				parms.setProperty(Context.INITIAL_CONTEXT_FACTORY,
                	                        "com.ibm.websphere.naming.WsnInitialContextFactory");
                				
                				Context ctx = new InitialContext(parms);
                				DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/myApp");
                				return ds.getConnection();
                			}
                			// if we're not running on WebSphere, catch the exception
                			// and do the lookup Tomcat style
                	        catch(NoInitialContextException e){
                	        	Context initContext = new InitialContext();
                	        	Context envContext = (Context) initContext.lookup("java:/comp/env");
                	        	DataSource ds = (DataSource) envContext.lookup("jdbc/myApp");
                	        	return ds.getConnection();
                	        }

                Comment


                • #23
                  Not to belabor the issue, but you should consider using Spring to do the JNDI lookup. Then deploying to one server or another is just a config change and your code doesn't become coupled to your environment in any way.

                  Try this:

                  Code:
                  <beans xmlns="http://www.springframework.org/schema/beans"
                         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                         xmlns:jee="http://www.springframework.org/schema/jee"
                         xsi:schemaLocation="http://www.springframework.org/schema/beans
                                             http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
                                             http://www.springframework.org/schema/jee
                                             http://www.springframework.org/schema/jee/spring-jee-2.5.xsd">
                  
                  <jee:jndi-lookup id="dataSource" jndi-name="/jdbc/database" resource-ref="true"/>
                  
                  </beans>

                  Comment


                  • #24
                    Websphere/Spring security 404 error-code on login/logout

                    I had exactly the same problem as people on this forum had: the 404 error-code whenever trying to login/logout of an application using Spring security. The error only occurred on WAS for me, but the same code worked fine on Tomcat, confirming this ISN'T a Spring security problem. The information provided by people in this thread was very useful in getting the problem fixed. Our WAS server was already at fixpack level 21, but the Websphere people in my company implemented the web container setting as suggested in this thread, and the problem magically disappeared.

                    Thanks

                    Comment


                    • #25
                      Originally posted by Jwileman View Post
                      I had exactly the same problem as people on this forum had: the 404 error-code whenever trying to login/logout of an application using Spring security. The error only occurred on WAS for me, but the same code worked fine on Tomcat, confirming this ISN'T a Spring security problem. The information provided by people in this thread was very useful in getting the problem fixed. Our WAS server was already at fixpack level 21, but the Websphere people in my company implemented the web container setting as suggested in this thread, and the problem magically disappeared.
                      Allegedly this is a WebSphere "optimization." Without the web container property set, WebSphere thinks that anything not mapped in a servlet-mapping section of the web.xml is static content, so it "optimizes" this call by not even attempting to send it down the filter chain.

                      This used to work with WAS 5.x, in fact. Why is it that an optimization which breaks backward compatibility needs to be actively turned off with a web container setting? Why not require the optimization to be turned on with a setting instead? I'm sure that IBM has their reasons, but they are a mystery to me.

                      Just to re-iterate something I said earlier in this thread... another thing you can do if you don't want to go the web container property route is to enable administrative security and map the login URL to j_security_check (instead of j_spring_security check) and your logout URL to ibm_security_logout. When administrative security is enabled, WAS is smart enough to realize that these URLs are "special" and not static content.

                      Comment


                      • #26
                        Error 404:SRVE0190E: File not found: /j_spring_security_check on WAS 7.0.0.7

                        I am running WAS 7 and tried setting the web container custom property, as suggested, but still getting this error. Wondering if anyone has found a solution for WebSphere 7.0.0.7

                        Comment

                        Working...
                        X