some of you advise me to handle sessions using filters. I studied a little about the filter following some guides found on the internet, and wrote a filter referring this guide.
I saw that the filter is called for every component of my page (css, images etc); is there a way to call it just when a jsp or a servlet is load? I need a method that can understand if jsp or a servlet is load, in order to make some stuff inside my filter.
Yes, you can do that. Just change the url-pattern for your session filter.
If you are using some web framework (spring mvc,...) with one dispatching servlet, you can map your filter only to this servlet using servlet-name and requests to other resources (js, css) will not be intercepted by this filter.
First off, please don't be misled by the purpose of the tutorial in the link you have specified. Session handling is always done through cookies, URL-rewriting (or for the more advanced, SSL). He's merely using filters to enhance application security, by ensuring the user is redirected to the login page, whenever he goes directly to an "avoid-url".
Think about a filter, a physical filter. Whether it be an excel filter or a physical gravel filter. It stands between one thing and another thing:
Java web filters can do the same thing:
Just like you can choose which water bottle to filter, you can decide which requests you want to filter. You do that using the filter-mapping element in web.xml. You can specify individual servlet names, or a url pattern.
Related
I am coding a Tomcat application and am authenticating against Google's oauth2 services. I was originally going to write a simple Filter to do the authentication but there is no way to set the user principal in a Filter. From my understanding you have to have the Filter call an implemented HttpServletRequestWrapper and set it inside of that class as seen in this post
I'm pretty sure Tomcat only instantiates one Filter of each type you may have defined and all requests go through this single object down the Filter chain (correct me if I'm wrong).
In the linked to code, is it correct for the code to call
next.doFilter(new UserRoleRequestWrapper(user, roles, request), response);
where every request is instantiating a new UserRoleRequestWrapper? Should this Filter instead have one request wrapper instatiated that gets shared amonsgst all requests? I'm having a hard time finding documentation on the specs of classes such as these.
I don't think that a Filter is what you're looking for. Doesn't seem right for this purpose... Filters weren't created for such use cases; they were created for pre/post processing requests and responses, with emphasis on manipulating the actual request/response data, rather than other aspects of the client-server communication (such as security). Remember, authenticating a user may have further repercussions than just handling HTTP request cycles. Security ties into the JavaEE framework in a lower level than HTTP cycles.
If you want to authenticate against oauth2, you should be far better off implementing some sort of a JAAS implementation for it, and plug it into Tomcat.
I have a simple user application. I have a MainController Servlet that will be in charge of general interaction in the application. This servlet will be "listening" for url-patterns: /, /index, etc (any other form of index). I also have an UserController Servlet that is in charge of login among other things, this one "listens" from /CheckLogin url-pattern.
I have form in a jsp, in the url /, that when I submit it, it points to the servlet at /CheckLogin. Then UserController servlet process it and either the login is ok or wrong it redirect to / (the MainController will be in charge of determining the page to show depending if the user logged in or not).
All work flawlessly except that after submitting the first time, then the form page has url /CheckLogin. I would like to remove it and show only / (even if logged or not). How do I do this (plain Java EE, not Spring or any other framework)?
I'm not sure if this is what you're looking for, but if you do a forward instead of a redirect, the URL on the client browser will not be updated: RequestDispatcher#forward(javax.servlet.ServletRequest, javax.servlet.ServletResponse; an explanation can be found at Forward vs Redirect.
In addition, it might be a better idea to implement authentication as a Filter instead of a Servlet; that way, the Filter can be used to intercept any URL you deem needs to be secured.
Is there a specific reason you're not using a web framework? They're meant to take care of things security and routing for you, generally.
I have just started working on a struts2 project. I have seen the power of actions in struts.
i just want to Know few things
1.When a client asks for a page through the search engine does the server direct the request through an action which maps the jsp?
2. If the ans to the above question is no how do we set-up all the bean properties in the action class required for rendering the page?
3.If the ans to the above question is no how to maintain data confidentiality as all interceptors are built around action
If your JSP pages are publicly accessible and a user goes to them directly (e.g., from a search engine or bookmark), then no, your action would not be invoked.
Your JSPs should be placed under the WEB-INF directory (e.g., /WEB-INF/jsp) so that users cannot get to them directly. In Struts2 (any many other MVC frameworks), JSPs are only the templates for your view layer and should not be accessed directly.
There are several comments in reply to one of the answers in Problem with moving JSPs under WEB-INF directory that reinforce this:
I'm not sure about struts, but with Spring, it is accepted practice to put JSPs in WEB-INF and then your view code accesses the protected JSP. This also prevents direct HTTP access to your JSPs so you get better access controls. -- jkf
Same goes for Struts as well. It is considered a good practice to put JSPs in WEB-INF folder. Anyways, I have got my answer. -- craftsman
The way Struts works is that it has a dispatcher servlet that reads the path of incoming requests and decides which action to send them to, then the action executes and forwards to a jsp. So whether the action gets called depends on what the url is that the client is clicking on, if it is a url that is mapped to an action in struts then it will call the action, otherwise not.
I have a small application with 3-4 servlets and a basic module that provide me authentication like:
public class Authentication {
public boolean isUserAuthenticated(){
....
}
}
Is there a way to check the authentication using my class BEFORE every other servlet calls, without have to add code in each of them? I'd like to avoid the check of the user for every servlet I have and for every servlet I will have to add.
Any suggestion is well accepted :)
Thanks, Roberto
Absolutely, use a servlet filter. It's the standard way of implementing security in Java Web applications.
The Java Servlet specification version
2.3 introduces a new component type, called a filter. A filter dynamically
intercepts requests and responses to
transform or use the information
contained in the requests or
responses. Filters typically do not
themselves create responses, but
instead provide universal functions
that can be "attached" to any type of
servlet or JSP page.
You can put your authentication logic in a Servlet Filter. If the filter finds a request not authenticated, it can redirect the user to a login page (or whatever).
Anything that gets to a servlet is implicitly authenticated by then.
Use Acegi Security (now Spring Security). Using Spring will also make your life easier in other ways. (Spring security works using a servlet filter as mentioned in above posts).
User Authentication can be done though servlet filters.
Check the detailed example User Authentication Filter Example
My web app has a secure area which users log in to via a JSP. The JSP posts the user name and password to a servlet, which then checks to see if the users credentials are valid. If they are valid then the user is directed to the secure resource. How can I ensure that users can't just navigate to the secure resource without validating first?
A common approach is to set a token in the user's session i.e.,
session.setAttribute("loggedIn", "true");
or even
session.setAttribute("loggedInUser", "someUserName");
and check that on any page that should be secured. A good strategy is to perform the check using a servlet filter that you attach to any page to be secured. If they don't pass the check, the filter can redirect to the login page. Also see here: http://java.sun.com/products/servlet/Filters.html
This is a good article on using filters for authentication also: http://www.developer.com/java/ent/article.php/3467801
What bout using the security-contraint in your web.xml :
<security-constraint>
<web-resource-collection>
<web-resource-name>Secure</web-resource-name>
<url-pattern>/secure/*</url-pattern>
</web-resource-collection>
Make sure people always access your app through a single servlet, where the servlet dispataches the request to a JSP, and returns the resulting response to the browser. This way you will always be in control of what happens because there is a single entry point.
A different approach is to have a session variable (server side, or even in a cookie) which gets checked by each and every JSP which requires authentication.
Security is really hard to get right. Much more than you would usually think. The use of a framework (Acegi comes to mind), or the standard "" section of web.xml as LenW pointed out is a must ! At least use a filter to handle the authorization part of your security.
I dont really like the solution of using a single point of entry (as suggested by Rolf). It seems to me like an artificial constraint put on your architecture. And there is a lot of good reasons to have multiple servlet in a webapp.
Whatever you do, dont use a technique where you rely on manual code on every page (like : every JSP begining with "if user_authentified ..."). You will forget to put it somewhere ...