Re: failed FORM authentication redirects to /j_security_check
On 26/08/2010 02:14, Shaun Senecal wrote: Thanks for the response Chris. You're right. Jetty does a redirect, so on the client-side the browser sees /login.html?error=true. Since this isn't happening in Tomcat, I am unable to retrieve the query string client side. As you indicated my login page is static html and I am relying on client-side processing to interpret the query string. I ended up working around the issue by creating a loginerror.html which is identical to login.html except that I have added a hidden DIV to the loginerror.html. I can then search for the hidden DIV to determine if there was a login failure or not. Not pretty, but it works! If you're using client-side scripting, why not just set a class or id on the body for each type, instead of the hidden div? p Thanks Shaun On Wed, Aug 25, 2010 at 10:17 PM, Christopher Schultz ch...@christopherschultz.net wrote: Shaun, On 8/23/2010 4:56 AM, Shaun Senecal wrote: I'm using FORM authentication, and everything seems to be working (logins are accepted, etc), except when there was an error the URL changes in the users browser to point to j_security_check. This is expected. The contents of the redirect to j_security_check contains login.html, so the user is able to login as expected, but my error=true query string is not passed along. How are you checking? If you are forwarding to a .html page, you probably don't have any dynamic content in there, and therefore have no options for checking for things like request parameters. Is there something obvious I am doing wrong here? I got it working under Jetty as a sanity test, but I need to get it working in Tomcat too... It's possible that Jetty performs a redirect (to login.html?error=true) during a failed login and Tomcat performs a forward, which is entirely server-side. The result is that the client never sees the error=true and therefore only server-side components will be able to see it. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: failed FORM authentication redirects to /j_security_check
Currently the only content in the HTML file is a script tag, since I am using GWT for the UI. I dont think there is any way I can set a class/id on a script tag, so I went with the empty DIV and put a known id on it. You're right though, I could have reused an existing element for this purpose as well. On Thu, Aug 26, 2010 at 5:17 PM, Pid p...@pidster.com wrote: On 26/08/2010 02:14, Shaun Senecal wrote: Thanks for the response Chris. You're right. Jetty does a redirect, so on the client-side the browser sees /login.html?error=true. Since this isn't happening in Tomcat, I am unable to retrieve the query string client side. As you indicated my login page is static html and I am relying on client-side processing to interpret the query string. I ended up working around the issue by creating a loginerror.html which is identical to login.html except that I have added a hidden DIV to the loginerror.html. I can then search for the hidden DIV to determine if there was a login failure or not. Not pretty, but it works! If you're using client-side scripting, why not just set a class or id on the body for each type, instead of the hidden div? p Thanks Shaun On Wed, Aug 25, 2010 at 10:17 PM, Christopher Schultz ch...@christopherschultz.net wrote: Shaun, On 8/23/2010 4:56 AM, Shaun Senecal wrote: I'm using FORM authentication, and everything seems to be working (logins are accepted, etc), except when there was an error the URL changes in the users browser to point to j_security_check. This is expected. The contents of the redirect to j_security_check contains login.html, so the user is able to login as expected, but my error=true query string is not passed along. How are you checking? If you are forwarding to a .html page, you probably don't have any dynamic content in there, and therefore have no options for checking for things like request parameters. Is there something obvious I am doing wrong here? I got it working under Jetty as a sanity test, but I need to get it working in Tomcat too... It's possible that Jetty performs a redirect (to login.html?error=true) during a failed login and Tomcat performs a forward, which is entirely server-side. The result is that the client never sees the error=true and therefore only server-side components will be able to see it. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: failed FORM authentication redirects to /j_security_check
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shaun, On 8/23/2010 4:56 AM, Shaun Senecal wrote: I'm using FORM authentication, and everything seems to be working (logins are accepted, etc), except when there was an error the URL changes in the users browser to point to j_security_check. This is expected. The contents of the redirect to j_security_check contains login.html, so the user is able to login as expected, but my error=true query string is not passed along. How are you checking? If you are forwarding to a .html page, you probably don't have any dynamic content in there, and therefore have no options for checking for things like request parameters. Is there something obvious I am doing wrong here? I got it working under Jetty as a sanity test, but I need to get it working in Tomcat too... It's possible that Jetty performs a redirect (to login.html?error=true) during a failed login and Tomcat performs a forward, which is entirely server-side. The result is that the client never sees the error=true and therefore only server-side components will be able to see it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx1F/oACgkQ9CaO5/Lv0PBinQCfYr3S/2sEresGix7Qcd/waAow ltYAoIMMm/C9xFuMS5ixJ8jlsm1ensim =cFJK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: failed FORM authentication redirects to /j_security_check
Thanks for the response Chris. You're right. Jetty does a redirect, so on the client-side the browser sees /login.html?error=true. Since this isn't happening in Tomcat, I am unable to retrieve the query string client side. As you indicated my login page is static html and I am relying on client-side processing to interpret the query string. I ended up working around the issue by creating a loginerror.html which is identical to login.html except that I have added a hidden DIV to the loginerror.html. I can then search for the hidden DIV to determine if there was a login failure or not. Not pretty, but it works! Thanks Shaun On Wed, Aug 25, 2010 at 10:17 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shaun, On 8/23/2010 4:56 AM, Shaun Senecal wrote: I'm using FORM authentication, and everything seems to be working (logins are accepted, etc), except when there was an error the URL changes in the users browser to point to j_security_check. This is expected. The contents of the redirect to j_security_check contains login.html, so the user is able to login as expected, but my error=true query string is not passed along. How are you checking? If you are forwarding to a .html page, you probably don't have any dynamic content in there, and therefore have no options for checking for things like request parameters. Is there something obvious I am doing wrong here? I got it working under Jetty as a sanity test, but I need to get it working in Tomcat too... It's possible that Jetty performs a redirect (to login.html?error=true) during a failed login and Tomcat performs a forward, which is entirely server-side. The result is that the client never sees the error=true and therefore only server-side components will be able to see it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx1F/oACgkQ9CaO5/Lv0PBinQCfYr3S/2sEresGix7Qcd/waAow ltYAoIMMm/C9xFuMS5ixJ8jlsm1ensim =cFJK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
failed FORM authentication redirects to /j_security_check
I'm using FORM authentication, and everything seems to be working (logins are accepted, etc), except when there was an error the URL changes in the users browser to point to j_security_check. The contents of the redirect to j_security_check contains login.html, so the user is able to login as expected, but my error=true query string is not passed along. Is there something obvious I am doing wrong here? I got it working under Jetty as a sanity test, but I need to get it working in Tomcat too... Using: FF 3.6.8 Tomcat 6.0.26 web.xml: login-config auth-methodFORM/auth-method form-login-config form-login-page/login.html/form-login-page form-error-page/login.html?error=true/form-error-page /form-login-config /login-config security-constraint web-resource-collection web-resource-nameUnprotected Resources/web-resource-name url-pattern/favicon.ico/url-pattern url-pattern/login.html/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProtected Resources/web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
