I'm fairly new to using Tomcat so I'm sure I'm missing something.
I have managed to run Tomcat on Ubuntu 18.04 and opened up the manager page, added a .war file which extracted perfectly and got displayed in the manager page(running=true)
However when I try to open up the app from the browser using the exact path it returns a 403 forbidden error with this in the description The server understood the request but refuses to authorize it.
What do I do to get it working
I have tried chown tomcat8:tomcat8 <foldername> and when I tried to refresh the browser the error message changed to 404 not found.
This is likely not a filesystem issue. What is most likely happening is the application requires authentication. Couple of ways to determine this... the best is to read the documentation. You can also look at the source code. Unzip the war and look in the WEB-INF directory, and you should see a web.xml. In that you'll see a security-constraint and roles sections. You'll need a user with those roles.
Tomcat can authenticate against a local database. In the conf directory, there will be a tomcat-users.xml you can add users to (there is examples in that file). Once you've created users, restart tomcat and try logging in with one of those users.
Related
I manage a few Tomcat 9 applications that are run on a remote server that also use IIS 8.5. Each site has three environments (DEV, TEST, and PROD). All of the environments are the same but on different servers. Their databases (Oracle DB) are also on separate remote servers. I do not use any other third party frameworks for the sites (such as Maven or Gradle).
One of my applications had an issue where an attacker could access the web.xml through a Multiple Directory Traversal Vulnerability. Some brief information can be found here: https://www.securityfocus.com/bid/63052/exploit
However, I discovered on the DEV and TEST (I thought PROD as well) that the filter we put in place was actually causing the site to not work correctly. You'd put in your user and password and click login and nothing would happen. I seemed to have fixed it on the DEV and TEST environment by fixing the regular expression that my code was testing the URI against. Code:
final String REGEX_INCLUDED = ".*\\/WEB-INF\\/web.xml.jsf.*";
...
if (Pattern.matches(REGEX_INCLUDED, URI)) {
log.debug("SecurityFilter redirect");
resp.sendRedirect("/errors/403.html"); // /login.jsf OR /index.html
} else
chain.doFilter(request, response);
I deployed the new war onto PROD, entered my user and password and it would load. The site redirects to the homepage after login, BUT it doesn't actually load if that makes sense. The response is a generic 502 error (shown below) but the URL does, in fact, say /home.jsp where it should respond with the homepage.
502 Error
I've checked the catalina log and I've not found a stack trace or any sign of an error being output. No other logs are useful either in showing what the issue is. I've tried just clearing my cache and retrying, using a different browser, restarting the tomcat service, restarting the site in IIS and nothing.
If there is something I'm missing that you wish to see let me know. BTW, I've tried removing the filter that blocks access to the web.xml just to make sure it wasn't the issue and both with and without the filter, it results in the 502 error.
Thanks in advance for any help.
Answering my own question: I had looked around everywhere and only after posting I found a related post:
502 proxy error on deployment
Their answer helped. The difference between my PROD environment and my DEV/TEST environments is that PROD is on a Proxy. I went to IIS on the server and found the server farm that the site used. I then clicked on the Proxy option and changed my timeout from 30 seconds to 60 seconds. Looks like my proxy was timing out. Hope this helps someone in the future.
I have deployed a war file inside a folder in the Tomcat webapps folder and the manager page is password protected. But I also want to password protect my application other than the Login system which it has of its own. I tried doing what is mentioned here.
But There has been no luck, when I do what it is mentioned there even the tomcat page i.e, localhost:8080 is also not accessible as it gives a not found error whereas I am able to access localhost:8080/manager/html page with the credentials and when I click on the Application I want to access it still doesn't ask for credentials but directly opens the web application.
I have a Java Web Start application. My JNLP instructs Java to prompt when there is an update, and create a desktop shortcut.
On UAT site, it works as intended. The shortcut's target will be something like this:
C:\Windows\SysWOW64\javaws.exe -localfile -J-Djnlp.application.href=[https]://[Domain]/[Path to my JNLP].jnlp "C:\Users[User name]\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\21\5819ce55-139863fe"
In Java Control Panel, I can see my application listed in the cache's Applications list. In the Resources list, I can see the entries for both JNLP and JAR files.
But on Pre-production site (using the same client machine), Java will use a different cache folder:
C:\Windows\SysWOW64\javaws.exe -localfile -J-Djnlp.application.href=[https]://[Domain]/[Path to my JNLP].jnlp "C:\Users[User name]\AppData\Local\Temp\tmp_cache2515468182853051613.tmp"
In Java Control Panel, the Pre-Production application is not listed in the Applications list. In the Resources list, I can only find the JAR file but not the JNLP file.
It is because of the missing JNLP in cache, that whenever I launch the Pre-Production version via the shortcut, Java will prompt that an update is available and will re-download the JAR file.
I tried turning on deployment log, but I have no idea what I should look for. I found entries like this:
Wrote URL [https]://[Domain]/[Path to JNLP].jnlp to File C:\Users[User name]\AppData\Local\Temp\tmp_cache3515307480207784226.tmp
But I have no idea why Local\Temp is used over DeploymentCache. The JNLP files of UAT and Pre-Production sites are nearly identical, the only differences are a change in the title element and contents in properties files.
Another difference I can think of is the server certificates - the JNLP and JAR files are hosted on Apache servers. Java will show a dialog for the Pre-Production certificate, saying that it failed to check CRL. I tried disabling CRL checking and the dialog went away, but it's still using Local\Temp instead of DeploymentCache.
What can be the reason behind this behavior of using different cache locations? It is almost like Java found something untrustworthy about the Pre-Production version and refused to cache its JNLP.
Edit: In a nutshell:
Same client machine, same settings.
Load UAT version of the application, JNLP and JAR gets cached in DeploymentCache folder (expected behavior).
Load Pre-Production version of the application, only JAR gets cached in Local/Temp folder, JNLP is not cached (unexpected behavior).
Only differences between UAT and Pre-Production versions are that they have different title in JNLP, properties files with different content, and that the Apache server hosting the Pre-Production version is using a certificate that Java can't check its CRL. Application JAR is signed by a different certificate that Java has no problem validating.
I would like to know what influence Java Web Start to behave like that. I suspect it has something to do with the certificate on the Apache server, but I can't find any documents about that.
Have you looked into deployment.user.tmp property in deployment.properties ?
http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/properties.html
As per Applet stopped working with a JNLP MissingFieldException <jnlp> see the cookie information to understand if Httponly is contained within it -- looks like it can cause this behavior with jws.
Alternatively this actually worked for me specifically...
In a browser, access the same exact resource from lower and upper environments and inspect the HTTP headers to see if there are any Cache-Control (no-cache and/or no-store directives) or Pragma: no-cache differences. Suspicion is that the environment that is not working has caching directives explicitly specified which, as per first comment of Java Web Start "Cannot find cached resource for URL" and first comment of https://bugs.openjdk.java.net/browse/JDK-8034978, happen to cause java web start to write to a different cache folder than what is specified in java configuration settings and, ultimately, causes the behavior discrepancy you're seeing. The fix would be to update the app server, web server and or any other intermediaries (eg. load balancers) to remove it from the http response headers.
I have the following problem. In one server, I have a folder /protected/ that requires authentication using a SAML token.
When I try to access resources in this folder, I get redirected to a log-in page first, and after login I can access the resource.
Now, I added a .jnlp file inside the /protected/ folder with all resources required. When I try to access the .jnlp file, I get the login page as expected. After logging in Java Web Start initializes and tries to download the resources.
However, Smart Start fails immediately, complaining that it couldn't parse the .jnlp file. When I look into the debug console, I see that Java downloaded, instead of the jnlp file, the log-in page. So it seems that the Java Web Start application does not share the credentials of the browser, so it requires a new log-in
My identity provider is ZXID, and we are using SAML. I would assume that Java Web Start must somehow use the same SAML token as the browser, right? Is this correct? is it possible?
So far in my investigations, it seems that when the browser finds a .jnlp file, it starts Java immediately and the Java Application will try to download the jnlp, creating this issue. I did find out that the JNLP file must not contain the codebase entry. Otherwise the Java VM will try to re-download the file, but because it is not authenticated it will get the login page.
However, if the JNLP can be read, the resources can not be in the protected area either, because again JWS is not authenticated.
So I guess what is needed is that the JWS VM somehow gets the session id from the browser, so it is considered Authenticated.
Any ideas?
So far, I haven't found a proper solution to this problem. I did the following, and it worked:
Created a protected area on my server, and added a servlet behind it
My servlet creates a JNLP file on the fly, with a session id.
JNLP file is used to download the JARs from a public location
The session id is used by the web start application to load resources from the protected area.
i am having trouble with my web application developed in GWT. the application allows users to upload and download using an upload servlet and a download servlet, the upload servlet was created using the gwtUpload library. the download servlet is using regular HTTPServlet.
when i run the application within eclipse the download servlet works fine, when i deploy it to tomcat, when a user selects to upload a file, the file does not download, when a user selects a link to download a file, this error is returned
type Status report
message /testhibernategilead/downloadServlet
description The requested resource (/testhibernategilead/downloadServlet) is not available.
can anyone explain why this is
The requested resource (/testhibernategilead/downloadServlet) is not available.
This is the same as a 404 Page Not Found. In other words, the URL is wrong, or the requested resource is indeed actually not there where you expect it to be.
If you are certain that the URL is correct, then you need to read the server logs if the server and the servlets started without problems. If a servlet fails during startup, then it will be unavailable that way.
I think this is due to the application's root directory misconfiguration in tomcat.
You can try adding the module base to your URL like this:
String servlet_url = GWT.getModuleBaseURL()+"testhibernategilead/downloadServlet";
Remember: GWT.getModuleBaseURL() puts a "/" at the end of the returned string.