sendRedirect(), oh this must be the most hated thing

[Balamaci Serban]

I've got a filter that checks the session for the presence of "authentificated" for all the files in the /protected path, if it's not there i want to redirect to the /login.jsp which is just in the base directory.
So i type http://localhost/MyContext/protected/apage.jsp
i want to be redirected to http://localhost/Mycontext/login.jsp
actually to https, but that's another issue.
so if in the filter that intercepts http://localhost/MyContext/protected/* i say res.sendRedirect("/login.jsp"), guess where it sends me:
http://localhost/login.jsp Ayn't that cute?... but it's wrong!
i tried:
res.sendRedirect("/login.jsp"), guess where it sends me on the call to http://localhost/MyContext/protected/apage.jsp, it sends to
http://localhost/MyContext/protected/login.jsp that's cute also but still wrong. Any way of just getting http://localhost/MyContext/ the base context so i can append login.jsp to it?

[David O'Meara]

You can use response.getContextPath() to determine the context, but is there any reason you're not using container managed authentication?

[Balamaci Serban]

Thanks! That solved the problem. The reason i'm not doing container, hmm, well i'm not pretending to know much about it, i know that you are not tied just to that simple windows popping up, and that you can actually have the option to design your own login page. The problem is that i would like to use encrypted passwords in the database, maybe some cookies so that i can make some automatic checking and not present the form at all and it's nice to have the user redirected to the initialy requested page after succesfull login. The login page is in https, but i guess that you can do that in container managed too. Only fear i have is that the filter will not always fire and sometimes it would get the user in the protected area. Filters must cost a lot of proc time also....

[Scott Duncan]

Here is some reasons why we control authentication with a filter:

The modification to web authentication will allow us to provide seemless single sign on integration between the rich client and the web client. The current implementation requires multiple authentication into the server. This is prohibited in a OTP (one time password) scenario where the credentials are invalidated after the first authentication request. By managing the authentication ourselves, we can maintain both the web and rich client authentication within a single authenticated server session.

If the authentication process is controlled by us, we can invalidate a users web session outside of the normal timeout periods. This will enable additional features for user administration such as kicking users out of the application while they are currently within a valid session.

In addition, we will be able to gather additional information on the login page, an assured single point of entry into the application, that can be leveraged throughout the application. For example, timezone offset can be gathered at that single point of entry and used to provide localized dates and times throughout the application.