I did what you said. That is pointing the web browser to a protected
resource without authentication and then logging in. It works perfectly IF
AND ONLY IF the credentials are ABSOLUTELY correct. Otherwise I am getting
undefined behavior an thats where I need your help now.
First-: If I provide an invalid user-id and valid/invalid password I am
getting the following error-:
HTTP Status 500 -
java.lang.NullPointerException
org.apache.catalina.realm.DigestCredentialHandlerBase.matchesSaltIterationsEncoded(DigestCredentialHandlerBase.java:147)
org.apache.catalina.realm.SecretKeyCredentialHandler.matches(SecretKeyCredentialHandler.java:73)
org.apache.catalina.realm.DataSourceRealm.authenticate(DataSourceRealm.java:297)
org.apache.catalina.realm.DataSourceRealm.authenticate(DataSourceRealm.java:267)
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:272)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:452)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:537)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1085)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1556)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1513)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Thread.java:745)
Now I thought that when invalid credentials of any kind are given Tomcat is
supposed to take you to the <form-error-page>. Then why is it I am getting
a 500 error. Clearly something is wrong from my side or else the
<form-error-page>
is invoked under different circumstances.
Secondly-: If I provide a valid user-id and invalid password I am again not
redirected to the form-error-page I am kept in j_security_check. How do I
show the user that is credentials are wrong ?
Also can I webapp have different realms ? If so how do you distinguish them
? I was looking at the RealmBase source and I haven't noticed a place for
realmName. If not then what is the use of the <realmName> element in
web.xml ?
The example that you have provided -:
request.login(req.getParameter("username"),
req.getParameter("password"));
Which realm would it use if there were multiple realms available ?
Thanks for your patience in helping me Christopher.
Regards
Sreyan Chakravarty
On Tue, Sep 1, 2015 at 9:44 PM, Christopher Schultz <
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 <Context> element you should already have.
>
> > Any documentation for this ?
>
> Just what you have already read:
>
> <Context>
> <Valve className="name.of.valve.class"
> ... other configuration attributes ...
> />
> </Context>
>
> - -chris
>
> > On Tue, Sep 1, 2015 at 12:46 AM, Sreyan Chakravarty <
> > sreyan.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 <login-config> 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
> > <form-login> like <default-landing-page> or something like that,
> > so that if you try to login with j_security_check and you hadn't
> > already requested a protected resource, the container knows where
> > to send the user after authentication.
> >
> > -chris
> >>>
> >>> --------------------------------------------------------------------
> - -
> >>>
> >>>
> To unsubscribe, e-mail: users-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
> 9mBEPCqYTwj6ZznSX5nXbujllNTdtSJNfZUfuCLRgV+fzEhfYuDflnptIPDMjg/9
> HH1WCozm/sAvLh/z3Gn0uPpALhTzT0b4rHlH8rksJqZlQ/0vaEO14HQgvhe3/DbM
> DCo8MCU/QTq7CILd1eB1l4kfiIDkc4XFUxYkdnUWCwvLelWWRMUB3Zd5B9gYefdK
> iJ3ivzwwd5GJURb/S+KAucJCHaN6gIkLE3z3IIb/Q/LUsc1AT+8mdwCMeExsr7N2
> 5wg9B64SviroD3Ab86lL/8MVan525YGuM/h4xUjn5v90Nv7Bm+9jZBCA3M1/FzbW
> XrrH5lFs/E4LJKOCGbM8sLNUbsYoa6nN1WI3XHovJkgnKnaVhA24MmEE0dN1GvDf
> P3TvUkHPDy2+b6MfN/x9
> =FCGh
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
