You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Sreyan Chakravarty <sr...@gmail.com> on 2015/08/29 23:16:42 UTC
HTTP 400 with Form based authentication
Okay this is my first try at container based authentication using Realms in
Tomcat. And things have gone wrong. Here is my login page -:
<html>
<body>
<h2>Login</h2>
<form method="post" action="j_security_check">
User ID: <input type="text" name="j_username" />
<br />
Password: <input type="password" name="j_password" />
<br />
<input type="submit" value="Login">
</form>
</body>
</html>
As you can see its as simple as it can get.
Once I click Submit with proper user creds I am suppose to land up in the
/protected/success.jsp. (Its in a folder called "protected" which is under
the webapp folder)
The success page looks like the following-:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<title>Hello User</title>
</head>
<body>
<h3>Success</h3>
</body>
</html>
Also as simple as it can get.
My web.xml security configuration is -:
<security-constraint>
<web-resource-collection>
<web-resource-name>TECHERS</web-resource-name>
<url-pattern>/teacher/success.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>TEACHER</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/index.jsp</form-login-page>
<form-error-page>/index.jsp?error=true</form-error-page>
</form-login-config>
</login-config>
<security-role>
<role-name>TEACHER</role-name>
</security-role>
Point out any errors if you find any.
I have configured the realm in my context.xml as follows-:
<Realm className="org.apache.catalina.realm.DataSourceRealm"
localDataSource="true"
dataSourceName="jdbc/TestDB"
userTable="users" userNameCol="user_id" userCredCol="user_pass"
userRoleTable="user_roles" roleNameCol="role_name">
<CredentialHandler className =
"org.apache.catalina.realm.SecretKeyCredentialHandler"
algorithm = "PBEWITHHMACSHA384ANDAES_256"
iterations = "111111"
saltLength = "20" />
</Realm>
Now when I click on submit I get the following error page in Tomcat -:
*HTTP Status 400 - Invalid direct reference to form login page*
*message* *Invalid direct reference to form login page*
*description* *The request sent by the client was syntactically incorrect.*
Why is this happening ? Any help would be greatly appreciated.
What does the error mean ? Please check my web.xml and tell me if I am
wrong.
Regards
Sreyan Chakravarty
RE: HTTP 400 with Form based authentication
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Sreyan Chakravarty [mailto:sreyan.mailing@gmail.com]
> Subject: Re: HTTP 400 with Form based authentication
> My security constraint is as follow-:
> <login-config>
> <auth-method>FORM</auth-method>
> <form-login-config>
> <form-login-page>/index.jsp</form-login-page>
> <form-error-page>/index.jsp?error=true</form-error-page>
> </form-login-config>
> </login-config>
> This is my understanding of the whole process. Please don't tell me that I
> have to put <form-login-page> as /teacher/success.jsp. If so then where do
> I designate the login page ?
One problem is that you have designated a welcome-file as the login page, pretty much forcing an infinite loop if a client doesn't request a specific resource. You want your login page to be completely separate (e.g., login.jsp) - it should never be directly referenced by a client. The server handles the replay of the original request once the login has been satisfied.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Fwd: HTTP 400 with Form based authentication
Posted by Sreyan Chakravarty <sr...@gmail.com>.
I have found the cause of the problem. It seems that there is no null
checking in the DataSourceRealm in Tomcat. What I mean is that if a
particular user does not exist in the database and is credentials are
returned as a null string then no null checking is specified.
I would like to open this as a bug.
The easiest solution is to write a custom Realm that provides the null
checking. The only problem is that now why am I not being redirected to the
error page if I provide a valid user with a wrong password.
Please if anyone can tell me how to write a custom Realm then it would be
really appreciated.
Regards,
Sreyan Chakravarty
On Mon, Sep 7, 2015 at 10:51 PM, Sreyan Chakravarty <
sreyan.mailing@gmail.com> wrote:
> Yes but what happens when the user passes a user-id that is not present in
> the DB. Or a password that is incorrect. How would the server handle that ?
>
> If I pass an incorrect user I am getting a NPE. And if I pass an invalid
> password but a valid user a am not being redirected to the form-login-error
> page.
>
> That was my question. How do I do that ?
>
> On Mon, Sep 7, 2015 at 9:52 PM, André Warnier (tomcat) <aw...@ice-sa.com>
> wrote:
>
>> Hi.
>>
>> I have notv really followed this thread from the beginning, but maybe I
>> can contribute something here..
>>
>> On 07.09.2015 15:56, Sreyan Chakravarty wrote:
>> ..
>>
>>>
>>> Also can I webapp have different realms ? If so how do you distinguish
>>> them
>>> ? I was looking at the RealmBase source and I haven't noticed a place for
>>> realmName. If not then what is the use of the <realmName> element in
>>> web.xml ?
>>>
>>>
>> One webapp can only have one realm, but several webapps (or let's say
>> more generically several areas in "URL space" on the server) can share the
>> same realm.
>>
>> The "realm" is something that the server sends back to the browser in the
>> "401 Authorization required response". It is just a "label", which in
>> terms of AAA, identifies a certain collection of resources on the server,
>> covered by the same authentication/authorization requirements.
>> In the server configuration, you can choose yourself which resources are
>> covered by the same realm (label).
>>
>> It is easier to explain this by example, in the general context of the
>> HTTP protocol.
>> The basic way in which AAA works in a webserver is this :
>>
>> 1) the client/browser sends a request to the server, with a specific URL,
>> which resolves on the server to some resource
>> 2) the server evaluates the request, and resolves the resource to which
>> it applies (e.g. a static html page, a servlet, ..). The server then
>> checks in its configuration, if this resource is protected. If not, it
>> returns the requested resouerces to the client, and that's it.
>> 3) if the request is protected, the server checks if the request contains
>> some form of authentication. If yes, the server checks if this
>> authentication is valid, and applicable to this resource. If yes, the
>> server returns the requested resource, and that's it.
>> If not, the server returns a "forbidden" response.
>> 4) If the request did not contain an authentication, the server returns a
>> response to the client : "401 Authorization required", along with a realm
>> (the "label" applicable to this resource, as per the server configuration),
>> *and* the required authentication method (e.g. "Basic" or "Digest").
>> 5) the client sees this response, and interacts with the user to obtain
>> the required user-id/password. Once obtained, the client/browser repeats
>> the same request to the server, but this time with some additional HTTP
>> header(s) containing the requested authentication. At the same time, the
>> client/browser "remembers" this authentication, and remembers to which
>> "realm" it applies.
>>
>> Then go back to (1) above.
>>
>> If the client/browser (within the same browser session), later accesses
>> the same or another resource, and it receives from the server another 401
>> "auth required" response with a realm in it, and the browser knows that
>> *for this same realm* it already had a remembered authentication, then it
>> can send the same one again to the server, without needing to ask the user
>> again to fill-in a login dialog.
>>
>> This is a pure HTTP-level mechanism, which works independently of any
>> "session" that one may have on the server (as long as the authentication
>> method is "Basic" or "Digest").
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: HTTP 400 with Form based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sreyan,
On 9/9/15 12:49 PM, Sreyan Chakravarty wrote:
> Okay can you please guide me on how to log the bug. That would be
> great. If possible you could do it yourself also.
1. Register for Bugzilla at bz.apache.org
2. Fill-out this form:
https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%208
(You can get here from inside BZ, of course, but here's the link
just in case you need it.)
3. Take care to describe this as best as you can. Feel free to
reference this thread on the list; links to things like markmail.org
are great because readers can easily follow them to get the
context of the discussion, even if it's not fully contained in the
bug report
4. If you're up for it, propose a patch. You'll get your name into the
changelog for all eternity :)
> And as far as opinions go I really don't know. The whole process of
> Realms seem confusing to me and its overtly complicated.
Presumably you mean "overly complicated". It's actually not once you
understand the complexity of what's being implemented. The
Authenticator/Realm split exists because any combination of
authentication mechanism (HTTP Basic, HTTP Digest, FORM, TLS-CERT,
etc.) and credential-storage mechanism (e.g. JDBC database, Java
Truststore, flat-file, etc.) needs to be supported.
I've always thought that the names (authenticator and realm) were bad
and confusing (especially because HTTP Basic/Digest uses the term
"realm" to describe the general thing-to-which-you-are-authenticating).
Perhaps better names would be:
authenticator = credential soliciter
realm = credential validator
But these names are far too historic to change, now.
The good news now is that the realms support better than the least
effort possible for a security system. The best you could do a year
ago was to use a single run-through of a supported hash algorithm, and
the default was MD5. Yuck. So, the fact that you can plug-in your own
algorithms for credential mutation is a really great system. To
wire-in scrypt a year ago would have been a mess, unless you just
wanted to write your own Realm that only supported a single authenticato
r.
Anyhow, things are getting better thank to contributions from the
community. Welcome to the community :)
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV8JYgAAoJEBzwKT+lPKRYIoAP/0ibxPVquauuMJK/qf05H+iy
pUpfplwh1U0WyzhC/B1V2NV7WIxf5QzaX4ld/3EJUu7yZLujA7qRrhMVN+WsCoKw
KghKyXgaLq0kWXQMXn1Aoe/9hiG32XQA59aR3Um+i8fNBv66aoIMj7albHeVFhTG
Dzf3QJAgjU3EKB4vxf+UKomfJkbr4SBOo12NXcQ37Pb5TPgFeHX//5RJBe0xS3Uh
XD+OSYDWi0gMOJfJK5bTar0gpSumzeOu+mX7iPJ6j7QLX1z73bcwG0WTRU0KRqlO
BQjZMe7qLL4Q+G4cbN4UV1lRdO7NYQ7IStHV8r05orY6BZmglaLKTEOHaqRKw2MQ
coaMArpu9eZOz0PN8HdhPT4u6N4EpYlahDZgqrY8hQlwGjatQHGAzdWeQ0i0Mmr+
BnVZT6vozA1d0tx8OUdmyWucgVy252s5iwCa9SZiaMpjugQbEpX9tYu8EQVQREZy
1UWrKcIlOGJ5be1iPWHq1yk6MEdAMDffHvhZdgzCshtzMy/tJ+VgntSjUzsJnu16
TmnlOgcWr5B/DK/ixH6BriHr4fWMLZAhsBR/WST5zgO/4CP0eZeoAGjma5B6V3pJ
Dcw3WvSpgq6dxbHJu8UxFjX3h6bwAEpLtyFo1fH2LwIfzkLN4UEikq7Rxfmcg9K/
j2lu4amIXCn5pmxzahH7
=Ux0j
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by Sreyan Chakravarty <sr...@gmail.com>.
Okay can you please guide me on how to log the bug. That would be great. If
possible you could do it yourself also.
And as far as opinions go I really don't know. The whole process of Realms
seem confusing to me and its overtly complicated.
Thanks for testing out the issue.
On Wed, Sep 9, 2015 at 7:25 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sreyan,
>
> On 9/9/15 9:45 AM, Christopher Schultz wrote:
> > On 9/7/15 2:17 PM, Sreyan Chakravarty wrote:
> >> I have found the cause of the problem. It seems that there is no
> >> null checking in the DataSourceRealm in Tomcat. What I mean is
> >> that if a particular user does not exist in the database and is
> >> credentials are returned as a null string then no null checking
> >> is specified.
> >
> >> I would like to open this as a bug.
> >
> > https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%208
> >
> > Before you file a bug:
> >
> > 1. Make sure you test on Tomcat 8.0.26 2. Make sure you post a
> > stack trace from the NPE 3. If you can provide a simple test-case,
> > it would be helpful
> >
> >> The easiest solution is to write a custom Realm that provides
> >> the null checking. The only problem is that now why am I not
> >> being redirected to the error page if I provide a valid user with
> >> a wrong password.
> >
> > If the authenticate() method returns false, then Tomcat should
> > send the user to the form-error-page. It may not issue a redirect,
> > but instead perform a forward. Is that a problem?
> >
> >> Please if anyone can tell me how to write a custom Realm then it
> >> would be really appreciated.
> >
> > If this really is a bug, it should be fixed. I'm skeptical at this
> > point, since nobody has reported this yet. It would be a fairly big
> > bug.
>
> Confirmed by code inspection that Tomcat does not check the return
> value from DataSourceRealm.getPassword. Exactly where the bug lies is
> a matter of opinion:
>
> 1. DataSourceRealm blindly passes the stored credential to the
> CredentialHandler
> 2. MessageDigestCredentialHandler.matches() performs null-checking of
> its arguments
> 3. SecretKeyCredentialHandler.matches() does not perform such
> null-checking
>
> I think it's appropriate for the entire system to waste a little time
> performing the credential-checking algorithm when the username is
> invalid because it mitigates timing-analysis used to perform user
> enumeration. That could be done in each of the individual
> CredentialHandler classes, or it could be done in the Realm itself. I
> would argue it makes sense to do in the Realm, but the handler itself
> could implement such a mechanism, too.
>
> Opinions are welcome.
>
> Please log the bug.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV8Do2AAoJEBzwKT+lPKRYNQEP/R1W9tPPrkmRCJMpy+JT63Y1
> GcUblu/0ho1xGd0/NQerpOrePJlAL94RPTkEBCw26DjHZOZ6ehYjgXHBApCIFmze
> LIMlI/x1xe63YgYx19VTCmGv48kLJa97XuoDgHa0Uo2RrAvtG7SaoIiBbFGoI+ID
> J+Ki0ntNvRZshrp4I9GvN9o+HpX19MVmW0Sj58P5a2DpdxwavF3gFRzgpkq8Rxdy
> W+Unbpx4/klI5Gp1W/bp+5j5u8xAS0+KxtsWxzD9ujjHhCCteDqr+2xZVmv4pR3P
> NUlHIdNa6ufOAP6TPM0eQTlFiyx2zRAAJlogCJ1jdYgWe2buaFvmPmFUG8q8JCLQ
> ggdVhtYo4qT1NNr+C0JWvYpmE25IlQN462cIXbcLV43wTReVaNDeeaVWQgwZLiMa
> 3TVS9C5UNGhSVKwPJriHsOECogaswA2fgJSUmDo25zaUAPTul7tT4TsxWbvKuTMI
> QUhAwsm5kqWhv8j9SbphMkmTG2lBBJDczZlemdjHGxofO3dH6q0TtLeR/1ipy9MN
> FML+r3P3D/l08pIPFbU1d2WT32Fvk77f2+x7Zijjx7XJH0gzZT3cGL4z3VtQPfFn
> 6ulWUT6EMsW4g59NEsWyWUPwoQxdyzbXq3QTgygHslEC4vNlOmoewz3uCJLWm0Gd
> MjZcERouuPKa+PiNJBuE
> =l21+
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: HTTP 400 with Form based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sreyan,
On 9/9/15 9:45 AM, Christopher Schultz wrote:
> On 9/7/15 2:17 PM, Sreyan Chakravarty wrote:
>> I have found the cause of the problem. It seems that there is no
>> null checking in the DataSourceRealm in Tomcat. What I mean is
>> that if a particular user does not exist in the database and is
>> credentials are returned as a null string then no null checking
>> is specified.
>
>> I would like to open this as a bug.
>
> https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%208
>
> Before you file a bug:
>
> 1. Make sure you test on Tomcat 8.0.26 2. Make sure you post a
> stack trace from the NPE 3. If you can provide a simple test-case,
> it would be helpful
>
>> The easiest solution is to write a custom Realm that provides
>> the null checking. The only problem is that now why am I not
>> being redirected to the error page if I provide a valid user with
>> a wrong password.
>
> If the authenticate() method returns false, then Tomcat should
> send the user to the form-error-page. It may not issue a redirect,
> but instead perform a forward. Is that a problem?
>
>> Please if anyone can tell me how to write a custom Realm then it
>> would be really appreciated.
>
> If this really is a bug, it should be fixed. I'm skeptical at this
> point, since nobody has reported this yet. It would be a fairly big
> bug.
Confirmed by code inspection that Tomcat does not check the return
value from DataSourceRealm.getPassword. Exactly where the bug lies is
a matter of opinion:
1. DataSourceRealm blindly passes the stored credential to the
CredentialHandler
2. MessageDigestCredentialHandler.matches() performs null-checking of
its arguments
3. SecretKeyCredentialHandler.matches() does not perform such
null-checking
I think it's appropriate for the entire system to waste a little time
performing the credential-checking algorithm when the username is
invalid because it mitigates timing-analysis used to perform user
enumeration. That could be done in each of the individual
CredentialHandler classes, or it could be done in the Realm itself. I
would argue it makes sense to do in the Realm, but the handler itself
could implement such a mechanism, too.
Opinions are welcome.
Please log the bug.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV8Do2AAoJEBzwKT+lPKRYNQEP/R1W9tPPrkmRCJMpy+JT63Y1
GcUblu/0ho1xGd0/NQerpOrePJlAL94RPTkEBCw26DjHZOZ6ehYjgXHBApCIFmze
LIMlI/x1xe63YgYx19VTCmGv48kLJa97XuoDgHa0Uo2RrAvtG7SaoIiBbFGoI+ID
J+Ki0ntNvRZshrp4I9GvN9o+HpX19MVmW0Sj58P5a2DpdxwavF3gFRzgpkq8Rxdy
W+Unbpx4/klI5Gp1W/bp+5j5u8xAS0+KxtsWxzD9ujjHhCCteDqr+2xZVmv4pR3P
NUlHIdNa6ufOAP6TPM0eQTlFiyx2zRAAJlogCJ1jdYgWe2buaFvmPmFUG8q8JCLQ
ggdVhtYo4qT1NNr+C0JWvYpmE25IlQN462cIXbcLV43wTReVaNDeeaVWQgwZLiMa
3TVS9C5UNGhSVKwPJriHsOECogaswA2fgJSUmDo25zaUAPTul7tT4TsxWbvKuTMI
QUhAwsm5kqWhv8j9SbphMkmTG2lBBJDczZlemdjHGxofO3dH6q0TtLeR/1ipy9MN
FML+r3P3D/l08pIPFbU1d2WT32Fvk77f2+x7Zijjx7XJH0gzZT3cGL4z3VtQPfFn
6ulWUT6EMsW4g59NEsWyWUPwoQxdyzbXq3QTgygHslEC4vNlOmoewz3uCJLWm0Gd
MjZcERouuPKa+PiNJBuE
=l21+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sreyan,
On 9/7/15 2:17 PM, Sreyan Chakravarty wrote:
> I have found the cause of the problem. It seems that there is no
> null checking in the DataSourceRealm in Tomcat. What I mean is that
> if a particular user does not exist in the database and is
> credentials are returned as a null string then no null checking is
> specified.
>
> I would like to open this as a bug.
https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%208
Before you file a bug:
1. Make sure you test on Tomcat 8.0.26
2. Make sure you post a stack trace from the NPE
3. If you can provide a simple test-case, it would be helpful
> The easiest solution is to write a custom Realm that provides the
> null checking. The only problem is that now why am I not being
> redirected to the error page if I provide a valid user with a wrong
> password.
If the authenticate() method returns false, then Tomcat should send
the user to the form-error-page. It may not issue a redirect, but
instead perform a forward. Is that a problem?
> Please if anyone can tell me how to write a custom Realm then it
> would be really appreciated.
If this really is a bug, it should be fixed. I'm skeptical at this
point, since nobody has reported this yet. It would be a fairly big bug.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV8DgVAAoJEBzwKT+lPKRYTfwP/A1tstT6mwueYnnjIT34HSji
Tu8OasywHIVPmVQ07jC7pkvysCGtOegGyWuymAilDWNEqiBsNuUmnMMuL/jJNm1D
8GLb0V8tazbxlNWsHyQ7Gg8XPEDvuRWjzJVNpCrHDbdrwOhKz0DnejxjPyXpSGkq
b2xyS+ay7iD8VLfohmclM6LD1Kp7+MdIwtnTPag5GvkAErwRQ9XmoByTVV1cZPbC
JToYerhP1kMepfF1M9K+XSotkod1xWYvq21sz2AC7sV/0kdcwOyZ/NWYqZSSdvbt
VlwQxcLqkliV6GRD/TRWduXrk36KwbNsgLNISTqjMwgBmL5HjLV7LmegL/kfK97u
J0ijssLVs/NA5BahEzmmDN/q3PfYrc7HWYJTeutt4T9obwuLqIFOoHZHPVKHj5vr
BZxWrgBVWULWw2MRpFooE4QiMaFHsLun7U/vLsKHT4ledJwPOt65UM0ARF06nZwV
htQfMkVFzqaM51+ZyJn4WBtGSwkQM1Mk8BARl5dOcH319GERRQB3ttLqJbSfmSca
PO38R6t3u0uvRmFHQqD11WHECEDWrt7rZbohyQSAX8acQb31pytrDPy4YsDDOk/o
fLpJ3v92ZGlnr22E1epziE5/bVzUywVmPkBTymJDKotOvYApu1FjUBINfyftsK71
rc3wYFqoC35+Oy29vvek
=ocBg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by Sreyan Chakravarty <sr...@gmail.com>.
I have found the cause of the problem. It seems that there is no null
checking in the DataSourceRealm in Tomcat. What I mean is that if a
particular user does not exist in the database and is credentials are
returned as a null string then no null checking is specified.
I would like to open this as a bug.
The easiest solution is to write a custom Realm that provides the null
checking. The only problem is that now why am I not being redirected to the
error page if I provide a valid user with a wrong password.
Please if anyone can tell me how to write a custom Realm then it would be
really appreciated.
Regards,
Sreyan Chakravarty
On Mon, Sep 7, 2015 at 10:51 PM, Sreyan Chakravarty <
sreyan.mailing@gmail.com> wrote:
> Yes but what happens when the user passes a user-id that is not present in
> the DB. Or a password that is incorrect. How would the server handle that ?
>
> If I pass an incorrect user I am getting a NPE. And if I pass an invalid
> password but a valid user a am not being redirected to the form-login-error
> page.
>
> That was my question. How do I do that ?
>
> On Mon, Sep 7, 2015 at 9:52 PM, André Warnier (tomcat) <aw...@ice-sa.com>
> wrote:
>
>> Hi.
>>
>> I have notv really followed this thread from the beginning, but maybe I
>> can contribute something here..
>>
>> On 07.09.2015 15:56, Sreyan Chakravarty wrote:
>> ..
>>
>>>
>>> Also can I webapp have different realms ? If so how do you distinguish
>>> them
>>> ? I was looking at the RealmBase source and I haven't noticed a place for
>>> realmName. If not then what is the use of the <realmName> element in
>>> web.xml ?
>>>
>>>
>> One webapp can only have one realm, but several webapps (or let's say
>> more generically several areas in "URL space" on the server) can share the
>> same realm.
>>
>> The "realm" is something that the server sends back to the browser in the
>> "401 Authorization required response". It is just a "label", which in
>> terms of AAA, identifies a certain collection of resources on the server,
>> covered by the same authentication/authorization requirements.
>> In the server configuration, you can choose yourself which resources are
>> covered by the same realm (label).
>>
>> It is easier to explain this by example, in the general context of the
>> HTTP protocol.
>> The basic way in which AAA works in a webserver is this :
>>
>> 1) the client/browser sends a request to the server, with a specific URL,
>> which resolves on the server to some resource
>> 2) the server evaluates the request, and resolves the resource to which
>> it applies (e.g. a static html page, a servlet, ..). The server then
>> checks in its configuration, if this resource is protected. If not, it
>> returns the requested resouerces to the client, and that's it.
>> 3) if the request is protected, the server checks if the request contains
>> some form of authentication. If yes, the server checks if this
>> authentication is valid, and applicable to this resource. If yes, the
>> server returns the requested resource, and that's it.
>> If not, the server returns a "forbidden" response.
>> 4) If the request did not contain an authentication, the server returns a
>> response to the client : "401 Authorization required", along with a realm
>> (the "label" applicable to this resource, as per the server configuration),
>> *and* the required authentication method (e.g. "Basic" or "Digest").
>> 5) the client sees this response, and interacts with the user to obtain
>> the required user-id/password. Once obtained, the client/browser repeats
>> the same request to the server, but this time with some additional HTTP
>> header(s) containing the requested authentication. At the same time, the
>> client/browser "remembers" this authentication, and remembers to which
>> "realm" it applies.
>>
>> Then go back to (1) above.
>>
>> If the client/browser (within the same browser session), later accesses
>> the same or another resource, and it receives from the server another 401
>> "auth required" response with a realm in it, and the browser knows that
>> *for this same realm* it already had a remembered authentication, then it
>> can send the same one again to the server, without needing to ask the user
>> again to fill-in a login dialog.
>>
>> This is a pure HTTP-level mechanism, which works independently of any
>> "session" that one may have on the server (as long as the authentication
>> method is "Basic" or "Digest").
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: HTTP 400 with Form based authentication
Posted by Sreyan Chakravarty <sr...@gmail.com>.
Yes but what happens when the user passes a user-id that is not present in
the DB. Or a password that is incorrect. How would the server handle that ?
If I pass an incorrect user I am getting a NPE. And if I pass an invalid
password but a valid user a am not being redirected to the form-login-error
page.
That was my question. How do I do that ?
On Mon, Sep 7, 2015 at 9:52 PM, André Warnier (tomcat) <aw...@ice-sa.com>
wrote:
> Hi.
>
> I have notv really followed this thread from the beginning, but maybe I
> can contribute something here..
>
> On 07.09.2015 15:56, Sreyan Chakravarty wrote:
> ..
>
>>
>> Also can I webapp have different realms ? If so how do you distinguish
>> them
>> ? I was looking at the RealmBase source and I haven't noticed a place for
>> realmName. If not then what is the use of the <realmName> element in
>> web.xml ?
>>
>>
> One webapp can only have one realm, but several webapps (or let's say more
> generically several areas in "URL space" on the server) can share the same
> realm.
>
> The "realm" is something that the server sends back to the browser in the
> "401 Authorization required response". It is just a "label", which in
> terms of AAA, identifies a certain collection of resources on the server,
> covered by the same authentication/authorization requirements.
> In the server configuration, you can choose yourself which resources are
> covered by the same realm (label).
>
> It is easier to explain this by example, in the general context of the
> HTTP protocol.
> The basic way in which AAA works in a webserver is this :
>
> 1) the client/browser sends a request to the server, with a specific URL,
> which resolves on the server to some resource
> 2) the server evaluates the request, and resolves the resource to which it
> applies (e.g. a static html page, a servlet, ..). The server then checks
> in its configuration, if this resource is protected. If not, it returns
> the requested resouerces to the client, and that's it.
> 3) if the request is protected, the server checks if the request contains
> some form of authentication. If yes, the server checks if this
> authentication is valid, and applicable to this resource. If yes, the
> server returns the requested resource, and that's it.
> If not, the server returns a "forbidden" response.
> 4) If the request did not contain an authentication, the server returns a
> response to the client : "401 Authorization required", along with a realm
> (the "label" applicable to this resource, as per the server configuration),
> *and* the required authentication method (e.g. "Basic" or "Digest").
> 5) the client sees this response, and interacts with the user to obtain
> the required user-id/password. Once obtained, the client/browser repeats
> the same request to the server, but this time with some additional HTTP
> header(s) containing the requested authentication. At the same time, the
> client/browser "remembers" this authentication, and remembers to which
> "realm" it applies.
>
> Then go back to (1) above.
>
> If the client/browser (within the same browser session), later accesses
> the same or another resource, and it receives from the server another 401
> "auth required" response with a realm in it, and the browser knows that
> *for this same realm* it already had a remembered authentication, then it
> can send the same one again to the server, without needing to ask the user
> again to fill-in a login dialog.
>
> This is a pure HTTP-level mechanism, which works independently of any
> "session" that one may have on the server (as long as the authentication
> method is "Basic" or "Digest").
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: HTTP 400 with Form based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sreyan,
On 9/7/15 9:56 AM, Sreyan Chakravarty wrote:
> I did what you said. That is pointing the web browser to a
> protected resource without authentication and then logging in. It
> works perfectly IF AND ONLY IF the credentials are ABSOLUTELY
> correct. Otherwise I am getting undefined behavior an thats where I
> need your help now.
>
> First-: If I provide an invalid user-id and valid/invalid password
> I am getting the following error-:
>
> HTTP Status 500 -
>
> java.lang.NullPointerException
> org.apache.catalina.realm.DigestCredentialHandlerBase.matchesSaltItera
tionsEncoded(DigestCredentialHandlerBase.java:147)
What
>
version of Tomcat are you running? That line number is a javadoc
comment in both Tomcat 8/trunk and Tomcat 9/trunk.
> Now I thought that when invalid credentials of any kind are given
> Tomcat is supposed to take you to the <form-error-page>. Then why
> is it I am getting a 500 error. Clearly something is wrong from my
> side or else the <form-error-page> is invoked under different
> circumstances.
It's possible there is a bug in there; the CredentialHandlers are
fairly new. But I'm gong to need a test case to check it out. Can you
create a quick WAR file containing whatever is necessary to reproduce
this on an up-to-date Tomcat 7/8/trunk? I'll need a copy of your
custom credential handler as well, and any configuration from
server.xml that is necessary.
> Secondly-: If I provide a valid user-id and invalid password I am
> again not redirected to the form-error-page I am kept in
> j_security_check.
What do you mean by that? Were you expecting a formal redirect response?
> How do I show the user that is credentials are wrong?
The form-error-page should be used when credentials are invalid.
> Also can I webapp have different realms?
Yes and no. The web application can only have a single Realm, but
there is a Realm called CombinedRealm that allows you to register as
many realms with it as you want.
> If so how do you distinguish them?
- From client code, I'm not sure it's possible.
> I was looking at the RealmBase source and I haven't noticed a
> place for realmName. If not then what is the use of the <realmName>
> element in web.xml?
That's for HTTP Basic and HTTP Digest authentication: it's the "realm"
name that is displayed to the user when the username/password pop-up
is shown to them.
> The example that you have provided -:
>
> request.login(req.getParameter("username"),
> req.getParameter("password"));
>
> Which realm would it use if there were multiple realms available ?
The only realm for the web application (which may be a CombinedRealm,
in which case you won't be able to tell which realm successfully
performed the authentication).
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV8DcwAAoJEBzwKT+lPKRYWIgP/jd1st1bvPD5xojhLl/D+fdz
zVQGejG9dCIW7RHNIt8BrHi/CL+Nf2Q1bEFrnIPbCHsBMQwsCvKdCf8dR9iWf6jH
LHiX9hHakf04aFc0LEkYHUkFIU9rFNKNTggSv1OKMb4JIcBZYyTS9bB8PZsWeWJM
qCJmn0Ga9zntDUzBwpnJXT8LKxAGqV1N980crmIjXLLVcbPhNSaK/+PmMn2cnYVc
nLuFOcO2ssrCp6/AcQrrP7w0sD9duzPIesLsebbxbiyw9ME15o0OTFbJ902itzPF
oBmH48sgh6z3vYzGoQHT7uh+jl8iCKLn3AqSucC2dkCcEiIWjRC4g2vtdbPtUyiy
3diqXYiDUonIRk4Xat3wScxmriOSbcX/LCgNIHTagpcXbfGnt40QgfjKuO+dm4bV
65SK/iJjswcmvJa1J0aRXs8gmPQ9Y1UbTdDIOZ5gMfCxY6rF4HkzroW8r7+zuuqF
ZUq870vCsAJk3+VOfzS0Uv3SoKBZgTc+6tReIp/CWT7gLoCysoqeXeWvDLB82v71
bHe5s+UQNYxDSJhrLZ+Y4ic1YzwffJEbI0+1+DvSuq3SaE+WFjZiinPjIhv1R6i7
WNVp25v5cyfdC6ihRztmlrVKwEniUUjm9ocKAcZgASXPOdAXrkwJ7ybBa5Ez8DbS
gi/jxgOSZZw7ddZC0rzK
=5Uty
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
Hi.
I have notv really followed this thread from the beginning, but maybe I can contribute
something here..
On 07.09.2015 15:56, Sreyan Chakravarty wrote:
..
>
> Also can I webapp have different realms ? If so how do you distinguish them
> ? I was looking at the RealmBase source and I haven't noticed a place for
> realmName. If not then what is the use of the <realmName> element in
> web.xml ?
>
One webapp can only have one realm, but several webapps (or let's say more generically
several areas in "URL space" on the server) can share the same realm.
The "realm" is something that the server sends back to the browser in the "401
Authorization required response". It is just a "label", which in terms of AAA, identifies
a certain collection of resources on the server, covered by the same
authentication/authorization requirements.
In the server configuration, you can choose yourself which resources are covered by the
same realm (label).
It is easier to explain this by example, in the general context of the HTTP protocol.
The basic way in which AAA works in a webserver is this :
1) the client/browser sends a request to the server, with a specific URL, which resolves
on the server to some resource
2) the server evaluates the request, and resolves the resource to which it applies (e.g. a
static html page, a servlet, ..). The server then checks in its configuration, if this
resource is protected. If not, it returns the requested resouerces to the client, and
that's it.
3) if the request is protected, the server checks if the request contains some form of
authentication. If yes, the server checks if this authentication is valid, and applicable
to this resource. If yes, the server returns the requested resource, and that's it.
If not, the server returns a "forbidden" response.
4) If the request did not contain an authentication, the server returns a response to the
client : "401 Authorization required", along with a realm (the "label" applicable to this
resource, as per the server configuration), *and* the required authentication method (e.g.
"Basic" or "Digest").
5) the client sees this response, and interacts with the user to obtain the required
user-id/password. Once obtained, the client/browser repeats the same request to the
server, but this time with some additional HTTP header(s) containing the requested
authentication. At the same time, the client/browser "remembers" this authentication, and
remembers to which "realm" it applies.
Then go back to (1) above.
If the client/browser (within the same browser session), later accesses the same or
another resource, and it receives from the server another 401 "auth required" response
with a realm in it, and the browser knows that *for this same realm* it already had a
remembered authentication, then it can send the same one again to the server, without
needing to ask the user again to fill-in a login dialog.
This is a pure HTTP-level mechanism, which works independently of any "session" that one
may have on the server (as long as the authentication method is "Basic" or "Digest").
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by Sreyan Chakravarty <sr...@gmail.com>.
I did what you said. That is pointing the web browser to a protected
resource without authentication and then logging in. It works perfectly IF
AND ONLY IF the credentials are ABSOLUTELY correct. Otherwise I am getting
undefined behavior an thats where I need your help now.
First-: If I provide an invalid user-id and valid/invalid password I am
getting the following error-:
HTTP Status 500 -
java.lang.NullPointerException
org.apache.catalina.realm.DigestCredentialHandlerBase.matchesSaltIterationsEncoded(DigestCredentialHandlerBase.java:147)
org.apache.catalina.realm.SecretKeyCredentialHandler.matches(SecretKeyCredentialHandler.java:73)
org.apache.catalina.realm.DataSourceRealm.authenticate(DataSourceRealm.java:297)
org.apache.catalina.realm.DataSourceRealm.authenticate(DataSourceRealm.java:267)
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:272)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:452)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:537)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1085)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1556)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1513)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Thread.java:745)
Now I thought that when invalid credentials of any kind are given Tomcat is
supposed to take you to the <form-error-page>. Then why is it I am getting
a 500 error. Clearly something is wrong from my side or else the
<form-error-page>
is invoked under different circumstances.
Secondly-: If I provide a valid user-id and invalid password I am again not
redirected to the form-error-page I am kept in j_security_check. How do I
show the user that is credentials are wrong ?
Also can I webapp have different realms ? If so how do you distinguish them
? I was looking at the RealmBase source and I haven't noticed a place for
realmName. If not then what is the use of the <realmName> element in
web.xml ?
The example that you have provided -:
request.login(req.getParameter("username"),
req.getParameter("password"));
Which realm would it use if there were multiple realms available ?
Thanks for your patience in helping me Christopher.
Regards
Sreyan Chakravarty
On Tue, Sep 1, 2015 at 9:44 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sreyan,
>
> On 8/31/15 3:20 PM, Sreyan Chakravarty wrote:
> > Ok I found FormAuthenticator and landingPage attribute in it in the
> > source.
>
> You shouldn't need to look at the source.
>
> > But how do I use that in my application ? What do I do ?
>
> You configure the FormAuthenticationValve in your application's
> META-INF/context.xml file.
> http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Introduction
>
> The intro says you can configure any Valve in any of the following
> "Catalina container[s] (Engine, Host, or Context)." Just make it a new
> child of the <Context> element you should already have.
>
> > Any documentation for this ?
>
> Just what you have already read:
>
> <Context>
> <Valve className="name.of.valve.class"
> ... other configuration attributes ...
> />
> </Context>
>
> - -chris
>
> > On Tue, Sep 1, 2015 at 12:46 AM, Sreyan Chakravarty <
> > sreyan.mailing@gmail.com> wrote:
> >
> >> Well Christopher thanks for that eye opener. I didn't know that
> >> the specs were so inconsistent.
> >>
> >> Okay now regarding your comment-:
> >>
> >> "Servlet 3.0 added the HttpServletRequest.login() method would
> >> improved the situation greatly: you can implement your own login
> >> handler that plugs-into the authentication services of the
> >> container. It's just that the container doesn't handle any
> >> redirection to a login page (none is required) or credential
> >> capturing (easily done with a servlet)."
> >>
> >> How do you implement your own login handler and how do you plug
> >> that into Tomcat Auth services. Can you provide some info as to
> >> how I would do that ?
> >>
> >> And what is the extension to FORM Authenticator that Mark is
> >> talking about ?
> >>
> >> Also correct me if I am wrong, then the page that I use to login
> >> and the page that will contain j_security_check as an action must
> >> be two different pages.
> >>
> >> Also can I have two <login-config> elements in my web.xml ?
> >>
> >> On Mon, Aug 31, 2015 at 11:19 PM, Christopher Schultz <
> >> chris@christopherschultz.net> wrote:
> >>
> > Sreyan,
> >
> > On 8/31/15 1:39 PM, Sreyan Chakravarty wrote:
> >>>>> First of all I did read the Servlet Spec, it provided no
> >>>>> hint as to what I was doing wrong.
> >>>>>
> >>>>> So you are saying that I can't have a login form on the
> >>>>> page when the welcome page ? Why not ? Tons of site have
> >>>>> just that, like Twitter and Facebook. It seems weird why I
> >>>>> can't have it on my welcome page.
> >
> > Oh, you can do it, but you'll have to implement it yourself. Go
> > re-read the spec's section on how FORM authentication works. Note
> > that you are required to attempt to access a protected page before
> > being asked for authentication. I think it's a big hole in the spec
> > that should be filled, but anything Tomcat would do for you here
> > is, by definition, out-of-spec.
> >
> >>>>> And wait a minute. You are telling me that I have to first
> >>>>> point my web browser to /teacher/success.jsp and then when
> >>>>> I get the login page and login ?
> >
> > Yes.
> >
> >>>>> What can't I do the following-:
> >>>>>
> >>>>> First login from the login page and then go to
> >>>>> success.jsp?
> >
> > You sure can do that, but you can't use j_security_check as
> > yourPOST target. Instead, you have to write your own Servlet and
> > then (probably) call HttpServletRequest.login() from there, then
> > redirect the user to wherever you want them to go.
> >
> >>>>> Why do I have to first hit an auth error and then be
> >>>>> redirected back to login and then provide my user/pass
> >>>>> combo ?
> >
> > This is spec-defined behavior.
> >
> >>>>> So how do you code a login module ? Where I can login first
> >>>>> and then go to my resources ?
> >
> > What's a "login module"?
> >
> >>>>> This is indeed weird.
> >
> > It's a (giant, gaping) hole in the spec. Inconvenient, maybe. But
> > certainly not weird.
> >
> > Servlet 3.0 added the HttpServletRequest.login() method would
> > improved the situation greatly: you can implement your own login
> > handler that plugs-into the authentication services of the
> > container. It's just that the container doesn't handle any
> > redirection to a login page (none is required) or credential
> > capturing (easily done with a servlet).
> >
> > Really the only thing the servlet spec is missing is a setting in
> > <form-login> like <default-landing-page> or something like that,
> > so that if you try to login with j_security_check and you hadn't
> > already requested a protected resource, the container knows where
> > to send the user after authentication.
> >
> > -chris
> >>>
> >>> --------------------------------------------------------------------
> - -
> >>>
> >>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>
> >>>
> >>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV5c7LAAoJEBzwKT+lPKRYBkoP/RCzs3LjRGedna+GYX1KP7nD
> eeQseNjfe+nCC9w0hkUUklTxA7ikC92IJHxfoBNKOwjEzIBBrT1stoR1rwUAjMRp
> dBZ44EjxybDYHQgCJkLdFQXD0q3+SH4kYDguVNJNSl8vpYQ4ehTj7RDV0mlf7USz
> rLgwZ/4WZh/QU3VMf0R+xYbnz/nkbzAMiIn9ZGMa/R26tBWT1AEWbP7ntGw6qFgM
> i4FhElMb21cJYSrU6eAvTvJpJR97ziBnCLauZxBmfiioIH09iutXqrG8F/q3Ou42
> 9mBEPCqYTwj6ZznSX5nXbujllNTdtSJNfZUfuCLRgV+fzEhfYuDflnptIPDMjg/9
> HH1WCozm/sAvLh/z3Gn0uPpALhTzT0b4rHlH8rksJqZlQ/0vaEO14HQgvhe3/DbM
> DCo8MCU/QTq7CILd1eB1l4kfiIDkc4XFUxYkdnUWCwvLelWWRMUB3Zd5B9gYefdK
> iJ3ivzwwd5GJURb/S+KAucJCHaN6gIkLE3z3IIb/Q/LUsc1AT+8mdwCMeExsr7N2
> 5wg9B64SviroD3Ab86lL/8MVan525YGuM/h4xUjn5v90Nv7Bm+9jZBCA3M1/FzbW
> XrrH5lFs/E4LJKOCGbM8sLNUbsYoa6nN1WI3XHovJkgnKnaVhA24MmEE0dN1GvDf
> P3TvUkHPDy2+b6MfN/x9
> =FCGh
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: HTTP 400 with Form based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sreyan,
On 8/31/15 3:20 PM, Sreyan Chakravarty wrote:
> Ok I found FormAuthenticator and landingPage attribute in it in the
> source.
You shouldn't need to look at the source.
> But how do I use that in my application ? What do I do ?
You configure the FormAuthenticationValve in your application's
META-INF/context.xml file.
http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Introduction
The intro says you can configure any Valve in any of the following
"Catalina container[s] (Engine, Host, or Context)." Just make it a new
child of the <Context> element you should already have.
> Any documentation for this ?
Just what you have already read:
<Context>
<Valve className="name.of.valve.class"
... other configuration attributes ...
/>
</Context>
- -chris
> On Tue, Sep 1, 2015 at 12:46 AM, Sreyan Chakravarty <
> sreyan.mailing@gmail.com> wrote:
>
>> Well Christopher thanks for that eye opener. I didn't know that
>> the specs were so inconsistent.
>>
>> Okay now regarding your comment-:
>>
>> "Servlet 3.0 added the HttpServletRequest.login() method would
>> improved the situation greatly: you can implement your own login
>> handler that plugs-into the authentication services of the
>> container. It's just that the container doesn't handle any
>> redirection to a login page (none is required) or credential
>> capturing (easily done with a servlet)."
>>
>> How do you implement your own login handler and how do you plug
>> that into Tomcat Auth services. Can you provide some info as to
>> how I would do that ?
>>
>> And what is the extension to FORM Authenticator that Mark is
>> talking about ?
>>
>> Also correct me if I am wrong, then the page that I use to login
>> and the page that will contain j_security_check as an action must
>> be two different pages.
>>
>> Also can I have two <login-config> elements in my web.xml ?
>>
>> On Mon, Aug 31, 2015 at 11:19 PM, Christopher Schultz <
>> chris@christopherschultz.net> wrote:
>>
> Sreyan,
>
> On 8/31/15 1:39 PM, Sreyan Chakravarty wrote:
>>>>> First of all I did read the Servlet Spec, it provided no
>>>>> hint as to what I was doing wrong.
>>>>>
>>>>> So you are saying that I can't have a login form on the
>>>>> page when the welcome page ? Why not ? Tons of site have
>>>>> just that, like Twitter and Facebook. It seems weird why I
>>>>> can't have it on my welcome page.
>
> Oh, you can do it, but you'll have to implement it yourself. Go
> re-read the spec's section on how FORM authentication works. Note
> that you are required to attempt to access a protected page before
> being asked for authentication. I think it's a big hole in the spec
> that should be filled, but anything Tomcat would do for you here
> is, by definition, out-of-spec.
>
>>>>> And wait a minute. You are telling me that I have to first
>>>>> point my web browser to /teacher/success.jsp and then when
>>>>> I get the login page and login ?
>
> Yes.
>
>>>>> What can't I do the following-:
>>>>>
>>>>> First login from the login page and then go to
>>>>> success.jsp?
>
> You sure can do that, but you can't use j_security_check as
> yourPOST target. Instead, you have to write your own Servlet and
> then (probably) call HttpServletRequest.login() from there, then
> redirect the user to wherever you want them to go.
>
>>>>> Why do I have to first hit an auth error and then be
>>>>> redirected back to login and then provide my user/pass
>>>>> combo ?
>
> This is spec-defined behavior.
>
>>>>> So how do you code a login module ? Where I can login first
>>>>> and then go to my resources ?
>
> What's a "login module"?
>
>>>>> This is indeed weird.
>
> It's a (giant, gaping) hole in the spec. Inconvenient, maybe. But
> certainly not weird.
>
> Servlet 3.0 added the HttpServletRequest.login() method would
> improved the situation greatly: you can implement your own login
> handler that plugs-into the authentication services of the
> container. It's just that the container doesn't handle any
> redirection to a login page (none is required) or credential
> capturing (easily done with a servlet).
>
> Really the only thing the servlet spec is missing is a setting in
> <form-login> like <default-landing-page> or something like that,
> so that if you try to login with j_security_check and you hadn't
> already requested a protected resource, the container knows where
> to send the user after authentication.
>
> -chris
>>>
>>> --------------------------------------------------------------------
- -
>>>
>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV5c7LAAoJEBzwKT+lPKRYBkoP/RCzs3LjRGedna+GYX1KP7nD
eeQseNjfe+nCC9w0hkUUklTxA7ikC92IJHxfoBNKOwjEzIBBrT1stoR1rwUAjMRp
dBZ44EjxybDYHQgCJkLdFQXD0q3+SH4kYDguVNJNSl8vpYQ4ehTj7RDV0mlf7USz
rLgwZ/4WZh/QU3VMf0R+xYbnz/nkbzAMiIn9ZGMa/R26tBWT1AEWbP7ntGw6qFgM
i4FhElMb21cJYSrU6eAvTvJpJR97ziBnCLauZxBmfiioIH09iutXqrG8F/q3Ou42
9mBEPCqYTwj6ZznSX5nXbujllNTdtSJNfZUfuCLRgV+fzEhfYuDflnptIPDMjg/9
HH1WCozm/sAvLh/z3Gn0uPpALhTzT0b4rHlH8rksJqZlQ/0vaEO14HQgvhe3/DbM
DCo8MCU/QTq7CILd1eB1l4kfiIDkc4XFUxYkdnUWCwvLelWWRMUB3Zd5B9gYefdK
iJ3ivzwwd5GJURb/S+KAucJCHaN6gIkLE3z3IIb/Q/LUsc1AT+8mdwCMeExsr7N2
5wg9B64SviroD3Ab86lL/8MVan525YGuM/h4xUjn5v90Nv7Bm+9jZBCA3M1/FzbW
XrrH5lFs/E4LJKOCGbM8sLNUbsYoa6nN1WI3XHovJkgnKnaVhA24MmEE0dN1GvDf
P3TvUkHPDy2+b6MfN/x9
=FCGh
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sreyan,
On 8/31/15 3:16 PM, Sreyan Chakravarty wrote:
> Well Christopher thanks for that eye opener. I didn't know that the
> specs were so inconsistent.
They aren't inconsistent... it's just that they don't cover a popular
use case. Remember that container-managed authentication has to cover
types of authentication other than "FORM".
The client can't, for instance, force HTTP Basic credentials into a
server without knowing what the server's "realm" is for HTTP Basic.
The server won't ask for authentication unless it's necessary, and
authentication isn't necessary unless the user tries to access a
protected resource.
The same is true for SSL client certificates. When you consider all
the types of authentication that the servlet spec covers, it makes
more sense why the authentication is done the way it is. (It doesn't
make it any less irritating, though.)
> Okay now regarding your comment-:
>
> "Servlet 3.0 added the HttpServletRequest.login() method would
> improved the situation greatly: you can implement your own login
> handler that plugs-into the authentication services of the
> container. It's just that the container doesn't handle any
> redirection to a login page (none is required) or credential
> capturing (easily done with a servlet)."
(Note that the word "would" should have been "which has" above.)
> How do you implement your own login handler and how do you plug
> that into Tomcat Auth services.
>
> Can you provide some info as to how I would do that ?
You write your own servlet and point your "main" login at it:
<form action="/path/to/my/login/servlet">
<input type="text" name="username" />
<input type="password" name="password" />
<input type="submit" />
</form>
public class MyLoginServlet extends HttpServlet {
public void doPost(HttpServletRequest req, HttpServletResponse rsp) {
request.login(req.getParameter("username"),
req.getParameter("password"));
}
}
It's up to you to decide what else should happen after authentication
succeeds. This hooks-into the container's authentication system by
using whatever Realm has been defined to actually do the
authentication (e.g. DataSourceRealm) and will also use the
CredentialHandlers we've been discussing.
> And what is the extension to FORM Authenticator that Mark is
> talking about ?
Check out the documentation for the FORM Authenticator and you'll see
that you don't actually need to write your own servlet like the above
if all you want to do is allow drive-by logins and always forward to
the same URI:
http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Form_Authentic
ator_Valve
Unfortunately, that feature is buried in the configuration reference
for the FormAuthenticatorValve and not somewhere more easily
accessible like under "Realms and AAA" for example.
> Also correct me if I am wrong, then the page that I use to login
> and the page that will contain j_security_check as an action must
> be two different pages.
If you use the form/servlet I outlined above, then yes: your "main"
login page should be separate from the one you use for Tomcat's
automated authentication. Of course, you can page a single
parameterized page or a complex series of JSPs that include each other
to avoid duplication, or you can just make two pages.
If you use Mark's technique to configure the FormAuthenticationValve,
then you can use a single form for everything. I would highly
recommend simply using the FormAuthenticationValve configuration
because you have to do a whole lot less work.
> Also can I have two <login-config> elements in my web.xml ?
Nope. How would the container know when to pick one over the other?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV5c4wAAoJEBzwKT+lPKRYX08QAJKuEE9N2ifMuZp2uOtXNkDz
VNPZBnZonXfqI/MKjYlhn2ox9IHpTOZ6sYVGaMgBKYV4ILHPN4kOvSHi3ud/azDh
igSpSEYJ52vcK1EAoYgr1f56hyUjSTZhxbQlNuf0cIfyF/nNLUB/fz9x5VMDUPEY
s8KH3UZ62OR5UI6rcwWE/QfnyneHyWoDqp0s831DxMRkH90XdzGGHn4xaICUK68f
fdZPJmQslgm6rdyh/MuVA/NVS9IGADEF4hlD7TbyGhl8sOupSv51pjivl594hjhX
znYT/wE8iO+sNft2oPb9A5LUWDS2le9dfA4S0zrA9TVsWFQvnUOs3dNkgEIW7aYO
fba0F9wUqRY0hUfoqiQ+mvCaBQP8a6P2YDy9P9PnShwxOTo6grd8UAXGYvsxyaae
D/TZkak1mSkYT/7HQ14OwXhDjtK00GflQ3I+p/qYAO7xCxeWJvfcxWp7y19Zc+8B
Zc3Vz+NQhneJHeltp6V0xK2xfamGrFCrpcuDMIpyu3Szi/15shpJaPTYWAuam8Pk
4Ld8OC0MCB5C7mgu58bJuKm54cr2GJgBlcgsfG6XwUkn3oeCAZDFBuqNoR7YMyQ6
e8gzUYvAwpb1IsNO1mELJIUKY8N+NDCdNnvjQ05X3rUsBhPS0tg6b3USdvs+TDIG
vb/DhPr4hguee6nFoX7Y
=iT9j
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by Sreyan Chakravarty <sr...@gmail.com>.
Ok I found FormAuthenticator and landingPage attribute in it in the source.
But how do I use that in my application ? What do I do ?
Any documentation for this ?
On Tue, Sep 1, 2015 at 12:46 AM, Sreyan Chakravarty <
sreyan.mailing@gmail.com> wrote:
> Well Christopher thanks for that eye opener. I didn't know that the specs
> were so inconsistent.
>
> Okay now regarding your comment-:
>
> "Servlet 3.0 added the HttpServletRequest.login() method would improved
> the situation greatly: you can implement your own login handler that
> plugs-into the authentication services of the container. It's just
> that the container doesn't handle any redirection to a login page
> (none is required) or credential capturing (easily done with a servlet)."
>
> How do you implement your own login handler and how do you plug that into
> Tomcat Auth services. Can you provide some info as to how I would do that ?
>
> And what is the extension to FORM Authenticator that Mark is talking about
> ?
>
> Also correct me if I am wrong, then the page that I use to login and the
> page that will contain j_security_check as an action must be two different
> pages.
>
> Also can I have two <login-config> elements in my web.xml ?
>
> On Mon, Aug 31, 2015 at 11:19 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Sreyan,
>>
>> On 8/31/15 1:39 PM, Sreyan Chakravarty wrote:
>> > First of all I did read the Servlet Spec, it provided no hint as to
>> > what I was doing wrong.
>> >
>> > So you are saying that I can't have a login form on the page when
>> > the welcome page ? Why not ? Tons of site have just that, like
>> > Twitter and Facebook. It seems weird why I can't have it on my
>> > welcome page.
>>
>> Oh, you can do it, but you'll have to implement it yourself. Go
>> re-read the spec's section on how FORM authentication works. Note that
>> you are required to attempt to access a protected page before being
>> asked for authentication. I think it's a big hole in the spec that
>> should be filled, but anything Tomcat would do for you here is, by
>> definition, out-of-spec.
>>
>> > And wait a minute. You are telling me that I have to first point my
>> > web browser to /teacher/success.jsp and then when I get the login
>> > page and login ?
>>
>> Yes.
>>
>> > What can't I do the following-:
>> >
>> > First login from the login page and then go to success.jsp?
>>
>> You sure can do that, but you can't use j_security_check as yourPOST
>> target. Instead, you have to write your own Servlet and then
>> (probably) call HttpServletRequest.login() from there, then redirect
>> the user to wherever you want them to go.
>>
>> > Why do I have to first hit an auth error and then be redirected
>> > back to login and then provide my user/pass combo ?
>>
>> This is spec-defined behavior.
>>
>> > So how do you code a login module ? Where I can login first and
>> > then go to my resources ?
>>
>> What's a "login module"?
>>
>> > This is indeed weird.
>>
>> It's a (giant, gaping) hole in the spec. Inconvenient, maybe. But
>> certainly not weird.
>>
>> Servlet 3.0 added the HttpServletRequest.login() method would improved
>> the situation greatly: you can implement your own login handler that
>> plugs-into the authentication services of the container. It's just
>> that the container doesn't handle any redirection to a login page
>> (none is required) or credential capturing (easily done with a servlet).
>>
>> Really the only thing the servlet spec is missing is a setting in
>> <form-login> like <default-landing-page> or something like that, so
>> that if you try to login with j_security_check and you hadn't already
>> requested a protected resource, the container knows where to send the
>> user after authentication.
>>
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQIcBAEBCAAGBQJV5JOeAAoJEBzwKT+lPKRYwSgQAJAARzjHnDqMXY9QexbBpyrZ
>> DSZSxqCRljdHtnEEuBjlLfT8FRUATIU3g0rHZ99SQSXhgYojfvCZ7WalO3izxu6o
>> NvmbptcCo/rASOvVqtVYpTu1ONhSgGu/v0fZ7maZksMlb0yXUSHpM5EeUucU92NK
>> AEnZElXlV+6yf2arN9R5L80lZHxioF5tUkS1RoqYsBr3+1KuS1DzfVVO2NKzPLiK
>> L03QVRCGdDtln66m6lrbPNjgzhMK3HvqMiHAPuED5sTMAha8uk5HTZfM855ojuY4
>> x8whD7X/6JjTemLue1pzd1CfSGx+EDxrgxgOscFyA4PK0zy8vQWnsnb5MAjKtvdw
>> +8oHg445RDoYG6BYJ1ZXbTmft9APN37PCeyxzKcGEv0sEzj4q5XRIr8oNiXi74mf
>> 8CQ1QsFv6tlMHysLk/3Tj53AwscZ59xnovjH5lUJqGDi8v6uIojhCOAwzG5UBQF0
>> JHq6Nd295a3Qp9XTj0WCyDJ6gHyDlzNMivI/dJzkaHOSeyML/hSfYSKKEL1vaOOO
>> OECSLWqCWiXztOCNCbHvT5YINSmzqV1hdqoPEdSQyLlVbeHrK6vrZVAFpoqoxOOp
>> ZaliFI6FTZkyiz3KE6pUjMR6PSiiTwK5GW/xhiI2ky5tcBgv4y8ZHXDiTOmchFt4
>> M5Rksa1BFd+fVbV0tn6m
>> =u/HP
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: HTTP 400 with Form based authentication
Posted by Sreyan Chakravarty <sr...@gmail.com>.
Well Christopher thanks for that eye opener. I didn't know that the specs
were so inconsistent.
Okay now regarding your comment-:
"Servlet 3.0 added the HttpServletRequest.login() method would improved
the situation greatly: you can implement your own login handler that
plugs-into the authentication services of the container. It's just
that the container doesn't handle any redirection to a login page
(none is required) or credential capturing (easily done with a servlet)."
How do you implement your own login handler and how do you plug that into
Tomcat Auth services. Can you provide some info as to how I would do that ?
And what is the extension to FORM Authenticator that Mark is talking about ?
Also correct me if I am wrong, then the page that I use to login and the
page that will contain j_security_check as an action must be two different
pages.
Also can I have two <login-config> elements in my web.xml ?
On Mon, Aug 31, 2015 at 11:19 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sreyan,
>
> On 8/31/15 1:39 PM, Sreyan Chakravarty wrote:
> > First of all I did read the Servlet Spec, it provided no hint as to
> > what I was doing wrong.
> >
> > So you are saying that I can't have a login form on the page when
> > the welcome page ? Why not ? Tons of site have just that, like
> > Twitter and Facebook. It seems weird why I can't have it on my
> > welcome page.
>
> Oh, you can do it, but you'll have to implement it yourself. Go
> re-read the spec's section on how FORM authentication works. Note that
> you are required to attempt to access a protected page before being
> asked for authentication. I think it's a big hole in the spec that
> should be filled, but anything Tomcat would do for you here is, by
> definition, out-of-spec.
>
> > And wait a minute. You are telling me that I have to first point my
> > web browser to /teacher/success.jsp and then when I get the login
> > page and login ?
>
> Yes.
>
> > What can't I do the following-:
> >
> > First login from the login page and then go to success.jsp?
>
> You sure can do that, but you can't use j_security_check as yourPOST
> target. Instead, you have to write your own Servlet and then
> (probably) call HttpServletRequest.login() from there, then redirect
> the user to wherever you want them to go.
>
> > Why do I have to first hit an auth error and then be redirected
> > back to login and then provide my user/pass combo ?
>
> This is spec-defined behavior.
>
> > So how do you code a login module ? Where I can login first and
> > then go to my resources ?
>
> What's a "login module"?
>
> > This is indeed weird.
>
> It's a (giant, gaping) hole in the spec. Inconvenient, maybe. But
> certainly not weird.
>
> Servlet 3.0 added the HttpServletRequest.login() method would improved
> the situation greatly: you can implement your own login handler that
> plugs-into the authentication services of the container. It's just
> that the container doesn't handle any redirection to a login page
> (none is required) or credential capturing (easily done with a servlet).
>
> Really the only thing the servlet spec is missing is a setting in
> <form-login> like <default-landing-page> or something like that, so
> that if you try to login with j_security_check and you hadn't already
> requested a protected resource, the container knows where to send the
> user after authentication.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV5JOeAAoJEBzwKT+lPKRYwSgQAJAARzjHnDqMXY9QexbBpyrZ
> DSZSxqCRljdHtnEEuBjlLfT8FRUATIU3g0rHZ99SQSXhgYojfvCZ7WalO3izxu6o
> NvmbptcCo/rASOvVqtVYpTu1ONhSgGu/v0fZ7maZksMlb0yXUSHpM5EeUucU92NK
> AEnZElXlV+6yf2arN9R5L80lZHxioF5tUkS1RoqYsBr3+1KuS1DzfVVO2NKzPLiK
> L03QVRCGdDtln66m6lrbPNjgzhMK3HvqMiHAPuED5sTMAha8uk5HTZfM855ojuY4
> x8whD7X/6JjTemLue1pzd1CfSGx+EDxrgxgOscFyA4PK0zy8vQWnsnb5MAjKtvdw
> +8oHg445RDoYG6BYJ1ZXbTmft9APN37PCeyxzKcGEv0sEzj4q5XRIr8oNiXi74mf
> 8CQ1QsFv6tlMHysLk/3Tj53AwscZ59xnovjH5lUJqGDi8v6uIojhCOAwzG5UBQF0
> JHq6Nd295a3Qp9XTj0WCyDJ6gHyDlzNMivI/dJzkaHOSeyML/hSfYSKKEL1vaOOO
> OECSLWqCWiXztOCNCbHvT5YINSmzqV1hdqoPEdSQyLlVbeHrK6vrZVAFpoqoxOOp
> ZaliFI6FTZkyiz3KE6pUjMR6PSiiTwK5GW/xhiI2ky5tcBgv4y8ZHXDiTOmchFt4
> M5Rksa1BFd+fVbV0tn6m
> =u/HP
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: HTTP 400 with Form based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 8/31/15 2:01 PM, Mark Thomas wrote:
> On 31/08/2015 18:49, Christopher Schultz wrote:
>
>> Really the only thing the servlet spec is missing is a setting
>> in <form-login> like <default-landing-page> or something like
>> that, so that if you try to login with j_security_check and you
>> hadn't already requested a protected resource, the container
>> knows where to send the user after authentication.
>
> And that is a feature Tomcat provides as an extension to the FORM
> authenticator.
Yeah... I thought I remembered doing that but I couldn't find the
reference to it and I'm fairly busy today :)
Thanks for the reference.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV5Jl9AAoJEBzwKT+lPKRYmQEP/2d0tmw48jatl/Q3HoXhSvCn
W13Rr4/7t0GlgxtHfHKzv68XA8EnzvcpWg/aYnN+xSUZ4dbNcdVOjYU6SpR/bDRI
Cg0zLnr/KccTKpd6OuSxzczWSc6OEVviIPthFATb9R6ooPJ/sS3AR5Be6wKjbeCD
yAQZCQXMfBHDd39Zi6FWmWX4D0PJ8xht9Wq7bwrTup5Wpri8VRkQtQWoCzjcWCK5
hxweWqyFy0d0FCUFm+BK1DtoO3OlLpnDLTc1qRENlfrQ+x1aMzb0n77fFI5lKrPw
y4jugfuFgFN/Q3DLAdRgysii6hWLT2Ymt6bIxDYX9QzKNmf12KtwqoeyHxVP4so7
/jUoEqnT4m8Twef6tBZ7XIBWwLJiYTEavA1nalIIa8VMniLb0pZBwfkBD7bA13Ln
fMHfDWEkJ4mADn9cCAzKRXYEAXlOheDpErEtXmLb+RZA/2th+0hgpPo3KzDu4YRq
h7CCvC1/OBNu4WRIC1FBTQoacZHlpol/AWAecXVoHY85349L+UHcpVIrgLMQsKtP
VGJI2aM5oDAiAf2v3AXVXhwvDbuBZfbrbgmiVzviNW9seKtLnz6lAA49uo0sceAf
g6EQj/B3coUWHszmZpCh2W4iiSaEqDMntZl03a2NqwBdTa9+ShbFktOu7JfrX3bo
zuoqrRYFZi25hAE7/Xfw
=8MYf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by Mark Thomas <ma...@apache.org>.
On 31/08/2015 18:49, Christopher Schultz wrote:
> Really the only thing the servlet spec is missing is a setting in
> <form-login> like <default-landing-page> or something like that, so
> that if you try to login with j_security_check and you hadn't already
> requested a protected resource, the container knows where to send the
> user after authentication.
And that is a feature Tomcat provides as an extension to the FORM
authenticator.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sreyan,
On 8/31/15 1:39 PM, Sreyan Chakravarty wrote:
> First of all I did read the Servlet Spec, it provided no hint as to
> what I was doing wrong.
>
> So you are saying that I can't have a login form on the page when
> the welcome page ? Why not ? Tons of site have just that, like
> Twitter and Facebook. It seems weird why I can't have it on my
> welcome page.
Oh, you can do it, but you'll have to implement it yourself. Go
re-read the spec's section on how FORM authentication works. Note that
you are required to attempt to access a protected page before being
asked for authentication. I think it's a big hole in the spec that
should be filled, but anything Tomcat would do for you here is, by
definition, out-of-spec.
> And wait a minute. You are telling me that I have to first point my
> web browser to /teacher/success.jsp and then when I get the login
> page and login ?
Yes.
> What can't I do the following-:
>
> First login from the login page and then go to success.jsp?
You sure can do that, but you can't use j_security_check as yourPOST
target. Instead, you have to write your own Servlet and then
(probably) call HttpServletRequest.login() from there, then redirect
the user to wherever you want them to go.
> Why do I have to first hit an auth error and then be redirected
> back to login and then provide my user/pass combo ?
This is spec-defined behavior.
> So how do you code a login module ? Where I can login first and
> then go to my resources ?
What's a "login module"?
> This is indeed weird.
It's a (giant, gaping) hole in the spec. Inconvenient, maybe. But
certainly not weird.
Servlet 3.0 added the HttpServletRequest.login() method would improved
the situation greatly: you can implement your own login handler that
plugs-into the authentication services of the container. It's just
that the container doesn't handle any redirection to a login page
(none is required) or credential capturing (easily done with a servlet).
Really the only thing the servlet spec is missing is a setting in
<form-login> like <default-landing-page> or something like that, so
that if you try to login with j_security_check and you hadn't already
requested a protected resource, the container knows where to send the
user after authentication.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV5JOeAAoJEBzwKT+lPKRYwSgQAJAARzjHnDqMXY9QexbBpyrZ
DSZSxqCRljdHtnEEuBjlLfT8FRUATIU3g0rHZ99SQSXhgYojfvCZ7WalO3izxu6o
NvmbptcCo/rASOvVqtVYpTu1ONhSgGu/v0fZ7maZksMlb0yXUSHpM5EeUucU92NK
AEnZElXlV+6yf2arN9R5L80lZHxioF5tUkS1RoqYsBr3+1KuS1DzfVVO2NKzPLiK
L03QVRCGdDtln66m6lrbPNjgzhMK3HvqMiHAPuED5sTMAha8uk5HTZfM855ojuY4
x8whD7X/6JjTemLue1pzd1CfSGx+EDxrgxgOscFyA4PK0zy8vQWnsnb5MAjKtvdw
+8oHg445RDoYG6BYJ1ZXbTmft9APN37PCeyxzKcGEv0sEzj4q5XRIr8oNiXi74mf
8CQ1QsFv6tlMHysLk/3Tj53AwscZ59xnovjH5lUJqGDi8v6uIojhCOAwzG5UBQF0
JHq6Nd295a3Qp9XTj0WCyDJ6gHyDlzNMivI/dJzkaHOSeyML/hSfYSKKEL1vaOOO
OECSLWqCWiXztOCNCbHvT5YINSmzqV1hdqoPEdSQyLlVbeHrK6vrZVAFpoqoxOOp
ZaliFI6FTZkyiz3KE6pUjMR6PSiiTwK5GW/xhiI2ky5tcBgv4y8ZHXDiTOmchFt4
M5Rksa1BFd+fVbV0tn6m
=u/HP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by Sreyan Chakravarty <sr...@gmail.com>.
First of all I did read the Servlet Spec, it provided no hint as to what I
was doing wrong.
So you are saying that I can't have a login form on the page when the
welcome page ? Why not ? Tons of site have just that, like Twitter and
Facebook. It seems weird why I can't have it on my welcome page.
And wait a minute. You are telling me that I have to first point my web
browser to /teacher/success.jsp and then when I get the login page and
login ?
What can't I do the following-:
First login from the login page and then go to success.jsp ?
Why do I have to first hit an auth error and then be redirected back to
login and then provide my user/pass combo ?
So how do you code a login module ? Where I can login first and then go to
my resources ?
This is indeed weird.
On Mon, Aug 31, 2015 at 10:55 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sreyan,
>
> On 8/31/15 12:34 PM, Sreyan Chakravarty wrote:
> > Wait I am sure I am going wrong in a fundamental area.
> >
> > My security constraint is as follow-:
> >
> > <security-constraint> <web-resource-collection>
> > <web-resource-name>TECHERS</web-resource-name>
> > <url-pattern>/teacher/success.jsp</url-pattern>
> > <http-method>GET</http-method> <http-method>POST</http-method>
> > </web-resource-collection>
> >
> > <auth-constraint> <role-name>TEACHER</role-name>
> > </auth-constraint> </security-constraint>
> >
> > <login-config> <auth-method>FORM</auth-method> <form-login-config>
> > <form-login-page>/index.jsp</form-login-page>
> > <form-error-page>/index.jsp?error=true</form-error-page>
> > </form-login-config> </login-config>
> >
> > <security-role> <role-name>TEACHER</role-name> </security-role>
> >
> > Now let me tell you what I understand from this-:
> >
> >
> > - The <web-resource-collection> /teacher/success.jsp is protected
> > via a FORM login page that is index.jsp - Therefore the page after
> > login which the user will land to is /teacher/success.jsp. I don't
> > need to specify that elsewhere. - <form-login-page> element
> > designates the login page. - <form-error-page> element designates
> > the page to go to if login has failed.
> >
> > This is my understanding of the whole process. Please don't tell me
> > that I have to put <form-login-page> as /teacher/success.jsp. If so
> > then where do I designate the login page ?
> >
> > Forgive my noobishness. Just starting out with servlet security.
>
> With your above configuration, you have to point your web browser at
> https://yourhost/teacher/success.jsp
>
> This will cause Tomcat to send you to the login page, and you can ener
> your username and password. Once you enter the right username and
> password, Tomcat will actually send you to /teacher/success.jsp
>
> You really should read the Servlet Spec's section on authentication.
> In fact, read the whole spec. It's quite readable and if you are going
> to be writing web applications, you really ought to have read it.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV5I30AAoJEBzwKT+lPKRYNvUQAIQOP8ShOVFnGkia8kAE2HMO
> mDbr7f54havmRECpC2mCbxvIr3YphXMcDBZJpmuD1IS6ybNIa0hzvX/L2hSmxBYA
> l2oDgInsm+jX+ndkHfZMtKcYp0Fku1Zg4VbSI13z+kTxObBd3tMN0ngkWGqO8YJC
> 4lwV62ho+wx0Xg9r7tpHgqjYfLGDBwJiKkKyG47FNbDtkZFp/BukVMY2QJWKwDuj
> Jb68wQ90jL4xBBLP6zCaJwpNXYjawAdJCCnFJkm90/6DhGzybnWMMQ736CVYdV/T
> 64npEeglSytj/KUJlzsO5aCEMK5CZi13D2CYYP2Svh/bGvrlUoHn3sGuAScavgn5
> NKT5KdyiXkvXV5YOghTaycje9pXBUkQmhHsIWFMj1vuJOU8E0X+Rl+MJ2fSGrgic
> D0x/zM58pUAPKnA2TD8xcUwLCDSo4akqCt64OPZNmM+i2hi2wXYVF4xfKBUD39GV
> oau/MeEj4c8xYHoswC/vC3X1Ol2a3Kliubbb1owXIQUEzILCPFf8tfB/awFMwVDj
> SfYR7nFtPvkHygqVY15Q38w3bxmobwlV/6Zb4mpmPER/OLQuWfNbdT7z/qVIZ53G
> FSOaFfsWOgFFD3mjn1IUezVOjTUSpaTRU5xCIoM6LC7XdOxYLTMFKIyk1rjEEWbh
> 0+wJHnsU1MbmxszEHMxd
> =5ou+
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: HTTP 400 with Form based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sreyan,
On 8/31/15 12:34 PM, Sreyan Chakravarty wrote:
> Wait I am sure I am going wrong in a fundamental area.
>
> My security constraint is as follow-:
>
> <security-constraint> <web-resource-collection>
> <web-resource-name>TECHERS</web-resource-name>
> <url-pattern>/teacher/success.jsp</url-pattern>
> <http-method>GET</http-method> <http-method>POST</http-method>
> </web-resource-collection>
>
> <auth-constraint> <role-name>TEACHER</role-name>
> </auth-constraint> </security-constraint>
>
> <login-config> <auth-method>FORM</auth-method> <form-login-config>
> <form-login-page>/index.jsp</form-login-page>
> <form-error-page>/index.jsp?error=true</form-error-page>
> </form-login-config> </login-config>
>
> <security-role> <role-name>TEACHER</role-name> </security-role>
>
> Now let me tell you what I understand from this-:
>
>
> - The <web-resource-collection> /teacher/success.jsp is protected
> via a FORM login page that is index.jsp - Therefore the page after
> login which the user will land to is /teacher/success.jsp. I don't
> need to specify that elsewhere. - <form-login-page> element
> designates the login page. - <form-error-page> element designates
> the page to go to if login has failed.
>
> This is my understanding of the whole process. Please don't tell me
> that I have to put <form-login-page> as /teacher/success.jsp. If so
> then where do I designate the login page ?
>
> Forgive my noobishness. Just starting out with servlet security.
With your above configuration, you have to point your web browser at
https://yourhost/teacher/success.jsp
This will cause Tomcat to send you to the login page, and you can ener
your username and password. Once you enter the right username and
password, Tomcat will actually send you to /teacher/success.jsp
You really should read the Servlet Spec's section on authentication.
In fact, read the whole spec. It's quite readable and if you are going
to be writing web applications, you really ought to have read it.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV5I30AAoJEBzwKT+lPKRYNvUQAIQOP8ShOVFnGkia8kAE2HMO
mDbr7f54havmRECpC2mCbxvIr3YphXMcDBZJpmuD1IS6ybNIa0hzvX/L2hSmxBYA
l2oDgInsm+jX+ndkHfZMtKcYp0Fku1Zg4VbSI13z+kTxObBd3tMN0ngkWGqO8YJC
4lwV62ho+wx0Xg9r7tpHgqjYfLGDBwJiKkKyG47FNbDtkZFp/BukVMY2QJWKwDuj
Jb68wQ90jL4xBBLP6zCaJwpNXYjawAdJCCnFJkm90/6DhGzybnWMMQ736CVYdV/T
64npEeglSytj/KUJlzsO5aCEMK5CZi13D2CYYP2Svh/bGvrlUoHn3sGuAScavgn5
NKT5KdyiXkvXV5YOghTaycje9pXBUkQmhHsIWFMj1vuJOU8E0X+Rl+MJ2fSGrgic
D0x/zM58pUAPKnA2TD8xcUwLCDSo4akqCt64OPZNmM+i2hi2wXYVF4xfKBUD39GV
oau/MeEj4c8xYHoswC/vC3X1Ol2a3Kliubbb1owXIQUEzILCPFf8tfB/awFMwVDj
SfYR7nFtPvkHygqVY15Q38w3bxmobwlV/6Zb4mpmPER/OLQuWfNbdT7z/qVIZ53G
FSOaFfsWOgFFD3mjn1IUezVOjTUSpaTRU5xCIoM6LC7XdOxYLTMFKIyk1rjEEWbh
0+wJHnsU1MbmxszEHMxd
=5ou+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HTTP 400 with Form based authentication
Posted by Sreyan Chakravarty <sr...@gmail.com>.
Wait I am sure I am going wrong in a fundamental area.
My security constraint is as follow-:
<security-constraint>
<web-resource-collection>
<web-resource-name>TECHERS</web-resource-name>
<url-pattern>/teacher/success.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>TEACHER</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/index.jsp</form-login-page>
<form-error-page>/index.jsp?error=true</form-error-page>
</form-login-config>
</login-config>
<security-role>
<role-name>TEACHER</role-name>
</security-role>
Now let me tell you what I understand from this-:
- The <web-resource-collection> /teacher/success.jsp is protected via a
FORM login page that is index.jsp
- Therefore the page after login which the user will land to is
/teacher/success.jsp. I don't need to specify that elsewhere.
- <form-login-page> element designates the login page.
- <form-error-page> element designates the page to go to if login has
failed.
This is my understanding of the whole process. Please don't tell me that I
have to put <form-login-page> as /teacher/success.jsp. If so then where do
I designate the login page ?
Forgive my noobishness. Just starting out with servlet security.
Regards
Sreyan Chakravarty
On Mon, Aug 31, 2015 at 3:59 PM, Mark Thomas <ma...@apache.org> wrote:
> On 31/08/2015 07:00, Sreyan Chakravarty wrote:
> > I don't understand where did I request the login page directly ? I just
> put
> > <form-login-config> as index.jsp and and the error page as
> > index.jsp?error=true.
> >
> > So where is my error ?
>
> Did you request '/teacher/success.jsp' ? No, you did not.
>
> Did you request '/index.jsp' (or '/' that because of welcome page
> processing would forward to '/index.jsp') ? Yes, you did. And that is
> your error.
>
> Mark
>
>
> >
> > On Sun, Aug 30, 2015 at 9:54 PM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 29/08/2015 22:16, Sreyan Chakravarty wrote:
> >>> Okay this is my first try at container based authentication using
> Realms
> >> in
> >>> Tomcat. And things have gone wrong. Here is my login page -:
> >>
> >> <snip/>
> >>
> >>
> >>> My web.xml security configuration is -:
> >>>
> >>> <security-constraint>
> >>> <web-resource-collection>
> >>> <web-resource-name>TECHERS</web-resource-name>
> >>> <url-pattern>/teacher/success.jsp</url-pattern>
> >>> <http-method>GET</http-method>
> >>> <http-method>POST</http-method>
> >>> </web-resource-collection>
> >>
> >> Remove the methods. By enumerating methods ONLY those methods are
> >> protected. PUT, HEAD, DELETE, etc. aould all be permitted.
> >>
> >>
> >> <snip/>
> >>
> >>> Now when I click on submit I get the following error page in Tomcat -:
> >>>
> >>>
> >>> *HTTP Status 400 - Invalid direct reference to form login page*
> >>>
> >>> *message* *Invalid direct reference to form login page*
> >>>
> >>> *description* *The request sent by the client was syntactically
> >> incorrect.*
> >>>
> >>>
> >>> Why is this happening ? Any help would be greatly appreciated.
> >>
> >> Because you requested the login page directly. You need to request the
> >> protected page and Tomcat will handle the redirects.
> >>
> >> Mark
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
Re: HTTP 400 with Form based authentication
Posted by Mark Thomas <ma...@apache.org>.
On 31/08/2015 07:00, Sreyan Chakravarty wrote:
> I don't understand where did I request the login page directly ? I just put
> <form-login-config> as index.jsp and and the error page as
> index.jsp?error=true.
>
> So where is my error ?
Did you request '/teacher/success.jsp' ? No, you did not.
Did you request '/index.jsp' (or '/' that because of welcome page
processing would forward to '/index.jsp') ? Yes, you did. And that is
your error.
Mark
>
> On Sun, Aug 30, 2015 at 9:54 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 29/08/2015 22:16, Sreyan Chakravarty wrote:
>>> Okay this is my first try at container based authentication using Realms
>> in
>>> Tomcat. And things have gone wrong. Here is my login page -:
>>
>> <snip/>
>>
>>
>>> My web.xml security configuration is -:
>>>
>>> <security-constraint>
>>> <web-resource-collection>
>>> <web-resource-name>TECHERS</web-resource-name>
>>> <url-pattern>/teacher/success.jsp</url-pattern>
>>> <http-method>GET</http-method>
>>> <http-method>POST</http-method>
>>> </web-resource-collection>
>>
>> Remove the methods. By enumerating methods ONLY those methods are
>> protected. PUT, HEAD, DELETE, etc. aould all be permitted.
>>
>>
>> <snip/>
>>
>>> Now when I click on submit I get the following error page in Tomcat -:
>>>
>>>
>>> *HTTP Status 400 - Invalid direct reference to form login page*
>>>
>>> *message* *Invalid direct reference to form login page*
>>>
>>> *description* *The request sent by the client was syntactically
>> incorrect.*
>>>
>>>
>>> Why is this happening ? Any help would be greatly appreciated.
>>
>> Because you requested the login page directly. You need to request the
>> protected page and Tomcat will handle the redirects.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: HTTP 400 with Form based authentication
Posted by Sreyan Chakravarty <sr...@gmail.com>.
I don't understand where did I request the login page directly ? I just put
<form-login-config> as index.jsp and and the error page as
index.jsp?error=true.
So where is my error ?
On Sun, Aug 30, 2015 at 9:54 PM, Mark Thomas <ma...@apache.org> wrote:
> On 29/08/2015 22:16, Sreyan Chakravarty wrote:
> > Okay this is my first try at container based authentication using Realms
> in
> > Tomcat. And things have gone wrong. Here is my login page -:
>
> <snip/>
>
>
> > My web.xml security configuration is -:
> >
> > <security-constraint>
> > <web-resource-collection>
> > <web-resource-name>TECHERS</web-resource-name>
> > <url-pattern>/teacher/success.jsp</url-pattern>
> > <http-method>GET</http-method>
> > <http-method>POST</http-method>
> > </web-resource-collection>
>
> Remove the methods. By enumerating methods ONLY those methods are
> protected. PUT, HEAD, DELETE, etc. aould all be permitted.
>
>
> <snip/>
>
> > Now when I click on submit I get the following error page in Tomcat -:
> >
> >
> > *HTTP Status 400 - Invalid direct reference to form login page*
> >
> > *message* *Invalid direct reference to form login page*
> >
> > *description* *The request sent by the client was syntactically
> incorrect.*
> >
> >
> > Why is this happening ? Any help would be greatly appreciated.
>
> Because you requested the login page directly. You need to request the
> protected page and Tomcat will handle the redirects.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: HTTP 400 with Form based authentication
Posted by Mark Thomas <ma...@apache.org>.
On 29/08/2015 22:16, Sreyan Chakravarty wrote:
> Okay this is my first try at container based authentication using Realms in
> Tomcat. And things have gone wrong. Here is my login page -:
<snip/>
> My web.xml security configuration is -:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>TECHERS</web-resource-name>
> <url-pattern>/teacher/success.jsp</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
Remove the methods. By enumerating methods ONLY those methods are
protected. PUT, HEAD, DELETE, etc. aould all be permitted.
<snip/>
> Now when I click on submit I get the following error page in Tomcat -:
>
>
> *HTTP Status 400 - Invalid direct reference to form login page*
>
> *message* *Invalid direct reference to form login page*
>
> *description* *The request sent by the client was syntactically incorrect.*
>
>
> Why is this happening ? Any help would be greatly appreciated.
Because you requested the login page directly. You need to request the
protected page and Tomcat will handle the redirects.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org