Why do I get:
java.lang.NullPointerException org.owasp.csrfguard.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:53)
when trying to run the 0wasp.CsrfGuard.Test example app on Tomcat 5.5?
I'm using the example app exactly as it came in the download but with the following changes to get around listener errors:
I downloaded the CsrfGuard 3.0.0 package and copied the Owasp.CsrfGuard.jar to WEB-INF/lib to get around the listeners not being found.
I changed the web.xml file to use the listener that comes with the Owasp.CsrfGuard.jar rather than the two listeners in the original web.xml, which don't exist.
When I start the app there are no errors but when I point my browser to the /Owasp.CsrfGuard.Test/index.html page, I get the above error.
Any ideas to try?
Update...
Several hours later and I got it working without error. I don't understand why but the filter errors seem to stick around even after stopping and restarting a webapp (in Tomcat at least). I had to rename that webapp's directory, wait 10 seconds for Tomcat to auto-undeploy it, rename it back to its original directory name, and wait 10 seconds for Tomcat to recognize it as a new webapp. I also removed the "x-requested-with" init-param from the web.xml file since I don't use AJAX. Don't know if that really needed to come out but it works so I'm leaving it out.
Now, the "protect.html" file is indeed protected but it is protected too well. I can't get to it at all. If I try to go directly to the protect.html page, it should not allow that, which it doesn't. However, it should allow me to get there through the proper webpage flow with all the pages getting the proper token(s).
The question now is how can I get to the protect.html page?
Thanks.
Got it! In case someone else has problems, here is what I figured out to get JavaScript DOM Manipulation working.
All of the references in the .properties file MUST BE absolute with reference to the web container (Tomcat in my case). Even if you place the .js and .jar files in a specific webapp and modify that webapp's web.xml file with the proper settings for CSRFGuard (with relative references by the way), the entries in the .properties file must include references to the webapp name. For example, it must be something like:
org.owasp.csrfguard.unprotected.Index=/someapp/index.html
rather than just
org.owasp.csrfguard.unprotected.Index=index.html
This is not intuitive since unless you are dealing with the entire Tomcat container (i.e. the master web.xml file) you can generally drop the webapp name since it is implied for that webapp.
Now I'm going to look into the other CSRFGuard method of JSP Tag Injection since the JavaScript mechanism won't work if the user has JavaScript turned off in their browser.
Related
I've seen this question: Prevent mod_jk to shows/append index.cfm?&_modcfmlredirected on page load
The first time I'd load a site after server-start, it appends index.cfm. This is a problem because I'm trying to conceal page extensions (as many websites do). The page fails to load because of this.
After that first try, if I try mysite.com/, it loads fine.
I tried the suggestion in the answer on that similar question, (upgrading 1.04 to 1.10, and 1.11) and the only difference is now the first load appends /index.cfm? (adding a question mark).
In the meantime, I have an IIS rule to allow index.cfm.
Before updating the file, I also updated Lucee to Lucee 5.3.3.62
Your site context is being created at runtime. This is what is happening on that first request. To avoid this, simply create the site context at boot time by adding it to Tomcat's server.xml file, located by default in the tomcat/conf/ directory. The file is commented. Simply scroll to the bottom, add the new context so that it matches the comments but has your site's values, then restart.
HTH
I've this unique scenario :
Say I've some jsp file (a.jsp) and tomcat is serving this page. Suppose i now delete the file a.jsp and add again a.jsp (with little modifications) the tomcat is not taking the newly modified file. It says file is missing even though the file is there at exactly the same location. Otherwise i've to refresh the project in eclipse for the changes to take effect.
I tried adding the following block in tomcat's web.xml but it didn't help much:
<init-param>
<param-name>checkInterval</param-name>
<param-value>1</param-value>
</init-param>
I'd like to know if there is any solution where i don't need to refresh the project and the changes are taken in seamlessly.
The issue here is if i edit the same jsp (it still works fine -- the changes take in effect) but if i delete the jsp file and then add the same jsp file (at the same location) with little modifications the changes does not take in effect
Did you enable Hot-Deploy? If you double-click Tomcat in Eclipse there should be a Publishing-Section. "Publish on Save" is probably disabled.
Take a look at following Question it could be related to your problem:
Integrating tomcat and eclipse as a hot-deploy environment
At some point, another request must have come-in for a.jsp and Tomcat has cached the "not found" result. There have been a bunch of reports of Tomcat caching responses longer than expected, and I haven't gotten a clear answer for why that happens. It usually ends up being some slightly wrong configuration.
I want to get the absolute path of my app and I'm using the code below:
String pathToSave = FacesContext.getCurrentInstance()
.getExternalContext().getRealPath("/");
the result is:
/home/ronaldo/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/Odontonew/
But I'm waiting for something like: /home/ronaldo/workspace/Odontonew/
What is wrong ?
ExternalContext#getRealPath() returns the path relative to where the webapp is been deployed, not where the webapp is been developed orso, as you incorrectly seemed to expect.
But, the variable name pathToSave indicates a much bigger problem: you seem to intend to save files in there. This is a bad idea for the reasons mentioned in the following answer: Uploaded image only available after refreshing the page. In a nutshell, save them to a fixed local disk file system path instead. Note that some servers offer ways to make this step easier configurable, e.g. JBoss.
Just stop using getRealPath(). You never need it in real world. In the 10 years I developed Java web applications (it's under the covers coming from ServletContext#getRealPath()), that method was never been useful for anything. Just ignore that method altogether.
See also:
What does servletcontext.getRealPath("/") mean and when should I use it
Up until now, when I needed to update the content of any pages, I have always had to update the source code directly and re-deploy the whole application. Right now, I want to implement a feature such that I can update the content of any HTML pages dynamically without having to re-deploy the application.
I tried to implement the feature with PrimeFaces's <p:editor> component but it does not work. To be more precise, my functions can correctly update the required page. When I goes to the source code folder, I can actually see my changes. However, subsequent requests for the page still render the old content.
I'd be very grateful if you could show me what I have done wrong. I'd also appreciate it very much if you could show me any other ways to achieve the same goal.
I think you are editing your work-space from your deployment. :)
You have 2 places with the code. One is deployed, and the other in your "working space".
First, it sounds to me like you want your working space to be the deployment. This way whenever you are editing something, you will be changing the deployment directly. For that, simply create a new project in your IDE and point it to the deployment folder.
I bet that :
C:\\Users\\James\\Documents\\NetBeansProjects\\MyProject\\MyProject-war\\web\\
points to your work-space and not the deployment. so effectively, your deployment is editing your work-space.
I think you are looking for this one:
FacesContext.getCurrentInstance().getExternalContext().getRealPath("/")
and if you want the location of the WEB-INF
use the following
String fullpath = FacesContext.getCurrentInstance().getExternalContext().getRealPath("/")+File.separator+"WEB-INF";
and so on...
My code actually was working perfectly. From the above answer of user1068746, I did some research and found this article. The solution is very simple: creating a virtual directory mapping to my hard-disk's directory. As a result, any updates to my files on the hard-disk will immediately be visible to future requests.
I have come across to a strange problem where apache tomcat server is showing 404 server code. But some of the files are being detected by the system. I am using eclipse for the development.
Any suggestions?!
EDIT 1 :
i have checked the webapps folder of CATALINA_HOME but nothing is there related to the project.
I'd recommending seeing if you can deploy a WAR file successfully in Tomcat without using Eclipse.
Right now it sounds like you don't understand Java web apps or Tomcat very well.
When you throw Eclipse on top of it there's too much ignorance to make progress.
So remove one of the things you don't understand. See if you can make the WAR file, deploy it manually, and see your JSP in the browser by hand. Once that works, you have a baseline for comparing how Eclipse needs to do things.
Another possible issue that might cause similar problems is if you have deployed your application in the root context (i.e. under the name ROOT) and the jsp in question is in a folder like /manager, while you also have the manager application. In this case, Tomcat will give preference to the manager application, rather than the /manager path inside the ROOT application
Eclipse wont always deploy dynamically aka hot deploy and you need to make it re-deploy. So sure shot way of checking is to actually going into the war file, or the root directory and checking if the jsp exists.
Also you have to provided much information as to what kind of a web application it is, for me to understand the problem better. For example, in struts a wrong entry in struts-config.xml will result in 404 even if the intended jsp is present.