<img src="/images/profilePicture.jpg"> then if some one enters "websiteDomain/images/profilePicture.jpg" in browser url should not be able to access image files.
I know 2 things by which this can be achieved but i do not want to use them
1. Placing the images folder in WEB-INF directory
2. Creating a filter
Creating a filter is a problem as if i specify src attribute for img it will invoke the filter
Secondly, Placing the images in WEB-INF folder i doubt will work because the image has to be rendered to the client. If client itself cannot access the data how can jsp serve it to the client
If you only want the images to be visible to somebody who is logged in, then it naturally follows that whatever serves the images must decide whether the request for an image is coming from a logged-in user. A filter seems ideal for this.
Joined: Sep 18, 2011
basically i want to restrict direct access to image files through url
is it like i will have to use content management system or something like that ?
Content management system? That's a pretty vague term, but perhaps you might be able to spend a couple of months investigating the possibility. Especially if you've already decided to reject the filter idea. If it were up to me, though, I would make sure I had clear requirements and then spend a couple of hours investigating filters.
You can protect URL access to image resources by placing them under a special URL pattern and adding a security rule in the web.xml file. For example, "http://myserver.com/secureimages/bigforest.jpg". If you use the J2EE built-in security system, you avoid the need to code and debug a filter yourself. And for that matter, a login processor. An added benefit is that you'll be using a well-documented security mechanism that has managed to stand up to over 10 years of use and abuse.
Do keep in mind, however regardless of what sort of protection scheme you use, once a user is able to view an image, they can save a copy of it. If you want a more secure means of distribution, only display watermarked images, and restrict access of the "pure" image to people who have purchased the rights for it. You'd normally do that by putting a servlet in control of the image download.
An IDE is no substitute for an Intelligent Developer.
Joined: Sep 18, 2011
@Tim Thanks for your reply... i need the second kind of security. Is it possible to display original image on a web page and for downloading i want to give a watermarked image.
I want this to be handled by pure jsp and servlets using tomcat 7.
One more thing Tim i am very new to web development.The first point that you mentioned about J2EE security i am not aware of that.
Can you please tell me anything that is available for tomcat so that i can research on it and decide which one to choose.
"displaying" an image and downloading it are for all intents and purposes the exact same thing. The only real difference is in how the browser interacts with the user. So adding a watermark to the download is locking the barn door after the horse has left. Although you can gain protection if the display images are low-resolution thumbnails or intentionally damaged in some way.
The J2EE standard container-managed authentication and authorization system is implemented on Tomcat exactly the same way as it is for every other J2EE server. Which is one of the advantages of the system. Unlike the DIY in-house insecure security systems, you can find plenty of information in any good intro to J2EE book and support from any J2EE expert worthy of the name.
The one thing that is Tomcat-specific is the server-side part of the security system. Tomcat - like many other J2EE appservers - supports plug-in security modules known as Realms. Realms are simply components that allow validating logins and checking roles against a variety of sources, including the very simple tomcat-users.xml file, J2EE data sources, LDAP servers, web-service based security managers and so forth. The Tomcat docs do a fairly good job of describing the standard set of Realms, plus it's quite easy to write your own Realm component if desired.