Announcement Announcement Module
Collapse
No announcement yet.
Simultaneous session forms Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Simultaneous session forms

    Hi,

    Does Spring prevent you from keeping multiple session forms in a session at the same time? I have an app that needs to do that, keeps a form for a user search filter, and one for the current user that was selected for viewing (so that you can go back to the search list and see the same search as what you started from). When I select a user from the search list, and try to go back to the search page (using a redirect view to the search url), the command bean is no longer in the session.

  • #2
    I figured out what the problem was. When I use the redirect view from the details page back to the search page, I'm actually moved to a different session.
    I don't understand why this is happening (after all the session id is stored in the browser cookie). I may be able to fix this, but I didn't like the idea of a redirect in the first place, so here's what I'm doing - maybe there's a way to solve it without redirects:
    I have two controllers that keep their command objects in the session. One is a user search controller (SimpleFormController), the other is a user details controller (AbstractWizardFormController). I am invoking the second one by selecting a user from user list fetched by the first one. I go through several pages, and, when done, I want to return to the search screen (as it was when I left it).
    The way I implemented it, in the processFinish method of my user details wizard, I return a redirect view which points back to the search url. I was hoping that, since the search keeps its command in the session, it would just pick up the search criteria from there, and regenerate the results. The problem, though, as I said, is that the redirect actually points me to a different session.
    Any suggestions? Thanks.

    Comment


    • #3
      The session form is only temporarily stored in the session in between page views. For the actual page view, the form is removed from the session and added to the request. If you redirect, you lose your request attributes, hence you have no form.

      The redirect does not give you a new session.

      Bob

      Comment


      • #4
        It does create a new session, though. I put a breakpoing on the handleRequestInternal method of AbstractFormController, and I check the session id there. Before the redirect the session id is the same for all requests, after the redirect it changes and keeps its new value until another redirect happens (at which point a new id gets generated, and so on). Anybody have any ideas why a redirect would cause the server to create a new session? Thanks

        Comment


        • #5
          What server are you using and in what configuration?

          The only thing that I can think of that could cause a redirect to create a new session is if you're using loadbalancing and its been misconfigured.

          Bob

          Comment


          • #6
            I sort of solved it by getting rid of redirects entirely and passing the name of the search controller to the user details wizard, like this:
            HTML Code:
            <code>
            protected ModelAndView processFinish(HttpServletRequest request,
            			HttpServletResponse response, Object command,    BindException errors)
            			throws Exception {
            		ApplicationContext ctx = getApplicationContext();
            		Controller ctrl =  (Controller) ctx.getBean(cancelController);
            		return ctrl.handleRequest(request, response);
            	}
            </code>
            This seems to work, but I don't know if it's correct from a framework point of view. If anybody has any input on this, or the redirect problem posted earlier, please let me know. Thanks.

            Comment


            • #7
              Hey Bob,
              I'm using Tomcat 5.5, with no load balancing or anything fancy around it. I'm deploying the application using the sysdeo tomcat plugin from eclipse.

              Comment


              • #8
                Do you have cookies disabled in your browser? If so you'll need to add the jsessionid onto the end of each request.

                If that's not the case, then I'm stumped.

                Bob

                Comment


                • #9
                  No, I haven't. I know that for sure because I do my authentication using CAS, and that only works if cookies are enabled. I checked my browser settings on that, too.

                  Is it possible that on redirects browsers don't send cookies back to the corresponding server? Never heard of that before, but I can't think of anything else.

                  Comment


                  • #10
                    Ahhh, that might be the problem. I've never used CAS before, but I have had the misfortune to use Tivoli Access Manager in conjunction with WebSEAL, and you have to expicitly tell it to forward on the session cookie, otherwise it strips it out. Maybe CAS does that too?

                    Bob

                    Comment


                    • #11
                      I don't know...I don't think the CAS server is involved at this point. After the initial authenticatin with CAS, everything works OK. I checked the session, and it accumulates the session command objects I put there. It is only when I do the redirect that the session gets blown away.

                      Comment


                      • #12
                        Remember that a redirect is not performed inside your server. An HTTP 3xx (probably 302) code is sent back to your browser and your browser does the redirect, so I suspect that your authentication server might get involved.

                        Bob

                        Comment


                        • #13
                          That's how I looked at it myself. From this point of view, a redirect should be the same as retyping the search url in the browser window, but it actually behaves differently, since, if I just put the url in there, everything works fine.
                          I'll try to find any CAS documentation on this issue, though, and, if I get some time, try to plug in a different type of authentication and compare. Thanks for your help.
                          As far as my "forward" improvisation goes (calling the target controller directly), do you see any potential problems?

                          Comment


                          • #14
                            Don't see any problems with that - though it might be cleaner to return an InternalResourceView (same package as RedirectView)

                            Bob

                            Comment


                            • #15
                              Will returning an InternalResourceView cause the controller associated with that view to be executed? I tried just returning the view, and doesn't find the command object it's supposed to get its data from (probably, as you said, because the controller does not take it from the session to make it available in the model)

                              Comment

                              Working...
                              X