Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6708F10A1E for ; Mon, 2 Dec 2013 09:06:45 +0000 (UTC) Received: (qmail 83070 invoked by uid 500); 2 Dec 2013 09:06:41 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 82706 invoked by uid 500); 2 Dec 2013 09:06:36 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 82697 invoked by uid 99); 2 Dec 2013 09:06:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Dec 2013 09:06:34 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates 212.85.38.228 as permitted sender) Received: from [212.85.38.228] (HELO tor.combios.es) (212.85.38.228) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Dec 2013 09:06:28 +0000 Received: from [192.168.245.216] (montserrat.wissensbank.com [212.85.37.175]) (Authenticated sender: andre.warnier@ice-sa.com) by tor.combios.es (Postfix) with ESMTPA id 301123C2870; Mon, 2 Dec 2013 10:06:31 +0100 (CET) Message-ID: <529C4D7A.20404@ice-sa.com> Date: Mon, 02 Dec 2013 10:06:02 +0100 From: =?windows-1252?Q?Andr=E9_Warnier?= Reply-To: Tomcat Users List User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Tomcat Users List CC: "J. Brian Hall" Subject: Re: j_security_check error References: <000b01ceeebd$65d635d0$3182a170$@me.com> <529BA499.4000101@ice-sa.com> <002101ceeedb$17dc11b0$47943510$@me.com> In-Reply-To: <002101ceeedb$17dc11b0$47943510$@me.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Hi. You posted your original question to the Tomcat Users list, and that is where you should keep posting. This way, other users later who search the list archives may find the answers they are looking for. Some further answers below. J. Brian Hall wrote: > Hey Andre, I found the problem, but don't understand it. My error page is > below. The problem is that the error page contained a link back to go back > to the login.jsp page (which seemed reasonable), but when I changed the link > to go to index.jsp (rather than login.jsp), everything now works as > expected. I can also login successfully (after the first login failure) if > I just use the back-page button in the browser. Maybe you know what is > going on here? Here's my error page: > > > > Login Error > charset=UTF-8�> > > >

You failed to login correctly. To go back to the href="login.jsp">login page.

> > > You need to think a bit, and figure out how this all works. Then you'll be able to fix it, and maybe also figure out better ways (for you) of doing what you want. There are many HTTP authentication schemes, but roughly they all follow some basic schema : 1) the browser sends a request to the server, for some resource. For the sake of the example, say this is "/index.html". 2) the server receives the request, and notices that "/index.html" is within a "protected area" which requires authentication. The server then checks if the request included some form of authentication. 3a) if the request contained a valid authentication for that protected area, the server returns the requested resource and that's it. 3b) if the request did not contain a valid authentication, the server returns "something" to the browser, to indicate that authentication is required. This "something" can be a 401 HTTP response ("Authorization required"), or - in your case - a login page. 4) Now some form of authentication has to be provided by the browser. In some cases, the browser pops up a dialog for the user to fill-in a login and password. In other cases, the browser does that itself internally, based on the network or domain login of the user. In your case, the login form is shown, the user fills it in and submits the form. 5) the server receives this new request. In some cases, it may be a request for the origina URL again ("/index.html"), just with some authentication information attached. In such a case, the server would redo items (2) and (3a) above. In the case of form-based authentication, it is a bit more complicated : the server receives this *new* request (from the login page), verifies the credentials supplied, and if they are ok, it should "remember" that the original request was for "/index.html", and forward the request back there. That's the key here : this "remembering" on the part of the server. It must be able to store somewhere that the original request was for "/index.html", and then, when receiving this totally different request from the browser (the submit of the login page), there should be something in the login request which allows the server to retrieve this previously-stored information. Obviously, in your case, it works when the user requests "/index.html" the first time, gets the login page instead, fills it in correctly, sends the completed login page, and finally receives the page "/index.html" from the server. But it doesn't work anymore if 1) the browser sends a request for "/index.html" 2) the server returns the login page "login.jsp" 3) the user fills in the (wrong) credentials and submits that form to the server 4) the server returns the error page "error.jsp" 5) a link on that page links directly to the login page again, and the user clicks it Can you guess why ? Hint : the link on the error page should direct back to the original "/index.html", not directly to the login page. Or, if you want it otherwise, then *you* must provide some way for the server to remember what was the original request that started it all, through the full login-error-new login sequence. > > > > > > > > > > -----Original Message----- > From: Andr� Warnier [mailto:aw@ice-sa.com] > Sent: Sunday, December 01, 2013 4:05 PM > To: Tomcat Users List > Subject: Re: j_security_check error > > J. Brian Hall wrote: >> I�m using Tomcat and a MySQL database that contains >> usernames/passwords/roles for form-based authentication. Logging in >> with correct username/password successfully directs to index.jsp (from >> login.jsp). Logging in with incorrect username/password successfully >> directs to error.jsp (from login.jsp). However, an unsuccessful login >> followed by attempting to login with the correct username/password >> leads to an HTTP Status 404 j_security_check error that says the >> requested resource is not available. Does anyone know what may be >> wrong? Here are the details of my configuration. >> > > To understand what is going on there, I suggest that you install a browser > plugin such as HttpFox, Live HTTP headers, or Fiddler2(for IE), and that you > have a look at which request URLs and HTTP headers are really being sent by > the browser to the server (and vice-versa), at each step. > Probably what happens is that the original URL requested by the browser is > lost somewhere when you go through the error page, and that by the time you > do the second (correct) authentication, the server does not know anymore > where to forward the (now authenticated) request to. So it ends up being > forwarded to some invalid URL, and you get back a 404 error. > > What does your "error.jsp" page really look like ? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org