I am using the blueimp jQuery-File-Upload on SpringSource Tool Suite 2.9.1.
I am trying to redirect from my UploadServlet , but because the option redirect is already
defined (on main.js) it create an error.
how can I redirect from my UploadServlet.java , after the files are uploaded .
In the example code they redirect to results.html , When I try this it upload the files but
after doPost function finish (in my UploadServlet.java) nothing happens & It doesn't
redirect .
please help me and give me an example how to do those thing .
Thanks
Tami
I've been through a similar issue when using the plugin on Google App Engine. Here is the complete working code. May be you'll have slight differences, but I guess you'll find how a Java server have to be done for this plugin to work.
Related
We are trying to use pretender.io to our application which developed in AngularJS, Spring and Hibernate konnectnow.com which hosted at amazon server.
Here are the steps I followed:
Signup at prerender.io and got token: cFeRZcsv3JnAftreuhMO
Checked documentation and understood that I need to install middleware and decided to use Spring one.
In web.xml added pom added as mentioned https://github.com/greengerong/prerender-java
Added !# to the URL in all the pages.
Restarted tomcat server.
Logged into pretender.io with login details and found that nothing getting crawl.
For testing purpose the url konnectnow.com/#!/planpage changed to konnectnow.com/?_escaped_fragment_=/planpage
Nothing comes up, got error page isn’t working.
Checked Crawl Stats at pretender.io and found that as:
Status Code: 505, Cache Hit: Miss, Response Time(sec): 1.51sec, URL:
http://localhost:8080/#!/planpage
Not sure why it takes local host.
Can some one help me how to make this work.
We recommend using html5 push state instead of the #! in your URLs if possible. Html5 push state is better since nothing after a # is sent to the server, which can lead to issues for the crawlers that are checked by their user agent (Facebook, Twitter, etc).
You should set the forwardedURLHeader in order to have the Prerender Java middleware use a different host for your website instead of your proxy URL.
https://github.com/greengerong/prerender-java#forwardedurlheader
I also see that you posted your prerender token publicly so we regenerated your token to prevent someone else from using it. Please find your new token when you log into your Prerender.io account. I've also emailed you there.
I wrote a servlet on eclipse and when i tried to execute it the server gives me the below posted page.
To note: yesterday I executed the same servlet normally i could see the output, but when I tried to run it today i could not. I have not changed any thing every thing is the same.
The status code 404 means that the page is not be found, maybe you updated something in the web.xml file.
You should post contain of your web.xml file here, so that we can see the problem; or you can post the errors from log file if any.
Restart the server and try it.
If it doesnt work then try correcting the web.xml
Im trying to use java applet on my web page. I try/search lots of thing but no chance. So here is the case.
My applet code is simple in app.html :
<applet codebase="." archive="applet.jar" code="de.escape.quincunx.dxf.apViewer" width="640" height="480" name="TEST">
<param name="file" value="40.dxf">
<param name="framed" value="false">
<param name="frameWidth" value="800">
<param name="frameHeight" value="600">
</applet>
This html file is working when i directly open in browser. Its working when i serve it with apache but its not working and give error "Incompatible magic value 21877456 in class file" when i try to serve with IIS. In apache i try php and html, both is working.
Is there any special configuration need on IIS when i try to serve applet?
Thank you for your answers.
I think IIS is not serving the right file for a .class, probably it is returning a 404 error or something similar, since it cannot find the file.
That error means that Java was expecting a .class file, all class files start with 0xCAFEBABE, which is a magic number with which Java can check that the file it is receiving is in fact a class file. In your case, however, the file returned by IIS is not a class file, it does not start with 0xCAFEBABE, and Java is unable to parse it.
The most common reason for it is that the web server is not able to serve the file, often because of a 404 error.
You should check what happens under the hood, search in IIS logs for requests of .class files, or use a tool (maybe even firebug) to see what is returned to the browser.
Finally i found a solution. Actually its not the exact solution but thank you for your answer Simone Gianni. His answer lead me to deeply search in IIS access logs and compare them with APACHE access logs. And yes, both was same and looks like couple of classes are not in place in the JAR file. So apVPORT.class is not in the jar file and developer who wrote this applet leave the calls for those classes in the other part of applet even he is not using them.
If someone can answer the reason why apache don't send any information or "its okey" information to java and continue loading rest of the applet even it see the 404 for apVPORT.class but IIS send 404 to java, this will be the final answer for this question.
Incompatible magic value 21877456 in class file : I found that this error comes when page is not able to reach /read the jar file.
in aspx page -
<applet code="FileAccess.class"
archive="../applet/SignFileAccessApplet.jar" width="325" height="325">
</applet>
in archive check whether url is proper or not by using "pickurl" option provided by intellisense of Visual Studio.
class file path in jar file need to be given in code attribute.
While deploying my app to mochahost, I met the problem between servlet and GWT-RPC communicate. The error shows:
HTTP Status 404 - /403.shtml
type Status report
message /403.shtml
description The requested resource (/403.shtml) is not available.
.war file works perfectly on my workstation, but not working on mochahost.
Any ideas to solve it?
Thanks in advance.
Mochahost have a very good support, try livechatting with their tech department, you will probably have the thing solved.
That's what I do.
Make sure you update live site URL. For instance, generally, on local system you access web app as http://localhost:8080/myapp but, on server it changes to http://[www.]myapp.com. Again, this is just an instance. The point is, the live site must reflect correct URL from code (servlet/JSP/action/etc...) and configuration properties, if any.
Comment 'DirectoryIndex' property in .htaccess file if you do not have any index file.
Comment 'RewriteCond' property in .htaccess file if you do not have any rewrite requirement.
For sure, one of the reason - if client does not accept cookies and servlet does not encode URL.
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