xulunfan / memcached-session-manager

Automatically exported from code.google.com/p/memcached-session-manager
0 stars 0 forks source link

Receive 408 error with forms authentication #171

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1.Log into app with proper credentials, submit the login form
2.Immediately receive 408 error with "j_security_check" in the url  (ex: 
http://myapp.net/j_security_check)
3.If I delete "j_security_check" from the url in the browser and hit enter, I'm 
able to access the app.

What is the expected output? What do you see instead?

This is the main text of the error:
HTTP Status 408 - The time allowed for the login process has been exceeded. If 
you wish to continue you must either click back twice and re-click the link you 
requested or close and re-open your browser

What version of the product are you using? On what operating system?
Tomcat 7.0.39
Windows Server 2008 R2 on Azure (the site is running on two VMs, load balanced 
using Azure load balancing) 
memcached-session-manager-1.6.5
memcached-session-manager-tc7-1.6.5
spymemcached-2.8.12

Please provide any additional information below.

Hers is my manager setting in the context.xml:
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:xxx1.mydomain.com:11211,n2:xxx2.mydomain.com:11211"
    sticky="false"
    sessionBackupAsync="false"
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
    transcoderFactoryClass="de.javakaffee.web.msm.JavaSerializationTranscoderFactory"
/>

As stated above, once I get the initial error if I remove "j_security_check" 
from the url in the browser and hit return, I'm authenticated and the app 
functions normally.  In our attempts to solve the problem, we had put some 
inline scripting code in the login.jsp file where the login form resides.  We 
also saved the credentials the user enters in cookies (j_user & j_pass).  The 
inline code was like the following:

<%
    String j_username = "";
    String j_password = "";
    Cookie[] cookies = request.getCookies();
    for (int i = 0; i < cookies.length; i++) {
        String cookieName = cookies[i].getName();
        if (cookieName.equalsIgnoreCase("j_user")) {
            j_username = cookies[i].getValue();
        } else if (cookieName.equalsIgnoreCase("j_pass")) {
            j_password = cookies[i].getValue();
        }
    }
    String redirectURL = response.encodeURL("j_security_check?j_username="
        + j_username + "&j_password=" + j_password);
        response.sendRedirect(redirectURL);
%>

We found that with this code in place, if the cookies were set when the 
login.jsp was loaded, the authentication would take place and no 408 error 
would occur.  This work around isn't desirable, so any help you can provide 
would be appreciated.   Please let me know if you need any additional 
information.

Thanks.

Original issue reported on code.google.com by Groa...@gmail.com on 18 Jul 2013 at 8:11

GoogleCodeExporter commented 9 years ago
Can you provide a simple sample app (e.g. on github) that allows to reproduce 
the issue?

Original comment by martin.grotzke on 18 Jul 2013 at 11:17

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I did a little more testing, and here's what I found.  I created an extremely 
basic login.jsp, with nothing but the essentials.  Like below:
<form method="POST" action="j_security_check">
<table>
    <tr>
        <td colspan="2">Login to the Tomcat-Demo application:</td>
    </tr>
    <tr>
        <td>Name:</td>
        <td><input type="text" name="j_username" /></td>
    </tr>
    <tr>
        <td>Password:</td>
        <td><input type="password" name="j_password"/ ></td>
    </tr>
    <tr>
        <td colspan="2"><input type="submit" value="Go" /></td>
    </tr>
</table>
</form>

This worked as expected.  Then I started to add back in some of the elements of 
our original login.jsp, and found that it stopped working when we added back an 
image that we had shown on the login screen, something like the following:

<img id='mylogoim' src='images/mylogo.png'/>

I know that "png" is part of the requestUriIgnorePattern we are using. When I 
changed the image name to be mylogo.bmp (bmp is not part of the 
requestUriIgnorePattern) and referenced that in the login.jsp, it worked as 
expected.  So it seems that items that match that condition cannot be in the 
login.jsp.  Is this is expected behavior? 

Thanks.

Original comment by Groa...@gmail.com on 19 Jul 2013 at 7:55

GoogleCodeExporter commented 9 years ago
No, this is not expected, it's a bug. I'm currently on holidays, will look into 
this when I'm back.

Original comment by martin.grotzke on 20 Jul 2013 at 9:37