Announcement Announcement Module
Collapse
No announcement yet.
"remember me" requires refresh? Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • "remember me" requires refresh?

    I got remember me working, and it was a really simple config. Only problem is, when I come back to the site it actually doesnt show me as logged in until I do a page refresh (or click on any link within the site). The second page loaded shows me logged in, but not the first.

    This is not a problem with cache, as I can change the JSP source and the new page will show up, just not logged in.

    Anyone else had this problem? Have any ideas?

    My config is pretty much right out of the docs, but I am also using a rewrite filter, defined in web.xml below the acegi filter chain. (I'll post my xml if no one has any ideas from this description.)

    THANKS!

  • #2
    more info

    I realized that it was logging in right away with remember me, but it was not setting the session object "ACEGI_SECURITY_CONTEXT" until after the first page had already processed. So the first page gets back null for that SecureContextImpl object, but future pages see it properly.

    Is there a different/better/more immediate way to access the current user?

    Currently, I am calling:

    reques.getSession().getAttribute("ACEGI_SECURITY_C ONTEXT")

    from within a custom tag on the page to display username, etc.

    any other ideas?

    thanks!

    Comment


    • #3
      try using getSecureContext

      I understand that you are trying to get the SecureContext, if this is so you may use SecureContextUtils.getSecureContext() . If you want only the user name displayed on the first page, try session.getAttribute(AuthenticationProcessingFilte r.ACEGI_SECURITY_LAST_USERNAME_KEY).

      Comment


      • #4
        This makes sense - HttpSessionIntegrationFilter comes first in the list, so you won't be able to access the context via the session until the request has been completed.

        You could try accessing the context directly using SecurityContextHolder.getContext as this should be available immediately after authentication takes place.

        Comment


        • #5
          check the mapping for the filters

          Hi dlevine.

          May be the first page you use to access the site when comming back doesn't trigger the remember me filter.

          Normally all the filters should be triggered before processing the jsps.

          The only thing I can see in your problem is that your jsp is processed and the filter is not.

          Check the URL mapping on you filters.

          paskos

          Comment


          • #6
            Re: check the mapping for the filters

            Originally posted by paskos
            Hi dlevine.

            May be the first page you use to access the site when comming back doesn't trigger the remember me filter.

            Normally all the filters should be triggered before processing the jsps.

            The only thing I can see in your problem is that your jsp is processed and the filter is not.

            Check the URL mapping on you filters.

            paskos
            I don't think this is correct. The filter is being processed - it's just that the context isn't available from the HttpSession until the request has (almost) been completed and HttpSessionIntegrationFilter sets it on the way out here:

            http://acegisecurity.sourceforge.net...ilter.html#266

            Comment


            • #7
              Thank you all for replies. You are correct Luke, the filter is being processed. I will try out the other suggestions this afternoon -- Thank you!

              You could try accessing the context directly using SecurityContextHolder.getContext as this should be available immediately after authentication takes place.
              If you want only the user name displayed on the first page, try session.getAttribute(AuthenticationProcessingFilte r.ACEGI_SECURITY_LAST_USERNAME_KEY).
              Those look helpful, and I will try them next. What is the standard way to check and see if a user is logged in from within a Servlet/JSP? What about to get the User Details object?

              I'll post my results in a few hours... thanks again!

              Comment


              • #8
                SecurityContextHolder.getContext().getAuthenticati on() gives you a reference to the current authentication object. From that you can access the UserDetails object.

                Note that the names and so on have changed - it might be an idea to upgrade if that's feasible, possibly when 0.9.0 comes out.

                Comment


                • #9
                  I should probably have said that the UserDetails is available from the getPrincipal() method (assuming you're using a DAO provider).

                  Comment


                  • #10
                    IT WORKS!

                    I was actually already doing "getContext().getAuthentication().getPrincipal ()", but I was doing it from

                    reques.getSession().getAttribute("ACEGI_SECURITY_C ONTEXT")

                    instead of

                    SecureContextUtils.getSecureContext()

                    Thanks Grasshopper!!! and to Luke for your help and paskos... =)

                    Comment


                    • #11
                      Good

                      Like I said though, if you're still early on in development you should try and upgrade 'cos SecureContextUtils, SecureContextImpl etc. don't exist anymore. Probably better not to lock yourself into an outdated syntax if you don't need to.

                      Comment


                      • #12
                        hehehehe... an excellent suggestion! =)

                        Comment


                        • #13
                          first off, I am still using v. 0.8.2 and I need to keep that for now.

                          When i switched from using request.getSession().getAttribute("ACEGI_SECURITY_ CONTEXT") to using SecureContextUtils.getSecureContext() it did fix the problem of "remember me requires refresh". However, I am now getting an exception when I hit some pages. It doesnt seem to affect anything (everything seems to work), but I'd like to figure out what is going on.

                          Code:
                          java.lang.IllegalStateException: ContextHolder invalid: 'null': are your filters ordered correctly? HttpSessionContextIntegrationFilter should have already executed by this time (look for it in the stack dump below)
                          [full stack trace below]

                          My filter chain looks like this:

                          Code:
                          	<bean id="filterChainProxy"
                          		class="net.sf.acegisecurity.util.FilterChainProxy">
                          		<property name="filterInvocationDefinitionSource">
                          			<value> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
                          				PATTERN_TYPE_APACHE_ANT
                          				/**=HttpSessionContextFilter,AuthenticationProcessingFilter,rememberMeProcessingFilter,SecurityEnforcementFilter
                          			</value>
                          		</property>
                          	</bean>
                          So it should be hitting the HttpSessionContextFilter first. Why would SecureContextUtils.getSecureContext() be throwing that exception (only on certain pages, repeatable) when I call it to get the Context?

                          Heres' the full stack trace...

                          Code:
                          13&#58;43&#58;37,781 ERROR &#91;localhost&#93;&#58;373 - Exception Processing ErrorPage&#91;errorCode=404, location=/pageHandler.htm&#93;
                          java.lang.IllegalStateException&#58; ContextHolder invalid&#58; 'null'&#58; are your filters ordered correctly? HttpSessionContextIntegrationFilter should have already executed by this time &#40;look for it in the stack dump below&#41;
                          	at net.sf.acegisecurity.context.security.SecureContextUtils.getSecureContext&#40;SecureContextUtils.java&#58;38&#41;
                          	at tv.current.web.studio.security.SecurityHelper.getCurrentUsername&#40;SecurityHelper.java&#58;39&#41;
                          	at org.apache.jsp.WEB_002dINF.jsp.site.studioPageHandler_jsp._jspService&#40;org.apache.jsp.WEB_002dINF.jsp.site.studioPageHandler_jsp&#58;95&#41;
                          	at org.apache.jasper.runtime.HttpJspBase.service&#40;HttpJspBase.java&#58;97&#41;
                          	at javax.servlet.http.HttpServlet.service&#40;HttpServlet.java&#58;802&#41;
                          	at org.apache.jasper.servlet.JspServletWrapper.service&#40;JspServletWrapper.java&#58;322&#41;
                          	at org.apache.jasper.servlet.JspServlet.serviceJspFile&#40;JspServlet.java&#58;291&#41;
                          	at org.apache.jasper.servlet.JspServlet.service&#40;JspServlet.java&#58;241&#41;
                          	at javax.servlet.http.HttpServlet.service&#40;HttpServlet.java&#58;802&#41;
                          	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;252&#41;
                          	at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;173&#41;
                          	at org.apache.catalina.core.ApplicationDispatcher.invoke&#40;ApplicationDispatcher.java&#58;672&#41;
                          	at org.apache.catalina.core.ApplicationDispatcher.processRequest&#40;ApplicationDispatcher.java&#58;465&#41;
                          	at org.apache.catalina.core.ApplicationDispatcher.doForward&#40;ApplicationDispatcher.java&#58;398&#41;
                          	at org.apache.catalina.core.ApplicationDispatcher.forward&#40;ApplicationDispatcher.java&#58;301&#41;
                          	at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel&#40;InternalResourceView.java&#58;97&#41;
                          	at org.springframework.web.servlet.view.AbstractView.render&#40;AbstractView.java&#58;250&#41;
                          	at org.springframework.web.servlet.DispatcherServlet.render&#40;DispatcherServlet.java&#58;928&#41;
                          	at org.springframework.web.servlet.DispatcherServlet.doDispatch&#40;DispatcherServlet.java&#58;705&#41;
                          	at org.springframework.web.servlet.DispatcherServlet.doService&#40;DispatcherServlet.java&#58;625&#41;
                          	at org.springframework.web.servlet.FrameworkServlet.serviceWrapper&#40;FrameworkServlet.java&#58;386&#41;
                          	at org.springframework.web.servlet.FrameworkServlet.doGet&#40;FrameworkServlet.java&#58;346&#41;
                          	at javax.servlet.http.HttpServlet.service&#40;HttpServlet.java&#58;689&#41;
                          	at javax.servlet.http.HttpServlet.service&#40;HttpServlet.java&#58;802&#41;
                          	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;252&#41;
                          	at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;173&#41;
                          	at org.apache.catalina.core.ApplicationDispatcher.invoke&#40;ApplicationDispatcher.java&#58;672&#41;
                          	at org.apache.catalina.core.ApplicationDispatcher.processRequest&#40;ApplicationDispatcher.java&#58;465&#41;
                          	at org.apache.catalina.core.ApplicationDispatcher.doForward&#40;ApplicationDispatcher.java&#58;398&#41;
                          	at org.apache.catalina.core.ApplicationDispatcher.forward&#40;ApplicationDispatcher.java&#58;301&#41;
                          	at org.apache.catalina.core.StandardHostValve.custom&#40;StandardHostValve.java&#58;362&#41;
                          	at org.apache.catalina.core.StandardHostValve.status&#40;StandardHostValve.java&#58;283&#41;
                          	at org.apache.catalina.core.StandardHostValve.invoke&#40;StandardHostValve.java&#58;136&#41;
                          	at org.apache.catalina.valves.ErrorReportValve.invoke&#40;ErrorReportValve.java&#58;105&#41;
                          	at org.apache.catalina.core.StandardEngineValve.invoke&#40;StandardEngineValve.java&#58;107&#41;
                          	at org.apache.catalina.connector.CoyoteAdapter.service&#40;CoyoteAdapter.java&#58;148&#41;
                          	at org.apache.coyote.http11.Http11Processor.process&#40;Http11Processor.java&#58;856&#41;
                          	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection&#40;Http11Protocol.java&#58;744&#41;
                          	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket&#40;PoolTcpEndpoint.java&#58;527&#41;
                          	at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt&#40;LeaderFollowerWorkerThread.java&#58;80&#41;
                          	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run&#40;ThreadPool.java&#58;684&#41;
                          	at java.lang.Thread.run&#40;Unknown Source&#41;

                          Comment


                          • #14
                            Well, it should be "HttpSessionContextIntegrationFilter" for a start.

                            There aren't any acegi filters in this stack trace. It's going straight from the container doFilter method into the JSP-specific stuff. Are you sure you're applying the filters properly in your web.xml?

                            Comment

                            Working...
                            X