I am running Tomcat 5.0 and I have problem with getting a resource from tomcats 'webapps' from Java. There is a html file that I check if it's available after server start in
tomcat_folder/webapps/myProject/site.html
In Java I run this code when server is started:
URL url = new URL("http://localhost:8080/myProject/site.html");
URLConnection con = url.openConnection();
Object content = con.getContent();
getContent() throws FileNotFoundException.
But when I put "http://localhost:8080/myProject/site.html" into browser, the site is displayed without problems.
Also I tested that on 4 machines - on 2 everything is fine, on other 2 FileNotFoundException.
I thought it might be some folder security access problem or user rights, but in the end I have no clue. Any suggestions?
Assuming you are on windows. You may need to add java.exe to your virus scanner / firewall to allow it to make out bound network connections.
If your code is in servlet then you can get the real path of your servlet and then append the file name to it.
String servletPath = getServletContext().getRealPath("/");
URL url = new URL(servletPath+"site.html");
For normal java application you will need the entire path to the webapps folder of your tomcat installation.
Your code seems to be correct.
but you missed to actually connect
con .connect();
before trying to getContent
I found the solution to my problem.
The cause was a windows service using port 8080, which was also in use by Tomcat. Resource was available through browser, but not from Java code.
After stopping conflicting service everything works as it should now.
Related
I have a Java web app which has a JSP page which has a couple c:import lines in it. The content referenced is on the same web server as the Java app, but is not bundled in the war file. My site has dns entries to allow for access to this app from a browser with a full name https://abc.123.def.com/app or a short name of just https://abc/app for users on our network.
If I access the jsp page via the alias https://abc/app I can get to the jsp page in the browser, but I get a server exception Problem accessing the absolute URL "https://abc//webfiles/included_file.html". java.net.SocketException: Connection reset on the page. But, when I access the jsp page via the fqdn like https://abc.123.def.com/app the include works perfectly, the jsp compiles, and all is well.
If I put the address of the file to be included in my browser it works with either short name or fqdn. So even though the error is saying the JSP can't find the file https://abc//webfiles/included_file.html I can plug that address in my browser and get to it fine. That's true from my separate user machine, or from a browser on the server itself. (Yes I see that double // there, it seems to not be a problem, it loads in the browser and loads fine as an include when using the fqdn).
I have good reason to believe the code is fine, this code worked fine on my old server which had JBoss 5. We've moved it to JBoss 6.4 on a new server and are now encountering this alias/short name include problem. I'm thinking it's some JBoss or IIS configuration issue. Of course we have lots of external links to this application utilizing the short name so simply using the fqdn will not work.
So IIS can serve up both the jsp via a fqdn or short name, it can also serve up the included_file path using the fqdn or short name. But Java for some reason can't see that included_file when using the short name, only the fqdn.
I've confirmed that the DNS suffix search list in the server's ipconfig includes the domain the site is in.
I'm not a JBoss config admin, and have no experience with IIS really, just a developer of the app, but I've been thrust into JBoss config/debugging out of desperation. Any help much appreciated.
PHP doesn't get parsed when I try to run the PHP page. I am using NetBeans and running Apache Tomcat as the server. I have defined the interpreter for PHP which is shown in the following snapshot:
If I try to run the PHP page from within the IDE (by using the default shift+F6), it runs, but with a URL file:///C:/Users/user/AppData/Local/Temp/php_1.php11992.html for a file named php_1.php. But when I try to test the URL localhost:8081/app/php_1.php, the PHP in the page isn't parsed, and I see only the HTML getting parsed.
What could be the reason for this? What do I do to parse PHP directly ?
Note: I have installed XAMPP, and the path I give in the above snapshot is of the PHP interpreter that comes packed with the XAMPP package.
Ensure that the tomcat webserver is stopped and the XAMPP server running, since there could be a conflict (of ports, URIs etc).
If XAMPP is running and it still doesn't work, you can try the following:
Ensure the webserver has the type set in conf.d:
AddType application/x-httpd-php .php .php5 .phtml
Also, if you are using short tags make sure it is enabled in php.ini
Make sure mod_php is enabled in XAMPP (should be by default). You can do this by navigating to httpd.exe in XAMPP and typing httpd -M which will list currently used modules.
Is there a way to retrieve the absolute path of url (http://localhost:8080/myApp) in java. The scenario is, i need to connect to csv file located in tomcat server. The statement works well if I enter the absolute path, but is there a solution to retrieve url's path using getAbsolutePath().Sorry if I'm wrong.
Connection conn = DriverManager(getConnection("jdbc:relique:csv:/home/apache-tomcat-6.0.26/webapps/myApp/"))
Thanks in advance.
You can use ServletContext.getRealPath(), which does exactly what you want.
Note that it does not necessarily work in all situations. For example, if your Tomcat is configured to deploy the .war file without unpacking it, then this will return null.
I don't know much about JAVA.
May be getServletContext().getContextPath() is something you are looking for
EDIT:
Or may be getRealPath()
Tomcat is not a http server. All tomcat urls reference services, not files.
You'll have to implement another service that sends the csv file on request, if you want to get it through any http URL. URL's like http://localhost/myapp/input.csv require a http server like apache httpd.
(Hope I got your question correct...)
I have a Java Applet inserted on a simple HTML page located at http://localhost:8080/index.html:
<applet id="applet" code="SomeCode.class" archive="lib.jar" Width="1" Height="1"></applet>
The Java Applet has a method that looks similar to the code below:
public void PostStuffToServer() {
String server = "http://localhost:8080/PostHandler.ashx";
URL u = new URL(server);
URLConnection con = u.openConnection();
con.setDoOutput(true);
con.getOutputStream().write(stream.toByteArray());
con.connect();
}
When I execute the applet code from JavaScript like so:
obj = document.getElementById('applet');
obj.getClipboardImageURL();
I get the following error:
access denied (java.net.SocketPermission 127.0.0.1:8080 connect,resolve)
It seems like the Java code resolves the domain localhost to its equivalent IP address and therefore raises a cross domain security restrain. It works fine when I execute the same code from http://127.0.0.1:8080/index.html. The lib.jar file is signed.
Is there anyway to avoid this?
I encountered the same problem after installing Java 6 Update 22. My applet has been online for several years with no reported errors. When I downgrade to version 6 Update 21, everything works perfect. My applet is not signed.
SOLUTION:
It took me ha while to find the cause of the problem. Actually in my case there were several factors causing the security error. The problem was solved by the crossdomain.xml file. The Java applet tried to download the crossdomain file, failed, and did not even bother to display an error in the java console (debug level 5). Java tried to download the file from the ip adress of my domain (http://ip-address/crossdomain.xml), and not the root of my website (http://domain-name/crossdomain.xml). I guess it is better for the security aspect? I then had to configure the webserver to expose the crossdomainfile on the IP address. In my case I have removed the default website in ISS for security reasons, and had to create a new website. I then discovered that the java applet did not work with the crossdomain files i use with flash:
<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-http-request-headers-from domain="*" headers="*"/>
<allow-access-from domain="*" />
</cross-domain-policy>
I had to remove the site-control and allow-http-request-headers-from nodes from the xml file in order to make the applet work.
I think I'm too late, but anyways... Guys you cannot believe how easy a solution this problem has.
The problem is that Java applet code called from JavaScript has only permissions that are the intersection of the JavaScript's code and your applet code - and somehow the JavaScript's permissions are seen as less, which results in this Exception.
Here is what I did: assume you have a function innocentFunc() that throws the java.net.SocketPermission exception, so your code is something like so:
String s = innocentFunc();
Now what you can do is to change it to something like so:
String s = AccessController.doPrivileged(
new PrivilegedAction<String>() {
public String run() {
return innocentFunc();
}
}
);
This AccessController call basically states to the Java Virtual Machine that the code it runs should not obey to the permissions from the call chain, but rather only the caller's permissions in its own.
Of course, you should do something like this only after making sure that this innocentFunc call can't do anything bad, even if invoked by malicious code.
Just to add, there's some stuff here which exactly matches the issue I've been getting - it specifically mentions controlling an applet with JavaScript.
http://www.oracle.com/technetwork/java/javase/6u22releasenotes-176121.html
The fix for CVE-2010-3560 could cause
certain Java applets running in the
new Java Plug-in to stop working if
they are embedded in web pages which
contain JavaScript that calls into
Java in order to perform actions which
require network security permissions.
These applets may fail with a network
security exception under some
circumstances if the name service
which resolved the original web page
URL host name does not return a
matching name as the result of a
reverse address lookup.
Their suggestion is to add a special crazy just-for-Java A record to the DNS, like:
10.11.12.13 foo.bar.com.auth.13.12.11.10.in-addr.arpa
I'm getting the same thing with Update 22, and not Update 21.
I'm using the TinyPlayer applet, which I'm controlling via JavaScript.
I'm loading audio files from the same domain (mydomain.example.com, IP 1.2.3.4) as the page the applet is loading on - everything is referenced using relative URLs.
When I try to play the audio, it fails to play and I get:
access denied (java.net.SocketPermission 1.2.3.4:80 connect,resolve)
Looking at the access logs, I get a request for crossdomain.xml right before this happens. But the catch is that Java isn't asking for a crossdomain.xml from
mydomain.example.com/crossdomain.xml
...but instead from
1.2.3.4/crossdomain.xml
The workaround that seems to work for me is to set up a virtual host that responds for the IP address 1.2.3.4, and give it a crossdomain.xml, so that Java can find the crossdomain.xml in the (wrong) place that it's looking for it.
I just tested with the contents:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
...but it's probably possible to make this more restrictive.
With that in there, the audio plays correctly.
IIRC, the JavaScript same-origin policy prevents access to same-host/different-port. The PlugIn's LiveConnect enforces this policy for localhost only.
See: http://download.oracle.com/javase/tutorial/deployment/applet/security.html
Unsigned applets can perform the following operations:
They can make network connections to the host they came from.
If Java does not resolve the originating system to localhost then the applet will not be able to open sockets.
I had the similar issue and it only occurs when I use the "localhost" as a part of the URL for the page with the applet. When I used the URL with the actual host name or IP address as a part of the URL, the problem didn't happen. I am not sure this is a defect for the Java plug-in...
For example when I used the URL like http://localhost:9080/app_id/appletPage the problem occurred but when I use the URL by using the actual IP or host name, the problem did not occur.
I don't think is possible to made the crossdomain.xml file more restrictive, at current time Java applets only support the (domain="*")
see here http://www.oracle.com/technetwork/java/javase/index-135519.html#CROSSDOMAINXML
You should check your virtual directory permissions.
Update from #Kristian above saved my day.
I had access denied (java.net.SocketPermission <server_ip>:<server port> connect,resolve) from an applet in a web application.
There had been change in our DNS, such that the IP of the load-balancer of the application server was not resolving to a name with domain. Therefore the suspected "cross-domain connection" from applet back to server was blocked.
I added crossdomain.xml with
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
to <tomcat-home>/webapps and checked that it is accessible with http://<server name>:<server port>/crossdomain.xml
I am working on a webbased application with servlets and JSPs in it. My requirement is to get the path of a file which is uploaded in my application.
The legacy code used to get the name of the file by using the code -
//FilePart class of the com.oreilly.servlet.multipart package.//
FilePart filePart = (FilePart) part;
screenosInputFileName = filePart.getFileName();
The getFileName returns the name of the file correctly as a string like "a.txt". Since I want the path also, I am using getFilePath as in--
String path = filePart.getFilePath();
However, I find that getFilePath is only returning the file name and not the file path. That is, getFileName and getFilePath are returning the same value "a.txt". What I was expecting from getFilePath was something like c:\myfiles.
Also, I am running my application in an Ubuntu enviroment (a linux flavour).
Any ideas why getFilePath is retuning only the filename and not the file path ? And how to overcome the problem. Any pointers higly appreciated.
Note: I am not familiar with com.oreilly.servlet.multipart.FilePart.
If FilePart represents the file on the client, then it is impossible to get the path of it (there is no reason for a server to know whether a.txt was uploaded from C:\Users\bob\ or from /home/bob/Documents/, so that information is not included).
If FilePart represents the file on the server (if your server saves uploaded files to a temporary directory so that you may access them as actual files), then you should be able to use this to get the actual path to the file:
String path = new File(filePart.getFilePath()).getAbsolutePath();
I hope this was helpful!
It used to be that Internet Explorer would include the full path of the file on the client's computer. I don't know if it does that anymore, but i don't think so, because it's a privacy issue. The server has no business knowing the full path.
getFilePath is only going to work if the client is using Internet Explorer, as it's the only browser that returns the entire file path to the server. Chances are, it'll only work with IE6 at that, as I believe MS finally realized this wasn't a good security practice when IE7 came out.