Tomcat - changing the contents of the login page depending on how the user got there

Question

I have a web service implemented in Tomcat and using Tomcat container-based authentication. I am trying to make the login page look different depending on how the user got there. In particular:

• If the user clicks the Login button, I want the login page to simply request a username and password. I implemented a login button to simply bring the user to the "logged in" page and make this page safe in order to activate login to the container.

• If a non-authenticated user visits a page that requires authentication, I want the login page to also say, “You must be logged in to do this” or something like that.

So the problem is getting the controller or JSP for the login form to find out what the browser requested when it was redirected here. I looked at the headers and other attributes of the request object, but I could not see anything that could help.

Can anyone suggest a solution? Or maybe another way to implement the login button to avoid the problem?

Answer 1

You can use this to determine the purpose of the original request:

<% String value0 = (String)request. getAttribute("javax.servlet.forward.request_uri"); if(value0.contains("login_success.jsp")) { out.print("USER, LOG IN!"); } else { out.print("USER, you have to LOG IN to go there!"); } %> 

Other options:

You can implement the login button to redirect to the login success page and add ?MyKey=value to the URL, this attribute can be seen using the login page , and you can respond to it.

I will work on my code that displays everything and anything that I can find, and make it more readable, and then publish it here. I am sure that the value in which the user receives the next is present somewhere in your request , you just need to find out where.

Answer 2

You have several options: 1 is the "Referer" header. This field will contain the URL where the browser was finally ... So you could see on the login page, there was the last page that they link to here, or somewhere else.

This will work, but not complete, some people / companies will filter out links, etc., and some browsers may allow users to enable it, so you will not get a link to the page in which they were last visited.

The BEST bet is to set a cookie when the user logs in, and then if the user requests a page that requires a login, your code simply checks for the current cookie value. If he is there, the user has already registered and you can show the page ... if you do not send them, YOU SHOULD LOGIN TO MAKE THIS page.

Answer 3

I prefer @Angelo's answer for portability, but if you want to associate your application with Tomcat, you can get the destination (where the user wants to go after logging in) from the launch request, which is saved to the session. I have not tried this, but I think this will work:

 import org.apache.catalina.authenticator.Constants import org.apache.catalina.authenticator.SavedRequest import org.apache.catalina.session.StandardSession ... StandardSession standardSession = (StandardSession) httpServletRequest.getSession(); // Retrieve the SavedRequest object from our session SavedRequest saved = (SavedRequest) standardSession.getNote(Constants.FORM_REQUEST_NOTE); if ((saved == null) || httpServletRequest.getRequestURI().equals(saved.getRequestURI())) { // user came directly to login page } else { // "You must login to do this" } 

Answer 4

The above solutions seem to be the opposite of me. The authentication controller should not look where the request came from to decide what to do ... it should be said. The controllers / redirection rules must know what they want to do and must send it to the appropriate action.

The input can go directly to the servlet login action.

I do not know how your servlets are configured, but the servlet should look for authentication in cases where it is necessary for some actions. If it is not authenticated, redirect to the authentication action. Login / authentication actions will be slightly different (setting parameters or text), but they can go to the same view.

Having said that doing authentication from scratch is a lot of work, and it is usually much easier to just pull in other structures. For example: Spring Security.