Re: HTTP 400 with Form based authentication

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sreyan,

On 8/31/15 3:16 PM, Sreyan Chakravarty wrote:
> Well Christopher thanks for that eye opener. I didn't know that the
> specs were so inconsistent.

They aren't inconsistent... it's just that they don't cover a popular
use case. Remember that container-managed authentication has to cover
 types of authentication other than "FORM".

The client can't, for instance, force HTTP Basic credentials into a
server without knowing what the server's "realm" is for HTTP Basic.
The server won't ask for authentication unless it's necessary, and
authentication isn't necessary unless the user tries to access a
protected resource.

The same is true for SSL client certificates. When you consider all
the types of authentication that the servlet spec covers, it makes
more sense why the authentication is done the way it is. (It doesn't
make it any less irritating, though.)

> Okay now regarding your comment-:
> 
> "Servlet 3.0 added the HttpServletRequest.login() method would
> improved the situation greatly: you can implement your own login
> handler that plugs-into the authentication services of the
> container. It's just that the container doesn't handle any
> redirection to a login page (none is required) or credential
> capturing (easily done with a servlet)."

(Note that the word "would" should have been "which has" above.)

> How do you implement your own login handler and how do you plug
> that into Tomcat Auth services.
> 
> Can you provide some info as to how I would do that ?

You write your own servlet and point your "main" login at it:

<form action="/path/to/my/login/servlet">
  <input type="text" name="username" />
  <input type="password" name="password" />
  <input type="submit" />
</form>

public class MyLoginServlet extends HttpServlet {
  public void doPost(HttpServletRequest req, HttpServletResponse rsp) {
    request.login(req.getParameter("username"),
                  req.getParameter("password"));
  }
}

It's up to you to decide what else should happen after authentication
succeeds. This hooks-into the container's authentication system by
using whatever Realm has been defined to actually do the
authentication (e.g. DataSourceRealm) and will also use the
CredentialHandlers we've been discussing.

> And what is the extension to FORM Authenticator that Mark is
> talking about ?

Check out the documentation for the FORM Authenticator and you'll see
that you don't actually need to write your own servlet like the above
if all you want to do is allow drive-by logins and always forward to
the same URI:

http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Form_Authentic
ator_Valve

Unfortunately, that feature is buried in the configuration reference
for the FormAuthenticatorValve and not somewhere more easily
accessible like under "Realms and AAA" for example.

> Also correct me if I am wrong, then the page that I use to login
> and the page that will contain j_security_check as an action must
> be two different pages.

If you use the form/servlet I outlined above, then yes: your "main"
login page should be separate from the one you use for Tomcat's
automated authentication. Of course, you can page a single
parameterized page or a complex series of JSPs that include each other
to avoid duplication, or you can just make two pages.

If you use Mark's technique to configure the FormAuthenticationValve,
then you can use a single form for everything. I would highly
recommend simply using the FormAuthenticationValve configuration
because you have to do a whole lot less work.

> Also can I have two <login-config> elements in my web.xml ?

Nope. How would the container know when to pick one over the other?

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

iQIcBAEBCAAGBQJV5c4wAAoJEBzwKT+lPKRYX08QAJKuEE9N2ifMuZp2uOtXNkDz
VNPZBnZonXfqI/MKjYlhn2ox9IHpTOZ6sYVGaMgBKYV4ILHPN4kOvSHi3ud/azDh
igSpSEYJ52vcK1EAoYgr1f56hyUjSTZhxbQlNuf0cIfyF/nNLUB/fz9x5VMDUPEY
s8KH3UZ62OR5UI6rcwWE/QfnyneHyWoDqp0s831DxMRkH90XdzGGHn4xaICUK68f
fdZPJmQslgm6rdyh/MuVA/NVS9IGADEF4hlD7TbyGhl8sOupSv51pjivl594hjhX
znYT/wE8iO+sNft2oPb9A5LUWDS2le9dfA4S0zrA9TVsWFQvnUOs3dNkgEIW7aYO
fba0F9wUqRY0hUfoqiQ+mvCaBQP8a6P2YDy9P9PnShwxOTo6grd8UAXGYvsxyaae
D/TZkak1mSkYT/7HQ14OwXhDjtK00GflQ3I+p/qYAO7xCxeWJvfcxWp7y19Zc+8B
Zc3Vz+NQhneJHeltp6V0xK2xfamGrFCrpcuDMIpyu3Szi/15shpJaPTYWAuam8Pk
4Ld8OC0MCB5C7mgu58bJuKm54cr2GJgBlcgsfG6XwUkn3oeCAZDFBuqNoR7YMyQ6
e8gzUYvAwpb1IsNO1mELJIUKY8N+NDCdNnvjQ05X3rUsBhPS0tg6b3USdvs+TDIG
vb/DhPr4hguee6nFoX7Y
=iT9j
-----END PGP SIGNATURE-----

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