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
Related
I have a java web app (Java ee) which is Servlet with JSP. Problem im having is that sometimes when i go to browser i wont find the resources that i have added, like some .jsp files will be missing completely and/or missing parts. If i refresh multiple times or if i delete a .jsp file and then add it again with the exact same code it temporarily fixes the problem.
I have tried doing ctr + F5 to clear the cache from browser, but didnt work. I also tried removing cache from intellij IDEA, also didnt work. What is going on?
We're trying to force the client's browser to reload static files when they change. Currently, we have our build scripts automatically creating a new directory with the build timestamp and replace the content in the code to point to that directory.
However, I feel this is hardly an optimal solution. It forces the client browser to load every single file if a new build exists, even if only 1 file changed, and build time increases considerably by scanning every file and replace every static file reference.
I know we can also set the version when we declare files (something like < link src="blahblah.css?version=1.1" />), but this forces us to change all our code to include a version placeholder and still have our build scripts replacing it.
Is there a smarter way to do this? We're using Spring MVC. Is there any option in mvc:resources that I'm not aware of to do this without changing code? Or something on web.xml?
We're using tomcat. Is there a way to do this at server level? Would it help to use a cache like Varnish or something? Or these caches only allow to set expiry times and not check that the file changed? Bear in mind I'm not comfortable at all in server and cache configuration tasks.
I found out about this project https://code.google.com/p/modpagespeed/, but since it's far from my comfort zone, I'm struggling to understand capabilities and if this helps with what I want.
Anyone has any ideas?
Thanks
You can use version as a query parameter, e.g. /resources/foo.js?_version=1.0.0. If you are using Maven, it is not that hard to get version information from /META-INF/maven/{groupId}/{artifactId}/pom.properties. Of course this will force reload all scripts with every new version... but new versions are probably not deployed that often.
Then it is always a good practice to properly set HTTP caching headers. <mvc:resources> should correctly handle Last-Modified header for you. And you can set cache-period to make browser check the for resource modifications more often.
Here is a working solution: CorrectBrowserCacheHandlerFilter.java
Basically, when your browser requests the static files, the server will redirect every requests to the same one but with a hash query parameter (?v=azErT for example) which depends on the content of the target static file.
Doing this, the browser will never cache the static files declared in your index.htmlfor example (because will always received a 302 Moved Temporarily), but will only cache the ones with the hash version (the server will answer 200 for them). So the browser cache will be used efficiently for those static files with hash version.
Disclaimer: I'm the author of CorrectBrowserCacheHandlerFilter.java.
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.
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 a single application that I am deploying via Java web Start. I have several different jnlp files for different launch scenarios. I am using DownloadService2 to check for updates periodically. When an update is available, I prompt the user. If they elect to update, I launch a new instance of javaws using Runtime.getRuntime().exec(), passing in the full jnlp url, then I System.exit(0). Effectively, this kicks off an update/restart cycle.
The problem is, since I could have started from one of several jnlp files, I can't simply hardcode the url. I know that I can get the host:port portion of the url from BasicService.getCodeBase(), but is there a way to get the file portion of the url? Currently I am adding a "jnlp" argument to the application-desc similar to the following so that I can retrieve it from args:
<application-desc main-class="my.main.class">
<argument>jnlp=myjnlp.jnlp</argument>
<application-desc/>
I think this will work, but I'm wondering if I am making it harder than it needs to be. Thanks.
Perhaps it would be best to provide this functionality using the DownloadService.
I worked around this issue using the approach described in my question. There doesn't seem to be a better way.