I am continuing my practices with JSF 2.0.
I see templating is a great thing to do, and it has lots of advantages. But today i got a new doubt related to it.
I created a template for my pages.
In the template, i use tags for the parts that are different(Those parts will be implemented later in a page using the composition tag in combination one or more define tags).
<ui:insert name="content" />
Also inside the template, to avoid putting to much code in the template, i create tags to add some other chunks of xhtml.
<ui:include src="/languageChanger.xhtml"/>
This is how my folder structure looks:
It all works as i spect, but when in the url i navigate to languageChanger.xhtml i see the composite chunk of xhtml:
My doubts are:
-Is that chunk of independent code placed in the right place?, Or it is wrong, the user should not be allowed to see that from the URL?
-Is that place save to have other components like login, register...?
-To avoid user access directly the component i could place it in WEB-INF folder, but then i have a problem that the include tag does not find the path. What should i do?
-What would be the best practice, where to place this independent chunks of code?
Is that chunk of independent code placed in the right place?, Or it is wrong, the user should not be allowed to see that from the URL?
Put it somewhere in /WEB-INF. Direct access to this folder is disallowed by the container.
Is that place save to have other components like login, register...?
I don't understand you. Perhaps you meant to say "safe" instead of "save"? What do you mean with "other components"?
To avoid user access directly the component i could place it in WEB-INF folder, but then i have a problem that the include tag does not find the path. What should i do?
Your path was apparently plain wrong. Facelet templates, includes, tags and compositions (not composite components) can perfectly be placed in /WEB-INF.
What would be the best practice, where to place this independent chunks of code?
Put it in /WEB-INF. Best practice is to use absolute paths, i.e. start the path with /. It will be resolved relative to the webcontent root. E.g.
<ui:include src="/WEB-INF/languageChanger.xhtml" />
Only the "main" page (the one which is to be requested by URL) cannot be placed in /WEB-INF.
For your first two questions:
Is that chunk of independent code placed in the right place?, Or it is wrong, the user should not be allowed to see that from the URL?
Is that place save to have other components like login, register...?
The templates and the default content used by them are in the right place. They must be present under the web application's document root, and not elsewhere.
For your last two questions:
To avoid user access directly the component i could place it in
WEB-INF folder, but then i have a problem that the include tag does
not find the path. What should i do?
What would be the best practice, where to place this independent
chunks of code?
The partial answer is provided above, where the need to place included files under the document root has been mentioned. The "resource resolver" used by the JSF runtime, requires that the facelet be present under the document root of the application. Facelets cannot be placed in WEB-INF for this reason.
If you need to prevent users from accessing these pages directly, then you must write a web-application filter to prevent access to these pages.
The Mojarra runtime does not internally forward any HTTP requests to a template resource; instead, it includes the contents of the file, retrieved as a stream. This implies that you need not restrict the filter to dispatch types of REQUEST alone; you can apply the filter to all dispatch types.
Placing all templates and the included facelets, in a /templates directory would make it easier to apply the filter on a single URL - /templates/*.
Related
I have a web application that contains hundreds of HTML, JavaScript and image files. These files are located under the root directory:
my_root--
-- html
-- js
-- images
These folders contain some subfolders.
From a security reason I need to move all these resources under the WEB-INF folder so they will not be directly accessible.
Currently JSP and servlet files are already under the WEB-INF folder.
What is the easiest method for me to safely move all HTML/JavaScript/images folders under the WEB-INF without breaking all links/forwarding to resources in these folders and make sure these resources are not directly accessible?
I am using WebSphere and WebLogic servers.
What is the easiest method for me to safely move all html/js/images folders under the WEB-INF without breaking all links/forwarding to resources in these folders and make sure these resources are not directly accessible?
You're making a thiniking mistake here. HTML/JS/image (and CSS) resources need to be directly accessible anyway. For JSPs the story is different, some of them, if not all, need to be preprocessed by a servlet (e.g. to retrieve some list from DB for display in a table). If those JSPs were been accessed directly, then that servlet step would be skipped altogether, which is absolutely not what you want (the JSPs end up "empty"; without any data from the DB). That's why they should be hidden in /WEB-INF to prevent direct access without going through a preprocessing servlet first. Also, in case of servlet based MVC frameworks, this way the whole MVC framework process (collecting request parameters, converting/validating them, updating model values, invoking actions, etc) would be skipped.
Your concrete functional requirement is not exactly clear (the whole question makes at its own no sense; the answer is just "don't do that"), but if you actually want to restrict access to static resources which don't need to be preprocessed by a servlet at all to certain users only, then you need to implement an authentication/login system. You can utilize container managed authentication or homegrow a Filter for this.
You can go with a very simple tool like notepad++ and use the findAndReplace feature. Eclipse can also do this but it gets tricky to effectively find every reference.
Note that there are other ways to stop users from accessing your images. It is probably easier to just leave things where they are and instruct the websphere to stop serving these images from the images folder
I am developing a java/javascript web application with JSPs, servlets, JAX-RS, and AngularJS. I am pretty new to this kind of stuff.
One problem I've been having is that I need to address url paths from static html, from javascript files, from jsps, and within servlets. I would like to be able to deploy this web app under different context roots (basically deploy in different folders). But in order to do this, unless I am mistaken, I must go through all the static files, (javascript and html) and change every link to properly reference resources based on new root directory. For the server side files, there are some java convenience methods like ServletContext's getContextPath() which allow me to avoid this.
Are there any conventions or strategies that people use to allow one to easily move a web app to different directories on a site without breaking all the links? At the moment I am guessing you must do search and replace for all the links.
Maybe put a special tag next to all local links so you know to change it?
Cheers,
As Java1 indicates, just use relative paths.
If the resource you are referencing is on the same level as the current web page, you don't need to prepend any path info. For example, if your main web page is loaded from path http://www.example.com/context/hello.html, and you have an image folder with path http://www.example.com/context/image, you can just load a image from that folder in your html with the relative path <img src="image/someimage.png">, without putting hostname or servlet context in your path.
If you are level deeper than the resource you are referencing, use "../" in front of the path. For example: <img src="../image/someimage.png">. If you are two levels deeper, use `../../image/someImage``, etc.
This holds true not just for images, but for scripts or static html as long as the web browser is loading the resource.
The web browser is responsible for converting the relative path to a server path. If you need to load something from the server side, you will need to use the full path.
I have my java application now i want to add security in my classes so that no one can de-compile my class files or open jar files.
i also want to add constraints in my web.xml file so that no one can try to access from another servlet.
I want to add security in my classes so that no one can de-compile my class files or open jar files.
You can't. It is mathematically impossible.
If someone can get hold of the JAR file / ".class" files, they can extract and decompile the classes. (There are ways to make it a bit harder ... but there is nothing you can do to stop a skilled and motivated attacker ... apart from not delivering code to him, in any form.)
I also want to add constraints in my web.xml file so that no one can try to access from another servlet.
Also impossible:
If you are talking about another servlet in the same web container, then anything you can put into the web.xml file can be edited out by the person who controls web container.
If you are talking about a servlet in another web container, then there is no way you can reliably distinguish a servlet making a request from a web browser making a request. All of the clues (e.g. request headers) can easily be spoofed.
How can I go to the source folder of a project by the browser URL in Java web. I want to ask that my project (consists of JSP and Servlets) is running at http://localhost:8080/myproject/index.jsp in Tomcat. If I want to go to the source folder that is myproject through browser's URL then how can I go? Simply you can tell that I want to hack this project, by knowing this I can prevent this access and can protect my website.
Not sure if this helps you, but if you're using some kind of Controller pattern (e.g. using Struts or a custom servlet that forwards to a JSP), the recommended way to prevent direct access to your JSP pages is to place them in the WEB-INF directory and then forward to these pages from your controller. See here for more details: How to properly put JSPs in the WEB-INF folder?
The Servlet 2.3 standard also defines how to prevent direct access in a similar manner (without putting them under WEB-INF), which then also requires to forward the request to these pages. For details, see here: http://www.jguru.com/faq/view.jsp?EID=471953
This question already has an answer here:
File names for JSP include directive to avoid compilation of them
(1 answer)
Closed 5 years ago.
What are .jspf files in JSP? As I know the compiler will look for .jsp files to compile, then how are the .jspf files compiled?
As others have noted, .jspf files are JSP fragments. They're designed to be statically included in another JSP file, not compiled on their own:
<%#include file="/WEB-INF/jspf/example.jspf" %>
You'll note that this example comes from the /WEB-INF/jspf directory. This means that it is not accessible outside of the web application; there's no way to construct a URL that can retrieve it. If you put them in the same directory as "normal" JSP files, you can construct such a URL; Tomcat, for example will retrieve the page as a text document. A front-end web-server, however, can block these URLS.
I like JSPF files as a first step in refactoring large JSP pages. Since they're statically included, you can extract a small chunk of the file without making provision for scriptets or variables, leading to pages that are somewhat more maintainable (and I want to stress, it's a first step; dynamic includes and taglibs are usually a better long-term solution). When refactoring, I believe in keeping the fragments close to their parent files; this is when having a web-server to block URLs becomes useful.
JSP Fragments can be compared to server side includes. These fragments are not compiled on their own, however there are compiled along side the page in which its included. If I've to display different pages base on a user preference, i will opt for jspf.
What : .jspf files are generally files that are included in .jsp files via the include directive. The 'f' stands for 'fragment' as these files are not full JSPs in and of themselves.
How to Compile: Since .jspf is a fragment of a jsp hence it may not be complete and compilable source, so most of the time it can't be compiled independently of another, complete, source that references them.
Source : Ibm Infocentre
IBM says that .jspf is for JSP fragments. A fragment may not be complete and compilable source, so they likely can't be compiled independently of another, complete, source that references them.
They're mentioned in Sun's developer resources in the same context - a naming convention for JSP Fragments.
In many web frameworks, it's possible to assemble views and pages from smaller, shared views and pages. Using JSP, these smaller pieces are called fragments. As the name implies, they're not necessarily a complete representation without some larger context.
Other languages and frameworks have their own term for the equivalent concept. In Ruby on Rails, for example, they're called partials.