tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: j_security_check error
Date Mon, 02 Dec 2013 09:06:02 GMT
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:
> 
> <html>
> 	<head>
> 		<title>Login Error</title>
> 		<meta http-equiv=ÓContent-TypeÓ content=Ótext/html;
> charset=UTF-8Ó>
> 	</head>
> 	<body>
> 		<h1>You failed to login correctly.  To go back to the <a
> href="login.jsp">login page</a>.</h1>
> 	</body>
> </html>
> 

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


Mime
View raw message