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 <login-config> 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 >> <form-login> like <default-landing-page> or something like that, so >> that if you try to login with j_security_check and you hadn't already >> requested a protected resource, the container knows where to send the >> user after authentication. >> >> - -chris >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - http://gpgtools.org >> >> iQIcBAEBCAAGBQJV5JOeAAoJEBzwKT+lPKRYwSgQAJAARzjHnDqMXY9QexbBpyrZ >> DSZSxqCRljdHtnEEuBjlLfT8FRUATIU3g0rHZ99SQSXhgYojfvCZ7WalO3izxu6o >> NvmbptcCo/rASOvVqtVYpTu1ONhSgGu/v0fZ7maZksMlb0yXUSHpM5EeUucU92NK >> AEnZElXlV+6yf2arN9R5L80lZHxioF5tUkS1RoqYsBr3+1KuS1DzfVVO2NKzPLiK >> L03QVRCGdDtln66m6lrbPNjgzhMK3HvqMiHAPuED5sTMAha8uk5HTZfM855ojuY4 >> x8whD7X/6JjTemLue1pzd1CfSGx+EDxrgxgOscFyA4PK0zy8vQWnsnb5MAjKtvdw >> +8oHg445RDoYG6BYJ1ZXbTmft9APN37PCeyxzKcGEv0sEzj4q5XRIr8oNiXi74mf >> 8CQ1QsFv6tlMHysLk/3Tj53AwscZ59xnovjH5lUJqGDi8v6uIojhCOAwzG5UBQF0 >> JHq6Nd295a3Qp9XTj0WCyDJ6gHyDlzNMivI/dJzkaHOSeyML/hSfYSKKEL1vaOOO >> OECSLWqCWiXztOCNCbHvT5YINSmzqV1hdqoPEdSQyLlVbeHrK6vrZVAFpoqoxOOp >> ZaliFI6FTZkyiz3KE6pUjMR6PSiiTwK5GW/xhiI2ky5tcBgv4y8ZHXDiTOmchFt4 >> M5Rksa1BFd+fVbV0tn6m >> =u/HP >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
