This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
You cannot access jsp under WEB-INF. It is not a standard J2EE Spec. The container only looks for class-files in WEB-INF and if you ask for jsp in this directory, it will return an error 404.
RAGHU<br /> <br />"When the going gets tough, the tough get going"
Joined: Nov 22, 2005
Thanks Raghu sir but i dont eant to access my jsps directky how can be that possible like first they have to fill some password only \then next page will be available to them. but if they know name of next page they will directly access them.
Amit, The resources which need to be protected from Http access are placed under WEB-INF.Normally jsps serves the purpose of presentation to the user, that is why they are placed outside WEB-INF. Filters are attached to the views(jsp/html/.doc/.txt/xml) to prevent direct access to those views by requesting a url to that resource in the browser. I suggest you to try a sample application and check for yourself.
Originally posted by Amit Arya: i have some jsps under WEB-INF folder and as i know that they cant be access directly. so how can i access those jsps.
You can access them by forwarding to them from another resource that is available to the web (an JSP that is not under WEB-INF, or a controller servlet).
You can also grant access to them by creating a servlet entry for each JSP with a corresponding servlet-mapping entry. When creating the servlet entry, use the jsp-file attribute in place of the servlet-class attribute.
See section 10 in SRV.13.4 of the servlet spec for complete details regarding the servlet element entry.
I really don't see any benefit of creating a one-line intermediary JSP just so you can put the "real" JSPs under WEB-INF. There's no benefit to the extra level of indirection or to protect the JSPs from direct access.
Under such a situation, it's much clearer to just move the JSPs out of WEB-INF.
That said, I highly recommend the Model 2 approach over Model 1.
Yes, I'd prefer Model 2 to Model 1 anytime. But if you're maintaining a model 1 application, I'd say it's a whole new different story.
I have one very specific reason for doing this (or at least wanting to do this): I do not want clients to be able to see the real code of the JSP. (Or allow hackers to easily access the code). If I put the 'real' JSP inside WEB-INF, I'm at least assured that this JSP cannot be directly accessed by clients.
So, it's one or the other: x Clients seeing my JSPs (with scriptlets, ELs and what-have-you's [gasp! even SQL in the JSP?]) x Clients seeing one line of code - a JSP include. In which I know that this included JSP cannot be easily accessed by a malicious client (albeit this page would involve an additional level of indirection).
I'm not sure what your stand is on this, but I'm going to go with the latter.
Originally posted by Amit Arya: Thanks Raghu sir but i dont eant to access my jsps directky how can be that possible like first they have to fill some password only \then next page will be available to them. but if they know name of next page they will directly access them.
I see what you're trying to do. What I would do is to create a filter mapped to *.jsp. this filter would check if the user has logged in(by checking the session) and checking that the user logged in has access to that page. If both test fails, redirect to the login screen, otherwise just move on.
Same applies if you want to implement a "workflow" type thing.
Joined: Feb 17, 2007
Originally posted by Bear Bibeault: I see your intent, but still think that it's needless over-complication not worth the percieved benefit.
Ok then, to each his own. :thumb: Just as long as you know what I mean. We lost millions in revenue when 'hackers' so easily 'hacked' our legacy since the site was exposed. Oh well... moving along...
Originally posted by Bear Bibeault: A great argument for moving to Model 2! :thumb:
Yes, we are! It will take months and months to refactor the code (+PM, +QA, etc). (I'm fairly new to this company, and I tell you, their legacy system is bad!) Therefore, the need to 'hide' the JSPs on the old system while that one's still running.
Well, I cannot answer the how true question for every version of weblogic ever created, but I tried it in WebLogic Server 8.1 sp 4 and I got a 404 error trying to directly access a jsp under the WEB-INF directory.
How true is it that if my web application is deployed in WebLogic users CAN access jsp under WEB-INF folder???
Without further details I would suggest that this may just be due to misunderstanding of what this really means.
Quote: "As we stated earlier, since the specification is clear about not letting direct access to resources under WEB-INF, all J2EE compliant application servers implement it. However, the second part is not stated in the specification and consequently it is the vendor�s prerogative to implement it or not. Certain providers do (For e.g.Tomcat) and others don�t (For e.g. WebLogic)."
Joined: Oct 10, 2000
What is the second part not specified by the spec?That sounds like something different. [haven't dug into the linked ebook]
As we stated earlier, since the specification is clear about not letting direct access to resources under WEB-INF, all J2EE compliant application servers implement it. However, the second part is not stated in the specification and consequently it is the vendor�s prerogative to implement it or not. Certain providers do (For e.g.Tomcat) and others don�t (For e.g. WebLogic).
1st Part is : Do not allow direct(external) access to Resources inside WEB-INF. All container Follow this.
2nd Part which is ambiguous is that if JSP is inside WEB-INF , They should be accessible by other members inside WEB-INF. Older Weblogic don't allow access to JSP inside WEB-INF from classes(ACTION classes) inside WEB_INF\classes while Tomcat does allow this.