subject:"form based authentication"

-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Fwd: HTTP 400 with Form based authentication

2015-09-09 Thread Sreyan Chakravarty

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.mail...@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) 
> 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  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-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>

Re: HTTP 400 with Form based authentication

-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 . Then why
> is it I am getting a 500 error. Clearly something is wrong from my
> side or else the  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 
> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

2015-09-09 Thread Sreyan Chakravarty

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 <
ch...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: HTTP 400 with Form based authentication

2015-09-07 Thread tomcat

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 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

2015-09-07 Thread Sreyan Chakravarty

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 . Then why is it I am getting
a 500 error. Clearly something is wrong from my side or else the

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  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 <
ch...@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  element you should already have.
>
> > Any documentation for this ?
>
> Just what you have already read:
>
> 
>... other configuration attributes ...
> />
> 
>
> - -chris
>
> > On Tue, Sep 1, 2015 at 12:46 AM, Sreyan Chakravarty <
> > sreyan.mail...@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  elements in my web.xml ?
> >>
> >> On Mon, Aug 31, 2015 at 11:19 PM,

Re: HTTP 400 with Form based authentication

2015-09-07 Thread Sreyan Chakravarty

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) 
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  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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: HTTP 400 with Form based authentication

2015-09-07 Thread Sreyan Chakravarty

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.mail...@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) 
> 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  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-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>

Re: HTTP 400 with Form based authentication

2015-09-01 Thread Christopher Schultz

-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  element you should already have.

> Any documentation for this ?

Just what you have already read:


  


- -chris

> On Tue, Sep 1, 2015 at 12:46 AM, Sreyan Chakravarty < 
> sreyan.mail...@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  elements in my web.xml ?
>> 
>> On Mon, Aug 31, 2015 at 11:19 PM, Christopher Schultz < 
>> ch...@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 
>  like  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-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@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

Re: HTTP 400 with Form based authentication

2015-09-01 Thread Christopher Schultz

-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:

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  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

I don't understand where did I request the login page directly ? I just put
 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  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 -:
>
> 
>
>
> > My web.xml security configuration is -:
> >
> > 
> > 
> > TECHERS
> > /teacher/success.jsp
> > GET
> > POST
> > 
>
> Remove the methods. By enumerating methods ONLY those methods are
> protected. PUT, HEAD, DELETE, etc. aould all be permitted.
>
>
> 
>
> > 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: HTTP 400 with Form based authentication

Wait I am sure I am going wrong in a fundamental area.

My security constraint is as follow-:



TECHERS
/teacher/success.jsp
GET
POST



TEACHER




FORM

/index.jsp
/index.jsp?error=true




TEACHER


Now let me tell you what I understand from this-:


   - The  /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.
   -  element designates the login 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  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  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
> >  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  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 -:
> >>
> >> 
> >>
> >>
> >>> My web.xml security configuration is -:
> >>>
> >>> 
> >>> 
> >>> TECHERS
> >>> /teacher/success.jsp
> >>> GET
> >>> POST
> >>> 
> >>
> >> Remove the methods. By enumerating methods ONLY those methods are
> >> protected. PUT, HEAD, DELETE, etc. aould all be permitted.
> >>
> >>
> >> 
> >>
> >>> 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-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: HTTP 400 with Form based authentication

2015-08-31 Thread Caldarale, Charles R

> From: Sreyan Chakravarty [mailto:sreyan.mail...@gmail.com] 
> Subject: Re: HTTP 400 with Form based authentication

> My security constraint is as follow-:
> 
> FORM
> 
> /index.jsp
> /index.jsp?error=true
> 
> 

> This is my understanding of the whole process. Please don't tell me that I
> have to put  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

2015-08-31 Thread Christopher Schultz

-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-:
> 
>   
> TECHERS 
> /teacher/success.jsp 
> GET POST 
> 
> 
>  TEACHER 
>  
> 
>  FORM  
> /index.jsp 
> /index.jsp?error=true 
>  
> 
>  TEACHER 
> 
> Now let me tell you what I understand from this-:
> 
> 
> - The  /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. -  element
> designates the login 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  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

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 <
ch...@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-:
> >
> >  
> > TECHERS
> > /teacher/success.jsp
> > GET POST
> > 
> >
> >  TEACHER
> >  
> >
> >  FORM 
> > /index.jsp
> > /index.jsp?error=true
> >  
> >
> >  TEACHER 
> >
> > Now let me tell you what I understand from this-:
> >
> >
> > - The  /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. -  element
> > designates the login 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  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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: HTTP 400 with Form based authentication

2015-08-31 Thread Christopher Schultz

-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
 like  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

2015-08-31 Thread Mark Thomas

On 31/08/2015 18:49, Christopher Schultz wrote:

> Really the only thing the servlet spec is missing is a setting in
>  like  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

2015-08-31 Thread Christopher Schultz

-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  like  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

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  elements in my web.xml ?

On Mon, Aug 31, 2015 at 11:19 PM, Christopher Schultz <
ch...@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
>  like  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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: HTTP 400 with Form based authentication

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.mail...@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  elements in my web.xml ?
>
> On Mon, Aug 31, 2015 at 11:19 PM, Christopher Schultz <
> ch...@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
>>  like  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-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>

Re: HTTP 400 with Form based authentication

2015-08-31 Thread Mark Thomas

On 31/08/2015 07:00, Sreyan Chakravarty wrote:
> I don't understand where did I request the login page directly ? I just put
>  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  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 -:
>>
>> 
>>
>>
>>> My web.xml security configuration is -:
>>>
>>> 
>>> 
>>> TECHERS
>>> /teacher/success.jsp
>>> GET
>>> POST
>>> 
>>
>> Remove the methods. By enumerating methods ONLY those methods are
>> protected. PUT, HEAD, DELETE, etc. aould all be permitted.
>>
>>
>> 
>>
>>> 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-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP 400 with Form based authentication

2015-08-30 Thread Mark Thomas

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-nameTECHERS/web-resource-name
 url-pattern/teacher/success.jsp/url-pattern
 http-methodGET/http-method
 http-methodPOST/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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

HTTP 400 with Form based authentication

2015-08-29 Thread Sreyan Chakravarty

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
h2Login/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 /
titleHello User/title
/head
body
h3Success/h3
/body
/html

Also as simple as it can get.

My web.xml security configuration is -:

security-constraint
web-resource-collection
web-resource-nameTECHERS/web-resource-name
url-pattern/teacher/success.jsp/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection

auth-constraint
role-nameTEACHER/role-name
/auth-constraint
/security-constraint

login-config
auth-methodFORM/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-nameTEACHER/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 = 11
   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

How to set Session Values with Form Based Authentication

2015-08-25 Thread Thusitha Thilina Dayaratne

Hi,

I'm using form based authentication with j_security_check. I want to set
some session values upon the user login. I can set them in the index page.
But when user directly put some other url then it will redirect to login
page and then back to the actual requested page. Therefore my logic on
index page will not get execute.
Is there a way for me to set the session value when using j-security_check
based form authentication in Tomcat?

Thanks
/Thusitha

--

Re: Form-based authentication breaks after upgrade to Tom 7.0.59

2015-03-13 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rop,

On 3/12/15 7:10 PM, rop wrote:
 Hi Chris, Yes, we are applying salt before hashing (to prevent
 googling up many passwords from the hashes).

Depending upon how you are storing the salt, you may be able to use
Tomcat out of the box, now, because Tomcat can now do salted passwords
(it was way overdue).

 Override probably seemed like easiest way at the time, but maybe a
 better way now. Will check it out, thanks.

You will be better-off moving away from Realm and towards
CredentialHandler instead. Consider beginning to evaluate that for the
future.

- -chris

 On Thu, Mar 12, 2015 at 8:53 PM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 
 Rop,
 
 On 3/12/15 3:33 PM, rop wrote:
 Finally, found the issue.
 
 Please bottom-post if you can. Also, please sign your posts.
 
 On Thu, Mar 12, 2015 at 6:18 PM, Mark Thomas
 ma...@apache.org wrote:
 
 On 12/03/2015 15:51, rop wrote:
 Ah, I got it now. Thanks, David.
 
 Yes, the a-b-c-d points are OK then.
 
 As a trouble-shoot action, I actually did an
 install-and-test binary search among the intermediate
 tomcat-versions to pinpoint exactly which version breaks
 our app.
 
 Turns out, up to 7.0.47 it still works OK. (7.0.48 and
 7.0.49 do not exist in the tomcat archive) And from
 7.0.50 it breaks.
 
 So apparently, between 47 and 50 some change occurred
 that breaks our login
 
 Nothing jumps out at me in the change log. I'd add that
 FORM auth is tested as part of every release so it isn't a
 general problem.
 
 In your shoes, I'd be firing up Eclipse and remote
 debugging my way through the authentication process.
 Alternatively, try creating the smallest/simplest possible
 WAR that exhibits the problem.
 
 The crucial change was in the method 
 RealmBase.compareCredentials(), which is new in 7.0.50 (the 
 comparison was much simpler before that).
 
 It is much more extensible, now.
 
 Dunno if we do something unusual here, but we just extend 
 DataSourceRealm, like MyDataSourceRealm, and implement the 
 message-digest for password-hashing in there, by simply
 overriding the digest() method.
 
 Do you need to extend the whole realm, or did you just want to 
 override Tomcat's default password-hashing algorithm?
 
 If you just want to tweak the hashing algorithm, you can write a 
 simpler class and not subclass DataSourceRealm. What does your
 Realm do besides change the password-comparison algorithm?
 
 Before 7.0.50, this worked fine *without* explicitly setting
 the DataSourceRealm.setDigest() property. It's always been
 null, and still worked.
 
 This was because it defaulted to MD5 and Tomcat always used 
 simplistic credential-hashing. It's much more sophisticated, now,
 and also supports things like Bcrypt, Scrypt, PBKDF2, etc.
 
 But the new method RealmBase.compareCredentials() assumes: if
 you use messageDigest, this property MUST be set. ( 
 compareCredentials() calls hasMessageDigest() which did not
 happen in earlier versions. )
 
 So the solution was to simply add the property digest in
 Realm digest=... ... which we didnt have there before.
 Then it works.
 
 Great. But I think you can do better. If your Realm merely changes
 the way hashing is done, please check-out the new features. You may
 be able to a) eliminate your class altogether due to new features
 or b) replace your Realm with a CredentialHandler that only does
 the mutation and comparison of credentials.
 
 We did this so you can use the same credential-mutations on *any* 
 realm, without having to subclass every Realm to do it.
 
 Hope that helps, -chris
 
 -

 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVAvnDAAoJEBzwKT+lPKRYswIQAK+OITerGZSKo0NWWtpDGZZk
yFbT2fwf4HfqveG0pP24pcF+1EJAkKJlPt+D/eonRw4REdVBjWlj5KOBVNSJSEcw
JS+2tcOYNdJFx/EYL1EvTOCB4mKuzwpyfegikfP6pj/hy1rBXGOzVVNpHPIoUQ5Q
ugkWqBckBZa/jVDwsvWbZUJPTuwYFs4HqdEfH4Y9NRvzBNz3a/cIjnRB75jAl+AY
0Wdcfe1YifFssVQv/jX8b+kUhVcrYQzS1EKzyJzuPcPYwF8X7sCLDB8QMkrB6Gkg
FMHZA48ytQSrGJyq+rZ62C97Y/nXsQ4EKsK4+cLwcinjfEJ5MhSvZGY7I8Vm+cQk
Xpika0vRNV8NtX+vqpdTS7lg/QeqZkUFn2KrDtpNyyS2e9lsbJ3laCcmDgg345VS
DY7icmTsuNbc9gcWMJzcf5AuSmf/U2GhhTgIza9mO9SkT/uckxOYX8q6bu1WT/8L
wSJeGPRI/VqIEik83X3dFWP6BcCguidjOB4J1uAowl1T1fKhrmVlsZ3LP9m9MWbO
0E4P7bRKIX3JlZvyqI2U2UFheFefj0vK/PCIUAttNDzuXENPvxigEiVrvYf5Qx37
JfVrW5cxHMGyUQ3YIVlZmRiwWT4hnZzbTLHxvs6/1mtu7Zr8267RcissgoEv5E7X
3X/MceB38qv4a3npJchq
=HqR1
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Form-based authentication breaks after upgrade to Tom 7.0.59

2015-03-12 Thread David kerber


On 3/12/2015 10:16 AM, rop wrote:

Hi Chris,

Thanks for your input.

Re your points a+b:
   You have put your Realm into conf/context.xml instead of into your web
application's META-INF/context.xml

Actually neither  we define the Realm in
$CATALINA_BASE/conf/server.xml
That's also what I see in the Tomcat-docs:
http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#DataSourceRealm


That is his option (a) in his list.  Did you check that?




And I see no mention of META-INF anywhere in there.

Can you please elaborate what you're referring to?




On Wed, Mar 11, 2015 at 2:26 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rop,

On 3/10/15 2:57 PM, rop wrote:

We are trying to upgrade Tomcat from 7.0.35 to 7.0.59.

For some reason, the form-based authentication gets broken after
the upgrade, and just gives Invalid username and/or password,
please try again when trying to login.

Cannot find anything in catalina.out related to this.


What about the other log files in logs/? Nothing?

:(


 From our logging, it appears the DataSourceRealm.authenticate()
never gets called at all.


What is your Realm configuration, and in what file is it configured?


If I downgrade to 7.0.35, it works again...

Anyone has a clue if anything changed between these versions, what
the problem might be, or even how to troubleshoot the issue?


Some initial thoughts for what could be wrong:

a. You have put your Realm into conf/server.xml instead of into
your web application's META-INF/context.xml file, and you forgot
to copy that configuration from 7.0.35 to your new 7.0.59
install.

b. You have put your Realm into conf/context.xml instead of into
your web application's META-INF/context.xml file, and you should
not have done that at all; move the Realm into META-INF/context.xml

c. The configuration you are modifying isn't the one that Tomcat is
actually using. I find that this happens a lot to people who are
launching Tomcat from within an IDE like Eclipse, because the IDE
does odd things with configuration management.

d. You installed your JDBC driver into Tomcat 7.0.35's lib/ directory
and didn't copy it into Tomcat 7.0.59's lib/ directory, though this
should have given you errors on startup.

Take a look at those possibilities and let us know what you find.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVAEKTAAoJEBzwKT+lPKRYyHMP/RbZX8neYPrCCGh0lTOQ7PRG
MOXkxFSbQRGsWwV2tyH//Q41IKfSy1Tlb01zbxNklb7gy3h+j+8JgFoYLOjg/iVz
f6XSfw4tUbpTMK/1kqIvpTIMbgi9aK18O+5aLlTdrvAguDZsODgylTi4MTTVZUPZ
v1c+iQbvO8bC7YG81bBm+76rD9pyrMVFbvCPKijfZHTXk5CivaNDwtpysTgDyE65
aG4cHumGSf6JjxSG4cw84OteY6CAYfcNBVDe0/y+F3WKjB6BQ8eHWHEYR57pK+L8
sbxyp6gg5k5Fbrrk/EgEx30CL+rQQfsUkCwKfzlcn3J0fsaE043vnKcNmHA8c6QB
DgC29Bj/o7WkW+hdB7UqB6d0Hq/x+lMZ1JDedEFQFm0IqIxyE3pI6PAX4BHQiWqG
04QB1kRJ32RhYX3+/6Le16FKVxwp2tjuv+xby6gsIGzEY817nIkmRi9SmdR8pGCx
xaxY4uRCNsRrt3fj/nkpygg/ZABueMt+2ix0Nqpe8Wi5T6O8sTRW3jUqj8ZY78+G
rbJZGBEbUuXe5s5o+ZsIfSjKY1U4NTtQhDd+ti8RpkDGy/pcSj2CNyPJ9NLS4E/u
Lb1JdV2nANX4s5r7vWVP1Satzk4DGSx2e93ddy5wDk14vp09d1Fezaq5H8FXUxnc
mzjWDKZT3BY6OqVoN2yj
=b0eg
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Form-based authentication breaks after upgrade to Tom 7.0.59

Hi Chris,

Thanks for your input.

Re your points a+b:
  You have put your Realm into conf/context.xml instead of into your web
application's META-INF/context.xml

Actually neither  we define the Realm in
$CATALINA_BASE/conf/server.xml
That's also what I see in the Tomcat-docs:
   http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#DataSourceRealm

And I see no mention of META-INF anywhere in there.

Can you please elaborate what you're referring to?




On Wed, Mar 11, 2015 at 2:26 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Rop,

 On 3/10/15 2:57 PM, rop wrote:
  We are trying to upgrade Tomcat from 7.0.35 to 7.0.59.
 
  For some reason, the form-based authentication gets broken after
  the upgrade, and just gives Invalid username and/or password,
  please try again when trying to login.
 
  Cannot find anything in catalina.out related to this.

 What about the other log files in logs/? Nothing?

 :(

  From our logging, it appears the DataSourceRealm.authenticate()
  never gets called at all.

 What is your Realm configuration, and in what file is it configured?

  If I downgrade to 7.0.35, it works again...
 
  Anyone has a clue if anything changed between these versions, what
  the problem might be, or even how to troubleshoot the issue?

 Some initial thoughts for what could be wrong:

 a. You have put your Realm into conf/server.xml instead of into
your web application's META-INF/context.xml file, and you forgot
to copy that configuration from 7.0.35 to your new 7.0.59
install.

 b. You have put your Realm into conf/context.xml instead of into
your web application's META-INF/context.xml file, and you should
not have done that at all; move the Realm into META-INF/context.xml

 c. The configuration you are modifying isn't the one that Tomcat is
actually using. I find that this happens a lot to people who are
launching Tomcat from within an IDE like Eclipse, because the IDE
does odd things with configuration management.

 d. You installed your JDBC driver into Tomcat 7.0.35's lib/ directory
and didn't copy it into Tomcat 7.0.59's lib/ directory, though this
should have given you errors on startup.

 Take a look at those possibilities and let us know what you find.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org

 iQIcBAEBCAAGBQJVAEKTAAoJEBzwKT+lPKRYyHMP/RbZX8neYPrCCGh0lTOQ7PRG
 MOXkxFSbQRGsWwV2tyH//Q41IKfSy1Tlb01zbxNklb7gy3h+j+8JgFoYLOjg/iVz
 f6XSfw4tUbpTMK/1kqIvpTIMbgi9aK18O+5aLlTdrvAguDZsODgylTi4MTTVZUPZ
 v1c+iQbvO8bC7YG81bBm+76rD9pyrMVFbvCPKijfZHTXk5CivaNDwtpysTgDyE65
 aG4cHumGSf6JjxSG4cw84OteY6CAYfcNBVDe0/y+F3WKjB6BQ8eHWHEYR57pK+L8
 sbxyp6gg5k5Fbrrk/EgEx30CL+rQQfsUkCwKfzlcn3J0fsaE043vnKcNmHA8c6QB
 DgC29Bj/o7WkW+hdB7UqB6d0Hq/x+lMZ1JDedEFQFm0IqIxyE3pI6PAX4BHQiWqG
 04QB1kRJ32RhYX3+/6Le16FKVxwp2tjuv+xby6gsIGzEY817nIkmRi9SmdR8pGCx
 xaxY4uRCNsRrt3fj/nkpygg/ZABueMt+2ix0Nqpe8Wi5T6O8sTRW3jUqj8ZY78+G
 rbJZGBEbUuXe5s5o+ZsIfSjKY1U4NTtQhDd+ti8RpkDGy/pcSj2CNyPJ9NLS4E/u
 Lb1JdV2nANX4s5r7vWVP1Satzk4DGSx2e93ddy5wDk14vp09d1Fezaq5H8FXUxnc
 mzjWDKZT3BY6OqVoN2yj
 =b0eg
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Form-based authentication breaks after upgrade to Tom 7.0.59

Ah, I got it now.
Thanks, David.

Yes, the a-b-c-d points are OK then.

As a trouble-shoot action, I actually did an install-and-test binary
search
among the intermediate tomcat-versions to pinpoint exactly which version
breaks our app.

Turns out, up to 7.0.47 it still works OK.
(7.0.48 and 7.0.49 do not exist in the tomcat archive)
And from 7.0.50 it breaks.

So apparently, between 47 and 50 some change occurred that breaks our
login


On Thu, Mar 12, 2015 at 3:37 PM, David kerber dcker...@verizon.net wrote:

 On 3/12/2015 10:16 AM, rop wrote:

 Hi Chris,

 Thanks for your input.

 Re your points a+b:
You have put your Realm into conf/context.xml instead of into your
 web
 application's META-INF/context.xml

 Actually neither  we define the Realm in
 $CATALINA_BASE/conf/server.xml
 That's also what I see in the Tomcat-docs:
 http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.
 html#DataSourceRealm


 That is his option (a) in his list.  Did you check that?




 And I see no mention of META-INF anywhere in there.

 Can you please elaborate what you're referring to?




 On Wed, Mar 11, 2015 at 2:26 PM, Christopher Schultz 
 ch...@christopherschultz.net wrote:

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Rop,

 On 3/10/15 2:57 PM, rop wrote:

 We are trying to upgrade Tomcat from 7.0.35 to 7.0.59.

 For some reason, the form-based authentication gets broken after
 the upgrade, and just gives Invalid username and/or password,
 please try again when trying to login.

 Cannot find anything in catalina.out related to this.


 What about the other log files in logs/? Nothing?

 :(

   From our logging, it appears the DataSourceRealm.authenticate()
 never gets called at all.


 What is your Realm configuration, and in what file is it configured?

  If I downgrade to 7.0.35, it works again...

 Anyone has a clue if anything changed between these versions, what
 the problem might be, or even how to troubleshoot the issue?


 Some initial thoughts for what could be wrong:

 a. You have put your Realm into conf/server.xml instead of into
 your web application's META-INF/context.xml file, and you forgot
 to copy that configuration from 7.0.35 to your new 7.0.59
 install.

 b. You have put your Realm into conf/context.xml instead of into
 your web application's META-INF/context.xml file, and you should
 not have done that at all; move the Realm into META-INF/context.xml

 c. The configuration you are modifying isn't the one that Tomcat is
 actually using. I find that this happens a lot to people who are
 launching Tomcat from within an IDE like Eclipse, because the IDE
 does odd things with configuration management.

 d. You installed your JDBC driver into Tomcat 7.0.35's lib/ directory
 and didn't copy it into Tomcat 7.0.59's lib/ directory, though this
 should have given you errors on startup.

 Take a look at those possibilities and let us know what you find.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org

 iQIcBAEBCAAGBQJVAEKTAAoJEBzwKT+lPKRYyHMP/RbZX8neYPrCCGh0lTOQ7PRG
 MOXkxFSbQRGsWwV2tyH//Q41IKfSy1Tlb01zbxNklb7gy3h+j+8JgFoYLOjg/iVz
 f6XSfw4tUbpTMK/1kqIvpTIMbgi9aK18O+5aLlTdrvAguDZsODgylTi4MTTVZUPZ
 v1c+iQbvO8bC7YG81bBm+76rD9pyrMVFbvCPKijfZHTXk5CivaNDwtpysTgDyE65
 aG4cHumGSf6JjxSG4cw84OteY6CAYfcNBVDe0/y+F3WKjB6BQ8eHWHEYR57pK+L8
 sbxyp6gg5k5Fbrrk/EgEx30CL+rQQfsUkCwKfzlcn3J0fsaE043vnKcNmHA8c6QB
 DgC29Bj/o7WkW+hdB7UqB6d0Hq/x+lMZ1JDedEFQFm0IqIxyE3pI6PAX4BHQiWqG
 04QB1kRJ32RhYX3+/6Le16FKVxwp2tjuv+xby6gsIGzEY817nIkmRi9SmdR8pGCx
 xaxY4uRCNsRrt3fj/nkpygg/ZABueMt+2ix0Nqpe8Wi5T6O8sTRW3jUqj8ZY78+G
 rbJZGBEbUuXe5s5o+ZsIfSjKY1U4NTtQhDd+ti8RpkDGy/pcSj2CNyPJ9NLS4E/u
 Lb1JdV2nANX4s5r7vWVP1Satzk4DGSx2e93ddy5wDk14vp09d1Fezaq5H8FXUxnc
 mzjWDKZT3BY6OqVoN2yj
 =b0eg
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org





 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Form-based authentication breaks after upgrade to Tom 7.0.59

2015-03-12 Thread Mark Thomas

On 12/03/2015 15:51, rop wrote:
 Ah, I got it now.
 Thanks, David.
 
 Yes, the a-b-c-d points are OK then.
 
 As a trouble-shoot action, I actually did an install-and-test binary
 search
 among the intermediate tomcat-versions to pinpoint exactly which version
 breaks our app.
 
 Turns out, up to 7.0.47 it still works OK.
 (7.0.48 and 7.0.49 do not exist in the tomcat archive)
 And from 7.0.50 it breaks.
 
 So apparently, between 47 and 50 some change occurred that breaks our
 login

Nothing jumps out at me in the change log. I'd add that FORM auth is
tested as part of every release so it isn't a general problem.

In your shoes, I'd be firing up Eclipse and remote debugging my way
through the authentication process. Alternatively, try creating the
smallest/simplest possible WAR that exhibits the problem.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Form-based authentication breaks after upgrade to Tom 7.0.59

Finally, found the issue.

The crucial change was in the method RealmBase.compareCredentials(),
which is new in 7.0.50 (the comparison was much simpler before that).

Dunno if we do something unusual here,
but we just extend DataSourceRealm, like MyDataSourceRealm,
and implement the message-digest for password-hashing in there,
by simply overriding the digest() method.

Before 7.0.50, this worked fine *without* explicitly setting the
DataSourceRealm.setDigest() property.
It's always been null, and still worked.

But the new method RealmBase.compareCredentials() assumes: if you use
messageDigest, this property MUST be set.
( compareCredentials() calls hasMessageDigest() which did not happen in
earlier versions. )

So the solution was to simply add the property digest in
Realm digest=... ...
which we didnt have there before.
Then it works.


On Thu, Mar 12, 2015 at 6:18 PM, Mark Thomas ma...@apache.org wrote:

 On 12/03/2015 15:51, rop wrote:
  Ah, I got it now.
  Thanks, David.
 
  Yes, the a-b-c-d points are OK then.
 
  As a trouble-shoot action, I actually did an install-and-test binary
  search
  among the intermediate tomcat-versions to pinpoint exactly which version
  breaks our app.
 
  Turns out, up to 7.0.47 it still works OK.
  (7.0.48 and 7.0.49 do not exist in the tomcat archive)
  And from 7.0.50 it breaks.
 
  So apparently, between 47 and 50 some change occurred that breaks our
  login

 Nothing jumps out at me in the change log. I'd add that FORM auth is
 tested as part of every release so it isn't a general problem.

 In your shoes, I'd be firing up Eclipse and remote debugging my way
 through the authentication process. Alternatively, try creating the
 smallest/simplest possible WAR that exhibits the problem.

 Mark

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Form-based authentication breaks after upgrade to Tom 7.0.59

2015-03-12 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rop,

On 3/12/15 3:33 PM, rop wrote:
 Finally, found the issue.

Please bottom-post if you can. Also, please sign your posts.

 On Thu, Mar 12, 2015 at 6:18 PM, Mark Thomas ma...@apache.org
 wrote:
 
 On 12/03/2015 15:51, rop wrote:
 Ah, I got it now. Thanks, David.
 
 Yes, the a-b-c-d points are OK then.
 
 As a trouble-shoot action, I actually did an install-and-test
 binary search among the intermediate tomcat-versions to
 pinpoint exactly which version breaks our app.
 
 Turns out, up to 7.0.47 it still works OK. (7.0.48 and 7.0.49
 do not exist in the tomcat archive) And from 7.0.50 it breaks.
 
 So apparently, between 47 and 50 some change occurred that
 breaks our login
 
 Nothing jumps out at me in the change log. I'd add that FORM auth
 is tested as part of every release so it isn't a general
 problem.
 
 In your shoes, I'd be firing up Eclipse and remote debugging my
 way through the authentication process. Alternatively, try
 creating the smallest/simplest possible WAR that exhibits the
 problem.
 
 The crucial change was in the method
 RealmBase.compareCredentials(), which is new in 7.0.50 (the
 comparison was much simpler before that).

It is much more extensible, now.

 Dunno if we do something unusual here, but we just extend
 DataSourceRealm, like MyDataSourceRealm, and implement the
 message-digest for password-hashing in there, by simply overriding
 the digest() method.

Do you need to extend the whole realm, or did you just want to
override Tomcat's default password-hashing algorithm?

If you just want to tweak the hashing algorithm, you can write a
simpler class and not subclass DataSourceRealm. What does your Realm
do besides change the password-comparison algorithm?

 Before 7.0.50, this worked fine *without* explicitly setting the 
 DataSourceRealm.setDigest() property. It's always been null, and
 still worked.

This was because it defaulted to MD5 and Tomcat always used
simplistic credential-hashing. It's much more sophisticated, now, and
also supports things like Bcrypt, Scrypt, PBKDF2, etc.

 But the new method RealmBase.compareCredentials() assumes: if you
 use messageDigest, this property MUST be set. (
 compareCredentials() calls hasMessageDigest() which did not happen
 in earlier versions. )
 
 So the solution was to simply add the property digest in Realm
 digest=... ... which we didnt have there before. Then it works.

Great. But I think you can do better. If your Realm merely changes the
way hashing is done, please check-out the new features. You may be
able to a) eliminate your class altogether due to new features or b)
replace your Realm with a CredentialHandler that only does the
mutation and comparison of credentials.

We did this so you can use the same credential-mutations on *any*
realm, without having to subclass every Realm to do it.

Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVAe6tAAoJEBzwKT+lPKRYl6UP/AhEtn5f53OPipu+EN1r3iKR
CkjrSZDT89yQ3LEqdV7mHkP1O1834MS8a21QVJ+AuLmceor2KRMkiwdAWbfa/uAx
5FKXg80n3Cu0lFQXrD3dHRq92+JPFJuAhN60s2VU+O76rbRgT4RkLULJa7j/t7Jr
H2vQXL/kY2/y7Ku8Xg+I+be9fBdss7K0DBAq8PT1Qluo2BkHRjf5JU6D59xy0wXZ
KMN6rnN7XRkKRw2/jZlle/fTBHKjIGO5Sq9lsr8KcS7Qpzguxlo3nZjz487pQ8Ok
y1DV3pjNz7y4cZtL5j0zS8zxFf0Tlb5A/xfqn8japLXti0uBZEyld//b42mWlVD1
8OTcTh6B5XyMcqchfvfV/7Fp27EbKl6Gwtdn560NizQ3fCbmyx3QMWY5i1K+lq7P
hlAYh4Xcs8WCS2aZ9s+R48AqsDAPsKVAHAam1i7wOe9k7yk7ziOkNvm1y9LNSseZ
FPDc9G13O/JXDg7GRTOdX3yas2aXCygTkm062fd2Uvvv4E5musaIYE4VDJgAlWUJ
cyY2Zx6DMjjSsDhxNgRgC6Z7c0eyjyHk7haWqMtWgqpDN0z+4qmc78o3hNoW5yfY
TLEZQSKt7q04ECq0xlt0cktcp7hmHaB/gvu5bK+cYS8H4lmGAr9Fg6zbI31Uzyov
xkQ8CoV6X9Oq0TlV3PXi
=Y/0T
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Form-based authentication breaks after upgrade to Tom 7.0.59

Hi Chris,
Yes, we are applying salt before hashing (to prevent googling up many
passwords from the hashes).
Override probably seemed like easiest way at the time, but maybe a better
way now. Will check it out, thanks.
/Rop



On Thu, Mar 12, 2015 at 8:53 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Rop,

 On 3/12/15 3:33 PM, rop wrote:
  Finally, found the issue.

 Please bottom-post if you can. Also, please sign your posts.

  On Thu, Mar 12, 2015 at 6:18 PM, Mark Thomas ma...@apache.org
  wrote:
 
  On 12/03/2015 15:51, rop wrote:
  Ah, I got it now. Thanks, David.
 
  Yes, the a-b-c-d points are OK then.
 
  As a trouble-shoot action, I actually did an install-and-test
  binary search among the intermediate tomcat-versions to
  pinpoint exactly which version breaks our app.
 
  Turns out, up to 7.0.47 it still works OK. (7.0.48 and 7.0.49
  do not exist in the tomcat archive) And from 7.0.50 it breaks.
 
  So apparently, between 47 and 50 some change occurred that
  breaks our login
 
  Nothing jumps out at me in the change log. I'd add that FORM auth
  is tested as part of every release so it isn't a general
  problem.
 
  In your shoes, I'd be firing up Eclipse and remote debugging my
  way through the authentication process. Alternatively, try
  creating the smallest/simplest possible WAR that exhibits the
  problem.
 
  The crucial change was in the method
  RealmBase.compareCredentials(), which is new in 7.0.50 (the
  comparison was much simpler before that).

 It is much more extensible, now.

  Dunno if we do something unusual here, but we just extend
  DataSourceRealm, like MyDataSourceRealm, and implement the
  message-digest for password-hashing in there, by simply overriding
  the digest() method.

 Do you need to extend the whole realm, or did you just want to
 override Tomcat's default password-hashing algorithm?

 If you just want to tweak the hashing algorithm, you can write a
 simpler class and not subclass DataSourceRealm. What does your Realm
 do besides change the password-comparison algorithm?

  Before 7.0.50, this worked fine *without* explicitly setting the
  DataSourceRealm.setDigest() property. It's always been null, and
  still worked.

 This was because it defaulted to MD5 and Tomcat always used
 simplistic credential-hashing. It's much more sophisticated, now, and
 also supports things like Bcrypt, Scrypt, PBKDF2, etc.

  But the new method RealmBase.compareCredentials() assumes: if you
  use messageDigest, this property MUST be set. (
  compareCredentials() calls hasMessageDigest() which did not happen
  in earlier versions. )
 
  So the solution was to simply add the property digest in Realm
  digest=... ... which we didnt have there before. Then it works.

 Great. But I think you can do better. If your Realm merely changes the
 way hashing is done, please check-out the new features. You may be
 able to a) eliminate your class altogether due to new features or b)
 replace your Realm with a CredentialHandler that only does the
 mutation and comparison of credentials.

 We did this so you can use the same credential-mutations on *any*
 realm, without having to subclass every Realm to do it.

 Hope that helps,
 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org

 iQIcBAEBCAAGBQJVAe6tAAoJEBzwKT+lPKRYl6UP/AhEtn5f53OPipu+EN1r3iKR
 CkjrSZDT89yQ3LEqdV7mHkP1O1834MS8a21QVJ+AuLmceor2KRMkiwdAWbfa/uAx
 5FKXg80n3Cu0lFQXrD3dHRq92+JPFJuAhN60s2VU+O76rbRgT4RkLULJa7j/t7Jr
 H2vQXL/kY2/y7Ku8Xg+I+be9fBdss7K0DBAq8PT1Qluo2BkHRjf5JU6D59xy0wXZ
 KMN6rnN7XRkKRw2/jZlle/fTBHKjIGO5Sq9lsr8KcS7Qpzguxlo3nZjz487pQ8Ok
 y1DV3pjNz7y4cZtL5j0zS8zxFf0Tlb5A/xfqn8japLXti0uBZEyld//b42mWlVD1
 8OTcTh6B5XyMcqchfvfV/7Fp27EbKl6Gwtdn560NizQ3fCbmyx3QMWY5i1K+lq7P
 hlAYh4Xcs8WCS2aZ9s+R48AqsDAPsKVAHAam1i7wOe9k7yk7ziOkNvm1y9LNSseZ
 FPDc9G13O/JXDg7GRTOdX3yas2aXCygTkm062fd2Uvvv4E5musaIYE4VDJgAlWUJ
 cyY2Zx6DMjjSsDhxNgRgC6Z7c0eyjyHk7haWqMtWgqpDN0z+4qmc78o3hNoW5yfY
 TLEZQSKt7q04ECq0xlt0cktcp7hmHaB/gvu5bK+cYS8H4lmGAr9Fg6zbI31Uzyov
 xkQ8CoV6X9Oq0TlV3PXi
 =Y/0T
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Form-based authentication breaks after upgrade to Tom 7.0.59

2015-03-11 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rop,

On 3/10/15 2:57 PM, rop wrote:
 We are trying to upgrade Tomcat from 7.0.35 to 7.0.59.
 
 For some reason, the form-based authentication gets broken after
 the upgrade, and just gives Invalid username and/or password,
 please try again when trying to login.
 
 Cannot find anything in catalina.out related to this.

What about the other log files in logs/? Nothing?

:(

 From our logging, it appears the DataSourceRealm.authenticate()
 never gets called at all.

What is your Realm configuration, and in what file is it configured?

 If I downgrade to 7.0.35, it works again...
 
 Anyone has a clue if anything changed between these versions, what
 the problem might be, or even how to troubleshoot the issue?

Some initial thoughts for what could be wrong:

a. You have put your Realm into conf/server.xml instead of into
   your web application's META-INF/context.xml file, and you forgot
   to copy that configuration from 7.0.35 to your new 7.0.59
   install.

b. You have put your Realm into conf/context.xml instead of into
   your web application's META-INF/context.xml file, and you should
   not have done that at all; move the Realm into META-INF/context.xml

c. The configuration you are modifying isn't the one that Tomcat is
   actually using. I find that this happens a lot to people who are
   launching Tomcat from within an IDE like Eclipse, because the IDE
   does odd things with configuration management.

d. You installed your JDBC driver into Tomcat 7.0.35's lib/ directory
   and didn't copy it into Tomcat 7.0.59's lib/ directory, though this
   should have given you errors on startup.

Take a look at those possibilities and let us know what you find.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVAEKTAAoJEBzwKT+lPKRYyHMP/RbZX8neYPrCCGh0lTOQ7PRG
MOXkxFSbQRGsWwV2tyH//Q41IKfSy1Tlb01zbxNklb7gy3h+j+8JgFoYLOjg/iVz
f6XSfw4tUbpTMK/1kqIvpTIMbgi9aK18O+5aLlTdrvAguDZsODgylTi4MTTVZUPZ
v1c+iQbvO8bC7YG81bBm+76rD9pyrMVFbvCPKijfZHTXk5CivaNDwtpysTgDyE65
aG4cHumGSf6JjxSG4cw84OteY6CAYfcNBVDe0/y+F3WKjB6BQ8eHWHEYR57pK+L8
sbxyp6gg5k5Fbrrk/EgEx30CL+rQQfsUkCwKfzlcn3J0fsaE043vnKcNmHA8c6QB
DgC29Bj/o7WkW+hdB7UqB6d0Hq/x+lMZ1JDedEFQFm0IqIxyE3pI6PAX4BHQiWqG
04QB1kRJ32RhYX3+/6Le16FKVxwp2tjuv+xby6gsIGzEY817nIkmRi9SmdR8pGCx
xaxY4uRCNsRrt3fj/nkpygg/ZABueMt+2ix0Nqpe8Wi5T6O8sTRW3jUqj8ZY78+G
rbJZGBEbUuXe5s5o+ZsIfSjKY1U4NTtQhDd+ti8RpkDGy/pcSj2CNyPJ9NLS4E/u
Lb1JdV2nANX4s5r7vWVP1Satzk4DGSx2e93ddy5wDk14vp09d1Fezaq5H8FXUxnc
mzjWDKZT3BY6OqVoN2yj
=b0eg
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Form-based authentication breaks after upgrade to Tom 7.0.59

2015-03-10 Thread rop

We are trying to upgrade Tomcat from 7.0.35 to 7.0.59.

For some reason, the form-based authentication gets broken after the
upgrade,
and just gives Invalid username and/or password, please try again
when trying to login.

Cannot find anything in catalina.out related to this.

From our logging, it appears the DataSourceRealm.authenticate() never gets
called at all.

If I downgrade to 7.0.35, it works again...

Anyone has a clue if anything changed between these versions,
what the problem might be, or even how to troubleshoot the issue?

Re: Passing additional parameters using j_security_check (Form based authentication)

2014-03-26 Thread Neeraj Sinha

On 12 March 2014 20:40, Christopher Schultz ch...@christopherschultz.netwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Neeraj,

 On 3/12/14, 10:47 AM, Neeraj Sinha wrote:
 Thanks. Actually in the realm implementation, I make a call to backend
 authenticate () method which validates various login rules and if any of
 them fails, it returns false and the user is not allowed to login
 (GenericPrincipal object is instantiated with an invalid role) and is
 re-directed to login page. One of the rule is user account locking rule so
 user can not be authenticated successfully unless his/her user account is
 unlocked first so this solution won't work.

 Then you'll have to do your own partial authentication, process the
 reset code, then perform *formal* authentication (using
 request.authenticate()), then forward to wherever users should go
 after they reset their passwords.

 - -chris


   Chris,

   Thanks. What I am doing now is that I am processing the unlock code and
re-directing the request to my login page along with get parameter as
status based on which a message is displayed if the unlock was successful
and further allows user to login. Although the earlier implementation was
not like this but I have seen in couple of applications where this approach
is followed.


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJTIHjsAAoJEBzwKT+lPKRYNo4P/jOQiQWlVFVu51i5KnpBGV5W
 HtjjnpJC6qU5Bu+MNqB2qcBeCJ6lTmlFZQ9fRSjL3CmDfkgBlApIoPebICMdGEoF
 wa9rNJljfkoUtUFpeas91rUwXXPYcKrlXFxelpemCHVu6EfoEVaFQh1s71e/gZrJ
 R5pkKSy4CWJxZ1R4GjuXadry39OvB5cjlnmLz8NpaNa337HrBe8EzsK/hmFBJjGB
 fUKORbxMszctpqzrQyaaRxkPwxw5duz8VaJ8kwimYXsMP4NmiNuX1xN8cDqxzJ2Z
 J23yqq0S9tIHbpGRIg867IHhbtSSyPv6tIihXdPZoNz7YwU9d7t8I0vut5c8kOzw
 JN5/wayIacqJTMuOHdwRr+n6RMw+RDgDMnlAXI/caUbXabCbdORDoo1CQlTs3wVv
 HeR0skCsRx2qDEnrLpnxrlrFwVbQiHBOpOH2yLi414YXdT203ndkmn9nSzCjOM5X
 uLF0yS2Q3MymFmJxaJrvmZwozf+LsNSUlTeVi+VQT7TSYHpL0CM15aCK+TCoYNtm
 bDsVNXoNKbsljGQzAO5iCPKdkQ845xBpMgl7uCrBA9bZT3hQXj8GcnZyBGyfsTYr
 TfhwzZK7DsA/lWXj3Bue50cv2w7pQUeo2FGjAGqkoYn4jwIIU7YlmnhKyMhSky+x
 OZXFwWvSplgE5F9zLBIP
 =iCrm
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




-- 
Regards,
Neeraj

Re: Passing additional parameters using j_security_check (Form based authentication)

2014-03-12 Thread Neeraj Sinha

Hi Chris,


On 12 March 2014 00:37, Christopher Schultz ch...@christopherschultz.netwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Neeraj,

 On 3/8/14, 2:06 AM, Neeraj Sinha wrote:
  Chris,
 
  On 7 March 2014 21:43, Christopher Schultz
  ch...@christopherschultz.netwrote:
 
  Neeraj,
 
  On 3/6/14, 4:34 AM, Neeraj Sinha wrote:
  I have a jsp application and my tomcat version is 7.0.34.
  Authentication is done using *Form based authentication.*
 
  My requirement is as follows:
 
  When user's account gets locked, he has to send a unlock
  request and he gets a link in his registered email id
  clicking on which takes him to unlocking page(let's say
  *unlock.jsp*) which has 3 fields namely*username*, *password*
  and *unlock_code* and a submit button. After submission, once
  unlocked successfully the user should land to home page of
  the application.

 How are you checking the username and password? If you are letting
 Tomcat check that, you could make unlock.jsp protected so that the URL
 points to https:///unlock.jsp?code=[unlock_code]. After
 authentication, Tomcat will redirect the user to the original URL --
 which will include the unlock code.


 Thanks. Actually in the realm implementation, I make a call to backend
 authenticate () method which validates various login rules and if any of
 them fails, it returns false and the user is not allowed to login
 (GenericPrincipal object is instantiated with an invalid role) and is
 re-directed to login page. One of the rule is user account locking rule so
 user can not be authenticated successfully unless his/her user account is
 unlocked first so this solution won't work.




 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJTH18KAAoJEBzwKT+lPKRYXLQP/AzuccE3pEzq5yF4zCWnAZLf
 VFdzsBJSbIt+C0CJyAffQ7UCRzVEZDJuAFVF12AhRcfdOUbn3N85QLUHPJoWHo0y
 +EbwSc951iRgzeMexp6EgB9DfdltelxCt9gXmAdvpZ91jPAldyVPA6spAdlkUixh
 +hcz9JqVMcILhN0tU35NilqbxYMRRQiserGHXffyRoH5KkWyeACLDrYICLgW8ylg
 2yIPtAkKv+Qr3CRintvGnBHVxf5WCQ76e4vo8dd81PC0Ds/KfNJ5qeSFPnIVND6V
 KmA46lfpxezT0BOFV3OSRzsTDRJ2T7ZeyjPcbSknm+2SqLIhS0L0zLLF9S/4FFr2
 qxIXeZV+AnVqPZBHCNhgCMGoK71recUULRqPcrWPpowgwom/rGyuzyuHD1epADa4
 2Uumcw6DcbK6bhkDTFC+5wzeIFdddVKMP546FL3QeY6OlfnUyR8RE7WjqxXgVDOO
 Opti4wN7CHhEo9CzS4+IAOkJsghqXiiemuZvUgKcAuS5O5DiBiEtuc6uiDpT4H3S
 CaVEvhLX5VrJhD2ZkM2vZQS3v45BTSEmhr5EswE3n9/vknrRV1Vyh+nuyx/RoiIc
 M5id1+Gm/bS/3wVfcVrEyIavgwdj9gK9Lwl0DhexlWq4HCUVqRCsaNBcRR9qY/Tc
 jEU85sGWpjuH1N8vhhLJ
 =HOx2
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




-- 
Regards,
Neeraj

Re: Passing additional parameters using j_security_check (Form based authentication)

2014-03-12 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Neeraj,

On 3/12/14, 10:47 AM, Neeraj Sinha wrote:
Thanks. Actually in the realm implementation, I make a call to backend
authenticate () method which validates various login rules and if any of
them fails, it returns false and the user is not allowed to login
(GenericPrincipal object is instantiated with an invalid role) and is
re-directed to login page. One of the rule is user account locking rule so
user can not be authenticated successfully unless his/her user account is
unlocked first so this solution won't work.

Then you'll have to do your own partial authentication, process the
reset code, then perform *formal* authentication (using
request.authenticate()), then forward to wherever users should go
after they reset their passwords.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTIHjsAAoJEBzwKT+lPKRYNo4P/jOQiQWlVFVu51i5KnpBGV5W
HtjjnpJC6qU5Bu+MNqB2qcBeCJ6lTmlFZQ9fRSjL3CmDfkgBlApIoPebICMdGEoF
wa9rNJljfkoUtUFpeas91rUwXXPYcKrlXFxelpemCHVu6EfoEVaFQh1s71e/gZrJ
R5pkKSy4CWJxZ1R4GjuXadry39OvB5cjlnmLz8NpaNa337HrBe8EzsK/hmFBJjGB
fUKORbxMszctpqzrQyaaRxkPwxw5duz8VaJ8kwimYXsMP4NmiNuX1xN8cDqxzJ2Z
J23yqq0S9tIHbpGRIg867IHhbtSSyPv6tIihXdPZoNz7YwU9d7t8I0vut5c8kOzw
JN5/wayIacqJTMuOHdwRr+n6RMw+RDgDMnlAXI/caUbXabCbdORDoo1CQlTs3wVv
HeR0skCsRx2qDEnrLpnxrlrFwVbQiHBOpOH2yLi414YXdT203ndkmn9nSzCjOM5X
uLF0yS2Q3MymFmJxaJrvmZwozf+LsNSUlTeVi+VQT7TSYHpL0CM15aCK+TCoYNtm
bDsVNXoNKbsljGQzAO5iCPKdkQ845xBpMgl7uCrBA9bZT3hQXj8GcnZyBGyfsTYr
TfhwzZK7DsA/lWXj3Bue50cv2w7pQUeo2FGjAGqkoYn4jwIIU7YlmnhKyMhSky+x
OZXFwWvSplgE5F9zLBIP
=iCrm
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Passing additional parameters using j_security_check (Form based authentication)

2014-03-11 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Neeraj,

On 3/8/14, 2:06 AM, Neeraj Sinha wrote:
 Chris,
 
 On 7 March 2014 21:43, Christopher Schultz
 ch...@christopherschultz.netwrote:
 
 Neeraj,
 
 On 3/6/14, 4:34 AM, Neeraj Sinha wrote:
 I have a jsp application and my tomcat version is 7.0.34. 
 Authentication is done using *Form based authentication.*
 
 My requirement is as follows:
 
 When user's account gets locked, he has to send a unlock
 request and he gets a link in his registered email id
 clicking on which takes him to unlocking page(let's say
 *unlock.jsp*) which has 3 fields namely*username*, *password*
 and *unlock_code* and a submit button. After submission, once
 unlocked successfully the user should land to home page of
 the application.

How are you checking the username and password? If you are letting
Tomcat check that, you could make unlock.jsp protected so that the URL
points to https:///unlock.jsp?code=[unlock_code]. After
authentication, Tomcat will redirect the user to the original URL --
which will include the unlock code.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTH18KAAoJEBzwKT+lPKRYXLQP/AzuccE3pEzq5yF4zCWnAZLf
VFdzsBJSbIt+C0CJyAffQ7UCRzVEZDJuAFVF12AhRcfdOUbn3N85QLUHPJoWHo0y
+EbwSc951iRgzeMexp6EgB9DfdltelxCt9gXmAdvpZ91jPAldyVPA6spAdlkUixh
+hcz9JqVMcILhN0tU35NilqbxYMRRQiserGHXffyRoH5KkWyeACLDrYICLgW8ylg
2yIPtAkKv+Qr3CRintvGnBHVxf5WCQ76e4vo8dd81PC0Ds/KfNJ5qeSFPnIVND6V
KmA46lfpxezT0BOFV3OSRzsTDRJ2T7ZeyjPcbSknm+2SqLIhS0L0zLLF9S/4FFr2
qxIXeZV+AnVqPZBHCNhgCMGoK71recUULRqPcrWPpowgwom/rGyuzyuHD1epADa4
2Uumcw6DcbK6bhkDTFC+5wzeIFdddVKMP546FL3QeY6OlfnUyR8RE7WjqxXgVDOO
Opti4wN7CHhEo9CzS4+IAOkJsghqXiiemuZvUgKcAuS5O5DiBiEtuc6uiDpT4H3S
CaVEvhLX5VrJhD2ZkM2vZQS3v45BTSEmhr5EswE3n9/vknrRV1Vyh+nuyx/RoiIc
M5id1+Gm/bS/3wVfcVrEyIavgwdj9gK9Lwl0DhexlWq4HCUVqRCsaNBcRR9qY/Tc
jEU85sGWpjuH1N8vhhLJ
=HOx2
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Passing additional parameters using j_security_check (Form based authentication)

2014-03-07 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Neeraj,

On 3/6/14, 4:34 AM, Neeraj Sinha wrote:
 I have a jsp application and my tomcat version is 7.0.34.
 Authentication is done using *Form based authentication.*
 
 My requirement is as follows:
 
 When user's account gets locked, he has to send a unlock request
 and he gets a link in his registered email id clicking on which
 takes him to unlocking page(let's say *unlock.jsp*) which has 3
 fields namely*username*, *password* and *unlock_code* and a submit
 button. After submission, once unlocked successfully the user
 should land to home page of the application.
 
 Just to let you know, the main login page of the application is 
 *login.jsp* which is configured in *web.xml *and it is called
 whenever any protected resource is requested. It has username and
 password fields and it's action is *j_security_check*.
 
 Now my problem is how to pass unlock_code, the 3rd parameter of
 *unlock.jsp* to *FormAuthenticator *using the action
 *j_security_check*?
 
 I have implementations of *authenticate* method in *LockOutRealm*
 where I would have liked to first check if unlock_code is not null
 and then if yes then would have called backend service to unlock
 the user first(which would have also checked the password matching
 part) and then would have made a call to instantiate
 *UserPrincipal*. I have the implementation of *getPrincipal* method
 in another custom realm.
 
 Is there anyway to pass other parameters apart from username and
 password to
 *FormAuthenticator*(org.apache.catalina.authenticator.FormAuthenticator)?

  Quick help/Any reference related to this scenario would be
 appreciated.

This is not possible using Tomcat's built-in authenticators.

This is something that is possible using securityfilter (a separate,
open-source product you can find here:
http://securityfilter.sourceforge.net/)

It's a bit out of date but it works quite well. You can handle
drive-by logins (those without an initial request to a protected page)
and you can allow pass-through request parameters that will be sent-on
to the post-login page as you are requesting.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTGfAnAAoJEBzwKT+lPKRYk54QAKEM5C7qdy8ClEabhE3JmUIY
B/7N6cABjoSXM41NutlxPKydlS09rTaYwKsDjb79m+K5RwH2r0Czd71DIZ6gyLxK
X1UTrpxttZaiD/X83mngT4aYj+Rna/3zpJDLSXkdG3Ey0Od8SL8WAQEFP81VRD9x
xHos3FHca/NzrzPvVx4Vm49OhItntAHjOxQce788r6HGDLvYMbbOH/s8M0nFel2v
zd5YckVk/pxuGnVPBoXCLKjHw1CyOVZPlSCmjzBOgQWvfaTZtSCkU3CrF1EY5kdj
i9wl/QEgWZYDSTxD8YFHe1ciZXsGGtNc2lo+6pvm7jJ9fpnTZ71oIj7PB0atpv0O
79iTzHjnDx1TNM3TTrsCqGy9vFG7X3+F2hCwo9a/C8F1hdVgQvMdt/3ICMh4PWT7
+r5ZcikBW+SgW3RWepaE2WLEmlXicWsuyTp5oMu3lcczjxw0terXItjH5vB26ahE
04aw9VIOwxX1JMvvIKXDDirZZ4J6ngcZcvxBMEG5p1J1CVm0lnt/8DteNDolxhpk
PVSm3I8j/CsRRoQDqEJn7kAti1tgnC85Noh+XEVyjdkPsAau4xr5dZR4fPc00Qby
b3/B08nCHAKfywM67ZUiJS0F2AA+n7IW+Mufs1ClM1qUkjD8xtjadtbijeiD/1xa
yhv59uhy1sYcBs7PmYan
=XzKe
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Passing additional parameters using j_security_check (Form based authentication)

2014-03-07 Thread Neeraj Sinha

Chris,

On 7 March 2014 21:43, Christopher Schultz ch...@christopherschultz.netwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Neeraj,

 On 3/6/14, 4:34 AM, Neeraj Sinha wrote:
  I have a jsp application and my tomcat version is 7.0.34.
  Authentication is done using *Form based authentication.*
 
  My requirement is as follows:
 
  When user's account gets locked, he has to send a unlock request
  and he gets a link in his registered email id clicking on which
  takes him to unlocking page(let's say *unlock.jsp*) which has 3
  fields namely*username*, *password* and *unlock_code* and a submit
  button. After submission, once unlocked successfully the user
  should land to home page of the application.
 
  Just to let you know, the main login page of the application is
  *login.jsp* which is configured in *web.xml *and it is called
  whenever any protected resource is requested. It has username and
  password fields and it's action is *j_security_check*.
 
  Now my problem is how to pass unlock_code, the 3rd parameter of
  *unlock.jsp* to *FormAuthenticator *using the action
  *j_security_check*?
 
  I have implementations of *authenticate* method in *LockOutRealm*
  where I would have liked to first check if unlock_code is not null
  and then if yes then would have called backend service to unlock
  the user first(which would have also checked the password matching
  part) and then would have made a call to instantiate
  *UserPrincipal*. I have the implementation of *getPrincipal* method
  in another custom realm.
 
  Is there anyway to pass other parameters apart from username and
  password to
  *FormAuthenticator*(org.apache.catalina.authenticator.FormAuthenticator)?
 
   Quick help/Any reference related to this scenario would be
  appreciated.

 This is not possible using Tomcat's built-in authenticators.

 This is something that is possible using securityfilter (a separate,
 open-source product you can find here:
 http://securityfilter.sourceforge.net/)

 It's a bit out of date but it works quite well. You can handle
 drive-by logins (those without an initial request to a protected page)
 and you can allow pass-through request parameters that will be sent-on
 to the post-login page as you are requesting.

 - -chris


  Thanks. Actually I knew about the Securityfilter but probably it doesn't
support single sign-on several web application contexts. I need
  to have single sign-on feature as well.

  - - Neeraj


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJTGfAnAAoJEBzwKT+lPKRYk54QAKEM5C7qdy8ClEabhE3JmUIY
 B/7N6cABjoSXM41NutlxPKydlS09rTaYwKsDjb79m+K5RwH2r0Czd71DIZ6gyLxK
 X1UTrpxttZaiD/X83mngT4aYj+Rna/3zpJDLSXkdG3Ey0Od8SL8WAQEFP81VRD9x
 xHos3FHca/NzrzPvVx4Vm49OhItntAHjOxQce788r6HGDLvYMbbOH/s8M0nFel2v
 zd5YckVk/pxuGnVPBoXCLKjHw1CyOVZPlSCmjzBOgQWvfaTZtSCkU3CrF1EY5kdj
 i9wl/QEgWZYDSTxD8YFHe1ciZXsGGtNc2lo+6pvm7jJ9fpnTZ71oIj7PB0atpv0O
 79iTzHjnDx1TNM3TTrsCqGy9vFG7X3+F2hCwo9a/C8F1hdVgQvMdt/3ICMh4PWT7
 +r5ZcikBW+SgW3RWepaE2WLEmlXicWsuyTp5oMu3lcczjxw0terXItjH5vB26ahE
 04aw9VIOwxX1JMvvIKXDDirZZ4J6ngcZcvxBMEG5p1J1CVm0lnt/8DteNDolxhpk
 PVSm3I8j/CsRRoQDqEJn7kAti1tgnC85Noh+XEVyjdkPsAau4xr5dZR4fPc00Qby
 b3/B08nCHAKfywM67ZUiJS0F2AA+n7IW+Mufs1ClM1qUkjD8xtjadtbijeiD/1xa
 yhv59uhy1sYcBs7PmYan
 =XzKe
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Passing additional parameters using j_security_check (Form based authentication)

2014-03-06 Thread Neeraj Sinha

I have a jsp application and my tomcat version is 7.0.34. Authentication is
done using *Form based authentication.*

My requirement is as follows:

When user's account gets locked, he has to send a unlock request and he
gets a link in his registered email id clicking on which takes him to
unlocking page(let's say *unlock.jsp*) which has 3 fields namely*username*,
*password* and *unlock_code* and a submit button. After submission, once
unlocked successfully the user should land to home page of the application.

Just to let you know, the main login page of the application is
*login.jsp* which
is configured in *web.xml *and it is called whenever any protected resource
is requested. It has username and password fields and it's action is
*j_security_check*.

Now my problem is how to pass unlock_code, the 3rd parameter of *unlock.jsp*
 to *FormAuthenticator *using the action *j_security_check*?

I have implementations of *authenticate* method in *LockOutRealm* where I
would have liked to first check if unlock_code is not null and then if yes
then would have called backend service to unlock the user first(which would
have also checked the password matching part) and then would have made a
call to instantiate *UserPrincipal*. I have the implementation of
*getPrincipal* method in another custom realm.

Is there anyway to pass other parameters apart from username and password
to *FormAuthenticator*(org.apache.catalina.authenticator.FormAuthenticator)?

Quick help/Any reference related to this scenario would be appreciated.

Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials

2013-07-02 Thread Shanti Suresh

Greetings,


On Wed, Jun 26, 2013 at 4:08 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 André,



  But, even when sending UTF-8 encoded data according to this
  principle, they are *not* indicating that it is UTF-8 data, which
  is basically wrong, because the standard HTTP/HTML character set is
  iso-8859-1, and they *should* indicate it when that is not what
  they are sending.  But that is the reality.

 No, as much as it pains me to do so, I agree with with Mozilla folks
 on this one: adding a charset attribute to an
 application/x-form-urlencoded Content-Type violates the spec. There is
 no good solution.
 ...



  We really need an RFC for HTTP 2.0, with UTF-8 as the default
  charset/encoding.

 +1

 Maybe they can clear-up Tomcat logging configuration while they are at
 it :)


Thank you!  This discussion was quite informational.


-Shanti

Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials

2013-07-02 Thread André Warnier


Shanti Suresh wrote:

Greetings,


On Wed, Jun 26, 2013 at 4:08 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,




But, even when sending UTF-8 encoded data according to this
principle, they are *not* indicating that it is UTF-8 data, which
is basically wrong, because the standard HTTP/HTML character set is
iso-8859-1, and they *should* indicate it when that is not what
they are sending.  But that is the reality.

No, as much as it pains me to do so, I agree with with Mozilla folks
on this one: adding a charset attribute to an
application/x-form-urlencoded Content-Type violates the spec. There is
no good solution.
...





We really need an RFC for HTTP 2.0, with UTF-8 as the default
charset/encoding.

+1

Maybe they can clear-up Tomcat logging configuration while they are at
it :)



Thank you!  This discussion was quite informational.



You are welcome.

Further as relatively [OT], in some other - non-Tomcat, non-Java - applications, we solve 
the general issue as follows (taking into account the deficiencies of the RFCs, the 
servers, the browsers, and the users) :
- when programmers create the html documents containing the forms, they must make sure 
that they use a tool which really saves the html document in the charset/encoding that 
corresponds to their wishes

- the html page should contain a declaration like :
meta http-equiv=Content-Type content=text/html; charset=x /
(where  is the correct charset/encoding, like UTF-8)
- each form that is sent to the browser is sent by the server with an explicit HTTP header 
: Content-type: text/html; charset=

(that normally happens automatically, but you should nevertheless check that it 
matches)
- the form tag of the form should contain the accept-charset attribute with the 
expected character set as value, like

form accept-charset=UTF-8 ...
- the form itself contains a hidden parameter like :
input type=hidden name=charset-test value=y
(where y is a character sequence which is so that, seen as bytes, its length would be 
different depending on the real character set used. E.g., for Europe, ÖöÜüÄä)
- the application which receives the form submit data, must first check if the string 
received for the charset-test parameter matches its expectations.
In other words, if the application expects UTF-8, then it should check that the received 
string has a byte length of 12 and a character length of 6, and matches a Unicode string 
ÖöÜüÄä)
And if it doesn't, then it should take appropriate action (abort the action, or try 
another charset)
(if the form sent by the server contains additional data coming from a back-end database 
system, then one should also check that the charset of that data matches the one of the 
form of course).


This may look a bit like overkill, but it is the result of long and painful real-world 
experience with multi-lingual applications used with multiple browsers and multiple types 
of users in multiple countries doing cut-and-paste of all kinds of stuff into forms.






-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: FORM based authentication and utf-8 encoding of credentials

2013-06-26 Thread Jan Vávra

Hello,

When I create user with password with czech String ŽežUlička.1 the
browser sends correctly this string as:

POST http://localhost:70/myapp/j_security_check HTTP/1.1
Content-Type: application/x-www-form-urlencoded

j_username=pj_password=%C5%BDe%C5%BEUli%C4%8Dka.1

The browser is not sending that correctly. The password is UTF-8 encoded
but the Content-Type fails to specify the character set used. It it did,
Tomcat would treat the password as UTF-8.

This is a common failing of browsers and is covered in the FAQ. [1]
Well I have tried IE, Firefox, Chrome. None of them is appending
charset in Content-Type.

I have manually modified the request header to:
Content-Type: application/x-www-form-urlencoded; charset=utf-8
and Tomcat gives me the letters in the correct form. Ok, good to know.

Any idea how to tell tomcat to use utf-8 in form based authentication?
It's tomcat 7.0.34 on Czech Windows 7 32 bit with default ansi code page
set as Windows-1250.

Authentication is tricky because the processing happens before any user
code runs. The best / only option is to set the characterEncoding
attribute for the Authenticator [2] to UTF-8 and hope that the browsers
are consistent in their failing to follow the specification and use
whatever encoding the page is encoded with.

HTH,

Mark

[1] http://wiki.apache.org/tomcat/FAQ/CharacterEncoding
[2]
http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Form_Authenticator_Valve/Attributes

As you have referred in [2] I have added to my app's context xml
Valve className=org.apache.catalina.authenticator.FormAuthenticator
characterEncoding=utf-8/

and Czech letters are in the correct form. This is a solution.

Thanks for an advice.
Jan.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials

2013-06-26 Thread André Warnier

Jan Vávra wrote:

Hello,

When I create user with password with czech String ŽežUlička.1 the
browser sends correctly this string as:

POST http://localhost:70/myapp/j_security_check HTTP/1.1
Content-Type: application/x-www-form-urlencoded

j_username=pj_password=%C5%BDe%C5%BEUli%C4%8Dka.1

The browser is not sending that correctly. The password is UTF-8 encoded
but the Content-Type fails to specify the character set used. It it did,
Tomcat would treat the password as UTF-8.

This is a common failing of browsers and is covered in the FAQ. [1]
Well I have tried IE, Firefox, Chrome. None of them is appending
charset in Content-Type.

I have manually modified the request header to:
Content-Type: application/x-www-form-urlencoded; charset=utf-8
and Tomcat gives me the letters in the correct form. Ok, good to know.

Any idea how to tell tomcat to use utf-8 in form based authentication?
It's tomcat 7.0.34 on Czech Windows 7 32 bit with default ansi code
page

set as Windows-1250.

HTH,

Mark

[1] http://wiki.apache.org/tomcat/FAQ/CharacterEncoding
[2]
http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Form_Authenticator_Valve/Attributes

As you have referred in [2] I have added to my app's context xml
Valve className=org.apache.catalina.authenticator.FormAuthenticator
characterEncoding=utf-8/

and Czech letters are in the correct form. This is a solution.

Thanks for an advice.

By the way, referring to this basic failing of browsers : this is something that is
clearly contrary to the specs, yet since years all major browsers have consistently
ignored this issue.
This failure of adding the character set/encoding to HTTP POST's is causing problems in
multi-lingual web applications, and by itself forcing multiple workarounds which
themselves are per force inconsistent.

Does anyone have an idea why browsers keep on ignoring this issue, version
after version ?

(I would imagine that Apache httpd and Tomcat devs must have regular contacts with
whomever develop browsers, so did anyone ever ask ?)

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: FORM based authentication and utf-8 encoding of credentials

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jan,

On 6/26/13 7:14 AM, Jan Vávra wrote:
 Hello,
 When I create user with password with czech String
 ŽežUlička.1 the browser sends correctly this string as:
 
 POST http://localhost:70/myapp/j_security_check HTTP/1.1 
 Content-Type: application/x-www-form-urlencoded
 
 j_username=pj_password=%C5%BDe%C5%BEUli%C4%8Dka.1
 The browser is not sending that correctly. The password is UTF-8
 encoded but the Content-Type fails to specify the character set
 used. It it did, Tomcat would treat the password as UTF-8.
 
 This is a common failing of browsers and is covered in the FAQ.
 [1]
 Well I have tried IE, Firefox, Chrome. None of them is appending 
 charset in Content-Type.

Again, this is a common failing of browsers and is covered in the FAQ.

 I have manually modified the request header to: Content-Type:
 application/x-www-form-urlencoded; charset=utf-8 and Tomcat gives
 me the letters in the correct form. Ok, good to know.

Did you read the FAQ? There are suggestions for fixing this issue. The
CharacterEncodingFilter (/without/ the force option enabled) IMO is
the most appropriate.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRyvEQAAoJEBzwKT+lPKRYTfsP/0Hru8ofkSxJW2TsgIL17y23
LgTEyINmWuijJK7SEzqk8ZXsjDKCyVxHECKGvrvQdp0/NHhnE7Vey856G2+C1568
ym/+ZOxJTbCcmvMsNbbp5WIb/j55waZQJhLS0DwVQHEfGxLM4C3hykV5R+NQuBSW
smOa69S1yk66+moq4eHypWi6CH+e0TTaIwA8TDOtACREQphWdguKXGsgAX0hswK2
H6kh/+jpLdHKvU5CbyMsBqe912AFMD9E/hHmgiwEWAe/9+eTsHOlfV7EVJ8Vy7DW
QoHHGYjADAcwapUijSMtckPpPeX9dt1XDJ5KQ+D2dojWgWUgN7+SbiTD1tmIjM+b
KeQad/DeHsm+rZw9IQCQZkBaDJXlLYdBdn/pCLVcahh8QbYijThimdIA1V7kVVsp
8stYl27exDQHDZB2kr8pP+hykJIJIl+JGy6shhLYrGCv1jMCGbZha4/tS8/5Ccqz
gWLJiyMmP7VkROgd1v1Pet8i+AuuZcs/nHFVQ2NUf4Tntz0/c0+fDJlCFStKBKaG
uwA4FlC7PnOt3KuGf0TpbM8Ri60KRBaJ8QYGkDjx7mqT2leHzcUWNxFgulSXcQbx
npoHsPRO+nEhxyqYfgozxNoOqUeZWgguG/5cCLemkYKZRDWylLekqdcd7Yd2RdBQ
UabVUNZBgChB3kyiWlMR
=gr3S
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 6/26/13 8:01 AM, André Warnier wrote:
 Jan Vávra wrote:
 Hello,
 When I create user with password with czech String
 ŽežUlička.1 the browser sends correctly this string as:
 
 POST http://localhost:70/myapp/j_security_check HTTP/1.1 
 Content-Type: application/x-www-form-urlencoded
 
 j_username=pj_password=%C5%BDe%C5%BEUli%C4%8Dka.1
 The browser is not sending that correctly. The password is
 UTF-8 encoded but the Content-Type fails to specify the
 character set used. It it did, Tomcat would treat the password
 as UTF-8.
 
 This is a common failing of browsers and is covered in the FAQ.
 [1]
 Well I have tried IE, Firefox, Chrome. None of them is appending 
 charset in Content-Type. I have manually modified the request
 header to: Content-Type: application/x-www-form-urlencoded;
 charset=utf-8 and Tomcat gives me the letters in the correct
 form. Ok, good to know.
 
 
 Any idea how to tell tomcat to use utf-8 in form based
 authentication? It's tomcat 7.0.34 on Czech Windows 7 32
 bit with default ansi code page set as Windows-1250.
 Authentication is tricky because the processing happens before
 any user code runs. The best / only option is to set the
 characterEncoding attribute for the Authenticator [2] to UTF-8
 and hope that the browsers are consistent in their failing to
 follow the specification and use whatever encoding the page is
 encoded with.
 
 HTH,
 
 Mark
 
 
 [1] http://wiki.apache.org/tomcat/FAQ/CharacterEncoding [2] 
 http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Form_Authenticator_Valve/Attributes



 
As you have referred in [2] I have added to my app's context xml
 Valve
 className=org.apache.catalina.authenticator.FormAuthenticator 
 characterEncoding=utf-8/ and Czech letters are in the correct
 form. This is a solution.
 
 Thanks for an advice.
 
 By the way, referring to this basic failing of browsers : this is 
 something that is clearly contrary to the specs, yet since years
 all major browsers have consistently ignored this issue. This
 failure of adding the character set/encoding to HTTP POST's is 
 causing problems in multi-lingual web applications, and by itself 
 forcing multiple workarounds which themselves are per force
 inconsistent. Does anyone have an idea why browsers keep on
 ignoring this issue, version after version ?
 
 (I would imagine that Apache httpd and Tomcat devs must have
 regular contacts with whomever develop browsers, so did anyone ever
 ask ?)

Here's the long-standing bug in Mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=241540

...and one referenced from it with better spec-research:
https://bugzilla.mozilla.org/show_bug.cgi?id=289060#c8

The bottom line is two specific items:
1. Content-Type should only have a charset attribute for text/ types
2. Adding charset to Content-Type for application/x-form-urlencoded
has broken some stuff in the past, so Mozilla has chosen not to
re-enable it

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRyvNoAAoJEBzwKT+lPKRYlucQAJVVLDiXE03vtrmTp6hjpgGQ
G9PBDZiPapLjRRqtfzfZ1Wz6koOB5kfZJngopt2xP+Ha9H7rGHCfcCYW3tIk5WNi
9c+6G/9Mzx54NCpIYLklx4AZZH8FG/egMmgTsdnAQ9P+Z9DBzPX9luD0DTaXf9dE
aDOPG0aSNMPl9Q4VXhFLV22PoEAdDVGDPnglOLRBoLgGzmVYVPNBqcDu8zfDLZKf
ZHBBIhcOUGf5YdJlwhqOSTwqo6Uez0BfkZT126FrYh3y4MNMXVTO9p2cpOHNfGZn
f7Ld1G0V3CB5bcsXIPNRQ53dugt/vOyN9diUaZ1WZwjqUUKjQoNw18qdzsolXpmn
gWsigotQE0Cko7UQzTKsGJRNMPMGlPmKNG3QKG62LNfYQc3ugkeeNJIEDFKcIC5c
1KUaGFdim2/13XXLonbrxF8Fx0k1VTynhqZHmDWsgQbibx/6gPs6HTthLYO/bowW
x26oHAC9o2BQLeJvJediaGwylHfogqOBbjFoHvIgyGYkwNj1Tav9ompHkh3bsHin
OkT3KOuTx36oiZRF5DPhCuRviB8UgbQCvWubkGfIzSnj6QI+vdQbHLMqbL1Y5D7w
TyJIzNZX4alGvfJDNk4Zh58h/MlUuRTkzGtRmNtOjHW4GRiILxuYS/cKsxPG/zvR
euKbE0Lk4BcrOOSu+9h6
=UKAo
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials

2013-06-26 Thread Shanti Suresh

Hi Chris,

This is such an interesting discussion.  I am not sure what to make of this
person's comment:

---
TAXI   2012-10-09 09:03:59 PDT

Wow, no fix since 8 years...

And this is a real bug: If the HTTP header says the file is encoded in
ISO-8859-1 the common way to override this with HTML is:

meta http-equiv=Content-Type content=text/html; charset=utf-8

Firefox reads the body in UTF-8 then, which is fine, but the charset
used in forms is still ISO-8859-1, so you have to add
accept-charset=utf-8 to the form just for firefox (other browser
automatically use UTF-8 or send the charset with the content-type).

So: Why the hell is nobody fixing this bug?
---


So the questions I have are:
(1) Firefox is not properly sending UTF-8 in the POST request even if it
reads the HTML page in UTF-8?  And other browsers are now sending
charset=utf-8 based on the the HTML META tag?
(2) Firefox has started respecting the accept-charset=utf-8 attribute in
forms now such that it adds charset to the Content-Type header of the POST
request?   I'm confused.  I thought Mozilla was not going to fix  this
issue.

Thanks for any clarifications.

   -Shanti

On Wed, Jun 26, 2013 at 9:58 AM, Christopher Schultz

 Here's the long-standing bug in Mozilla:
 https://bugzilla.mozilla.org/show_bug.cgi?id=241540

 ...and one referenced from it with better spec-research:
 https://bugzilla.mozilla.org/show_bug.cgi?id=289060#c8

 The bottom line is two specific items:
 1. Content-Type should only have a charset attribute for text/ types
 2. Adding charset to Content-Type for application/x-form-urlencoded
 has broken some stuff in the past, so Mozilla has chosen not to
 re-enable it

 - -chris

Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials

2013-06-26 Thread André Warnier

Shanti Suresh wrote:

Hi Chris,

This is such an interesting discussion. I am not sure what to make of this
person's comment:

---
TAXI 2012-10-09 09:03:59 PDT

Wow, no fix since 8 years...

And this is a real bug: If the HTTP header says the file is encoded in
ISO-8859-1 the common way to override this with HTML is:

meta http-equiv=Content-Type content=text/html; charset=utf-8

Firefox reads the body in UTF-8 then, which is fine, but the charset
used in forms is still ISO-8859-1, so you have to add
accept-charset=utf-8 to the form just for firefox (other browser
automatically use UTF-8 or send the charset with the content-type).

So: Why the hell is nobody fixing this bug?
---

So the questions I have are:
(1) Firefox is not properly sending UTF-8 in the POST request even if it
reads the HTML page in UTF-8? And other browsers are now sending
charset=utf-8 based on the the HTML META tag?
(2) Firefox has started respecting the accept-charset=utf-8 attribute in
forms now such that it adds charset to the Content-Type header of the POST
request? I'm confused. I thought Mozilla was not going to fix this
issue.

Thanks for any clarifications.

I think that you are still confused.. :-)
(As are, in part, some of the people who posted on that Mozilla bug).

(1) browsers, in general, are *not* sending a charset attribute in their POST
submissions (whether form-url-encoded or multipart).
This is a real pity, because it is the source of much confusion, and the real reason why
servers have to go through loops to figure out (or force) the character set/encoding of
the data that they are getting from browser POSTs.
And the Mozilla people seem to say that it is that way, because when they tried to add
this charset attribute, it broke a number of server applications at the time (8 years
ago), and they see no reason to think that it would not still be the same today, so they
arer not trying it again.

(1a) what browsers *will* do, in general, is to send POST data in the same character
set/encoding as the one of the HTML *page* which contains the form being posted.
But, even when sending UTF-8 encoded data according to this principle, they are *not*
indicating that it is UTF-8 data, which is basically wrong, because the standard HTTP/HTML
character set is iso-8859-1, and they *should* indicate it when that is not what they are
sending. But that is the reality.

(2) the accept-charset attribute of a form does not mean that this form will *send*
data according to that charset/encoding. It indicates that any data that is entered in
the form's input boxes will be interpreted as being in that charset.
So the fact of adding an accept-charset attribute to your form tags does not make it
so that the browser will magically change its behaviour when POSTing data.

In other words, it's a mess, and the mess is mainly due to some lack of precision in the
original RFC's, but it is being perpetuated now by the fear of browser developers of
breaking server applications by doing things right.
Which is rather funny in a way, considering all the things that browser developers do all
the time anyway which do break existing applications.

We really need an RFC for HTTP 2.0, with UTF-8 as the default charset/encoding.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials

2013-06-26 Thread Konstantin Kolinko

2013/6/26 Shanti Suresh sha...@umich.edu:
 Hi Chris,

 This is such an interesting discussion.  I am not sure what to make of this
 person's comment:

 ---
 TAXI   2012-10-09 09:03:59 PDT

 Wow, no fix since 8 years...

 And this is a real bug: If the HTTP header says the file is encoded in
 ISO-8859-1 the common way to override this with HTML is:

 meta http-equiv=Content-Type content=text/html; charset=utf-8

 (...)
 ---

That person is plainly wrong.
You must not use different values in Content-Type HTTP header and in
Content-Type META tag.

1. The HTML spec explicitly says that the HTTP header takes priority.
http://www.w3.org/TR/html401/charset.html#h-5.2.2

2. Actually different browsers behave differently. Some may fall back
to autodetection.
(You may guess what browsers do not follow the specification).

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Shanti,

On 6/26/13 11:00 AM, Shanti Suresh wrote:
 Hi Chris,
 
 This is such an interesting discussion.  I am not sure what to make
 of this person's comment:
 
 --- TAXI   2012-10-09 09:03:59 PDT
 
 Wow, no fix since 8 years...
 
 And this is a real bug: If the HTTP header says the file is encoded
 in ISO-8859-1 the common way to override this with HTML is:
 
 meta http-equiv=Content-Type content=text/html;
 charset=utf-8
 
 Firefox reads the body in UTF-8 then, which is fine, but the
 charset used in forms is still ISO-8859-1, so you have to add 
 accept-charset=utf-8 to the form just for firefox (other browser 
 automatically use UTF-8 or send the charset with the
 content-type).
 
 So: Why the hell is nobody fixing this bug? ---
 
 
 So the questions I have are: (1) Firefox is not properly sending
 UTF-8 in the POST request even if it reads the HTML page in UTF-8? 
 And other browsers are now sending charset=utf-8 based on the the
 HTML META tag?

This is just a convention: it's not defined by the spec. One could
argue that META should override HEADER, but the spec says the
opposite, actually.

 (2) Firefox has started respecting the accept-charset=utf-8
 attribute in forms now such that it adds charset to the
 Content-Type header of the POST request?   I'm confused.  I thought
 Mozilla was not going to fix  this issue.

No, browsers will use accept-charset as the charset they use to encode
the POST request. The will still not likely add the charset attribute
to the Content-Type header, because the spec says not to do so.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRy0i2AAoJEBzwKT+lPKRYUfEQAKpBWbhF6sDKY1uA6v7HgqQ3
eRbANUtnknEPiOscJqjMcW8ZWdKJl1mucvKigPNXwJMYpTe3Q/c3r8RjVLV9TqtC
jgtWwxlS/GF3W8gO9BuLKva59dTbQtE+xyG12nNCJyxMHPow7WJWUIo4KVB4t0IB
vCTXwQT65DxMXZGwRMoc6eFI9idu5M0t1Luj+wnf5PxqV338WoZDx4N7QrSKS3Cj
z8S1OeA6uEqPHjSotl4Y7jgRBSSutP4AOwdnFjhBU81JWIZOl5+oaIemFcZgTcwm
0ZlcKThYud+BcH10mPv3nCieUSj1LHo6deEcCYMoNi3sEfSKlfvCW3XsQJI2T7xk
3jj+OplKqhYd8oMhg3sy7M2D25IenG0LJxnCADZutVhQ7U+qO3xKMeovymffNeXn
rLOLlxliUiZ0EhPpQSqbtloAOvO/klyECdZlHlILSkFFtMmiQf6yDYtXQLAQfgqK
o4/OAD9M7IqMLITmF4sUdt1fXfBjU7g/02tqmJWOP479XWbvqYHESG81XD6dR+PR
mFQu+gpIMAZJpIGcVWwMKvG7hMKP9jeNRBp+w5yOBj2BPg9s8Z6vBaonXVMAFN5c
VPzows5r1tx6YqKJkfEVpbswzRU4rx8HJHZUpYYBDpUhRztCQhcsFqKRj0d754cV
l9hb19ydVgu1Iz0ztsFZ
=MUYp
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials