Announcement Announcement Module
Collapse
No announcement yet.
/j_acegi_security_check and jsessionid Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • /j_acegi_security_check and jsessionid

    Hi all,
    how do you deal with sessions (only based on url rewriting) that should survive a login.

    I have the situation that I would like a customer to log-on at a certain point in time. On this point he could already have a session. If the customer now tries to log in he isn't able to do this because the jsessionid changes the URL so acegi doesn't recognize the autorization request:

    Code:
    http://localhost:8880/xyz/j_acegi_security_check;jsessionid=1ygetc
    This could be solved by not appending the sessionid to the url, but then I would loose the session of the customer if does not have cookies enabled.
    Or am I wrong with this assumption?

    Is there an easy way out of this situation? E.g. regex on this url would help a lot.

    Thanks,
    Markus

  • #2
    Hi,

    What container are you using and how are you handling the URL rewriting?

    I just spoke to Ben and he tried running the contacts sample app with Tomcat 5.5.7 with cookies switched off. The login worked without any problems.

    The jsessionid parameter should be removed by the container before it reaches the Acegi code so it shouldn't affect the URL matching.

    If you're using a different container, can you try the contacts application and let us know if it works?

    Thanks,

    Luke.

    Comment


    • #3
      tried it

      Hi Luke,
      thanks for your anwser. I tried the contacts sample coming with the 0.8.1 jar and it has the same issues.

      The container is jetty-plus 5.1.2

      So you think it's a container issue?

      Thanks,
      Markus

      Comment


      • #4
        Could you give it a go in Tomcat and see what your mileage is? I think it's a container issue, as I used the Contacts 0.8.1 sample with Tomcat and cookies disabled just fine (the URL did include the ;jsessionid).

        Comment


        • #5
          hi ben,
          contacts example works perfectly well in tomcat 5.5.7. No problems at all.

          So it's a container question. One thing I also noticed:
          In tomcat the "start" page is hello.htm.
          In jetty it is immediately acegilogin.jsp. But the login behaviour is different than the one I described. If I enter user and password and submit I immediately come back to this page. So it seems like the URL is processed but login is not possible.

          Strange. In my appliation the j_acegi_security_check does not even get processed if a jsessionid is appended (using jetty. Not sure about tomcat haven't tried it yet).

          Anyway, it seems like jetty is a poor choice in conjunction with acegi.

          Comment


          • #6
            Maybe take it up with the Jetty list, as I find Greg and Jan are pretty spec-knowledgable and could probably tell us which HttpServletRequest parameters we're meant to be using if the Jetty behaviour is spec-compliant.

            Comment


            • #7
              I asked on the jetty mailinglist and this is the reply from greg:

              I think this is actually a bug in tomcat, which the acegi code must be written
              to expect!

              I think you will find that acegi code is using the URI returned
              by getRequestURI() to look for a resource. Their code probably is
              expecting the ;jsessionid to be stripped (which tomcat does).

              But Jetty does not strip this - because according to the spec,
              getRequestURI should NOT decode the URI. Also if the container
              strips URI params from getRequestURI, then their is no way for
              a servlet to deal with any other ;name=value URI parameters (all which
              are legal).

              The code should either strip URI params itself - OR it should
              use getServletPath and getPathInfo.
              So it seems like listening on /j_acegi_security_check is not enough. It must be like listening on /j_acegi_security.*

              Comment


              • #8
                I've been reading a bit more on this and it seems there is a difference between "path parameters" which occur before the "?" in a URL and (the more common) "query parameters" which occur after. The jsessionid is one of the former and the definition of getRequestURI states that it should supply the request's "URL from the protocol name up to the query string". So I guess Tomcat is probably wrong in this behaviour, although it could be argued that the jsessionid parameter is no concern of the application's anyway.

                From what I read before, it seemed that the grammar for HTTP URLs didn't allow semi-colons before the query string at all, so the application would be receiving an invalid URL if the sessionid wasn't stripped out (as tomcat does). I may have overlooked something though .

                In any case, if containers other than tomcat are written this way, then I guess we should probably take this into account.

                Luke.

                Comment


                • #9
                  Luke, I'm coming in late on this but given Greg's reply (he's very knowledgable I find) we probably should detect a semi-colon and disregard everything after it. Would you be able to make the change and add a unit test?

                  Comment


                  • #10
                    Originally posted by Ben Alex
                    Luke, I'm coming in late on this but given Greg's reply (he's very knowledgable I find) we probably should detect a semi-colon and disregard everything after it. Would you be able to make the change and add a unit test?
                    OK Ben. I'll have a look at it. I think the grammar I looked at originally was itself wrong.

                    This rfc has a pretty comprehensive description and contradicts it:

                    http://www.faqs.org/rfcs/rfc2396.html

                    Just goes to show - don't trust everything you read on the internet. But then I could be wrong...

                    Comment


                    • #11
                      Hi, has this been fixed?

                      Originally posted by Luke
                      Originally posted by Ben Alex
                      Luke, I'm coming in late on this but given Greg's reply (he's very knowledgable I find) we probably should detect a semi-colon and disregard everything after it. Would you be able to make the change and add a unit test?
                      OK Ben. I'll have a look at it. I think the grammar I looked at originally was itself wrong.

                      This rfc has a pretty comprehensive description and contradicts it:

                      http://www.faqs.org/rfcs/rfc2396.html

                      Just goes to show - don't trust everything you read on the internet. But then I could be wrong...
                      Hello, has this issue been fixed? I am experiencing the exact same issue in my deployment and I am running on acegi version 0.8.3.

                      Assuming a patch is not in 0.8.3, I was wondering when the next release containing a patch might occur?

                      Thanks!

                      Comment


                      • #12
                        I hope to release 1.0.0 around The Spring Experience conference in December. But it'll depend on time. And we'll get a 0.9.0 out before then as well....

                        Comment


                        • #13
                          It looks like there should be a fix for this is CVS and it appears to have been put in place prior to the 0.8.3 release. The requiresAuthentication method strips off everything from the first semi-colon before checking for a match with the authentication url.

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

                          There's also a test method

                          http://acegisecurity.sourceforge.net...rTests.html#73

                          So I can't think of a reason why it would still be failing. I haven't actually tried it with Jetty myself.

                          Luke.

                          Comment


                          • #14
                            Did this problem get fixed? I'm using 1.0RC1 and I'm running into an issue with the session id switching when not using cookies..

                            basically, when j_acegi_security_check;jsessionid=SOMESESSIONID is called, instead of reusing the original session id, it creates a new one and loses the old session (where the the REDIRECT URL is stored). Works just fine when cookies are enabled (the call to j_acegi_security_check doesn't create a new session).

                            Tried it on both Resin 3.0.17, and Tomcat 5.5.18 and both have the same problem.

                            Comment


                            • #15
                              This sounds like a different issue and could be a bug.

                              Can you raise an issue in Jira and it will be looked into.

                              Comment

                              Working...
                              X