I'd like to create a service where people can enter external websites, after which the returned source will be modified by my application (for whatever purpose) and then returned to the user.
One would normally redirect all traffic through the server, so that the server is the one accessing the external source. This is because HTML5 and flash sockets cannot access external sources unless the external source has the required policy files (please correct me if this is false). Even if the user wants the client to, it still can't access these external sources if the external source itself does not have such policy file.
My question is: can a Java applet access an external source regardless of it's policy file, if the user allows it to? How is this usually done?
If not, is there anything else I can try? Redirecting all traffic through my server is not an option because of 1. high use of bandwidth and server resources for a free service and 2. a high chance of my server being marked as a spam bot or bandwidth hogger.
Thanks in advance.
Regards,
Tom
If choice of technology is not a problem you can use a Java Web start application.
Your application will be launched from a web page (if that is what you want)
After user-confirmation your application can do everything (similar to native apps)
I have actually done this with a Java web start application that used web services from servers other than the one it was launched from.
Related
As a kind of personal project, I'm trying to develop a Java Applet that will stream from a collection of music that I will host on the same machine as the applet. I know when you request files in an applet, it looks for them in the files of the computer which is accessing the applet. I, however, want to access files that are hosted on the same server as the applet.
My intention is to, when the client wants to stream a specific song, the server will begin loading the data and streaming the data to the client. I think this would be possible using the URL class in Java, but would that not be going out to the internet only to come back to the very same server to get its files? Or will it recognize that the files are local and access them without going out to the web?
Summary: What is the best way for an applet to access files that are hosted on the same server as itself?
An applet runs on the client machine. In order to access files the server you're going to have implement functionality on the server-side to expose those files to your client. There are various ways to do this in Java - the most common would be:
1) a custom servlet or
2) a web service
Here are some links to articles which could be helpful:
Can a web service return a stream?
FileServlet serving from absolute path
As an aside I think your question is quite broad. You're probably going to have to investigate one or both of the methods above, try to implement one of them and then come back to SO with more specific questions.
I have a web application running with support for some specific pieces of hardware. This is achieved in the following steps:
User runs a small installer that places java files (and a couple
others) on the client machine. The main piece is a jar called "hardwareManager"
User visits web app. The web app runs a java applet which, due to
a .java.policy file placed during the install, has permission to
interact with the client machine outside the browser sandbox.
The applet checks to make sure the hardwareManager is running,
and if not runs a command to start it.
User interacts with the web app which sends commands to the applet via
javascript. The applet then writes commands to a text file
on the client machine. The text file is constantly monitored by the
hardwareManager which runs any commands it reads in.
This works, but seems clunky. I have a couple ideas on how to improve it, but I don't know which, if any, are even worth trying.
Would it be better to set up the hardwareManager as a socketServer and have the applet connect directly to it, rather than going through text files? Is that even possible?
Is there a way to eliminate the applet altogether and have the javascript talk directly to the hardwareManager? Maybe by writing the hardwareManager to be a local http server? What port should it run on? Do javascript xss limitations fit in here somewhere?
It would be less clunky to start the Java application using Java Web Start. This would remove the need to daemonize or install the Java hardware manager.
Another alternative is to use a built-in browser inside Java. I supose this is not an option, since you depend heavily on Javascript (I suppose to provide a rich client experience).
If you already have to install something on the client machine, why did you make the choice to go with a web application?
Talking from experience: We had a Java EE application which needed to print to PoS printers at the client site. We installed a small "synchronizer" application that connects through SSH and synchronizes all clients files. Afterwards, it loads the JAR and executes the program. This program connects through RMI with the server and subscribes to a JMS queue to receive the print assignments.
Applied to your case: Why not let your Java application connect to the server directly? You can use HTTP, SOAP or even JMS over RMI. You can then launch the hardware command from the server (instead of from the limited JavaScript webbrowser environment). This way, you get tons of features: authentication, buffering of commands, and you can even share hardware between multiple clients.
Schematic:
<----AJAX------> Web browser
ApplicationServer
<---HTTP/SOAP--> Java hardware manager application
You can launch the Java application using Java Web Start, which allows you to update the application automatically (instead of needing to pass every client a new installer).
I need to load somehow the html code of a webpage A into a javascript string of another webpage B, on a different host. I know this is impossible to do with javascript alone because of the same origin policy, and I know I could do it loading the page via php on my server and then send results back to the user's client but I wouldn't be able to handle so many requests, so I need it to be done directly by the user's browser. I can use nearly whatever browser scripting language/applet framework common enough to be installed on the majority of my users' computers, like flash and java.
On example, what if I use flash or java to load the external html code and then call a javascript callback function providing the source? Could this work?
Do you have ANY idea? I gratefully accept any suggestion, and I REALLY appreciate examples!
Thank you very much!
Matteo
It would require a digitally signed and trusted applet in order to reach cross-domain, short of the user running a plug-in 2 architecture JRE and the site implementing a Cross-Domain XML.
Ordinarily, unsigned Java applets or applications may only connect
back to the web server from which they originated. This restriction
prevents an applet from causing denial-of-service attacks by making
rapid connections to arbitrary machines on the Internet.
In Java SE 6 update 10, both the Java Web Start and Java Plug-In
technologies contain preliminary support for cross-domain policy
files, which specify how unsigned code may access web services on the
Internet. The crossdomain.xml policy file is hosted on a given server
and allows either selected clients, or clients from anywhere, to
connect to that server. Cross-domain policy files make accessing web
services much easier, particularly from unsigned applets.
"via php on my server and then send results back to the user's client but I wouldn't be able to handle so many requests"
So many requests? That is not so many reqs; just making php script to read couple page and creating new page depending the data. If that is too much for your server ..hard to believe.. you sure can do that kind of thing with flash (clients computer) to load those two pages, and parse the datas to one html page and display it (via js) to clients browser. Kind of weird question after all.. perhaps i did not understand it :)
I have never used JNLP, and I have no web/war server already running so I will install it from sratch:
Which to use?
GlassFish
Tomcat
Apache
Jetty
Another?
I wonder if someone already using JNLP could make any recomendation for the server.
I just want a blank page with a button in the middle for starting the application nothing more, nothing less.
If you use only JNLP you don't need Java server. JNLP is client side. Simple http server like Apache HTTP Server should be OK. HTTP server will be better solution than use of web container/Java EE server because JNLP (usually) is a static content. Even lighthttpd should be enough.
As already stated any server capable to serve HTTP will do. If your WebStart application is not signed by itself (i.e. you code-signed the corresponding Jar files) you could probably consider to publish the JNLP plus its resources via HTTPS. This way your clients will know that the software they are going to execute came from its rightful origin. Although unsigned WebStart applications are restricted in their privileges on the client's machine it still is a measure to elicit trust in your clients. On the other hand this requires more configuration effort with regard to the server you chose.
If your application will need some extended privileges on the client's machine such as access to the file system then I would recommend that you do sign your jar files to gain the necessary privileges automatically (don't forget to specify them in a element within your JNLP).
These are the default restrictions for unsigned WebStart apps:
No access to local disk.
All your jars must be downloaded from the same host. Note, however, that you can download extensions and JREs from any host as long as they are signed and trusted.
Network connections are allowed only to host from which your jars were downloaded. ("Phone home restriction.")
No security manager can be installed.
No native libraries (not even in extensions).
Limited access to system properties. (The application has read/write access to all system properties defined in the jnlp file, as well as read-only access to the same set of properties as applets
You dont need a server to run JNLP(Webstart).. This is how webstart works
it simply is an application that can be started over the web, this would be the procedure from the user perspective:
user goes to yourwebsite.com
user see's link: run my awesome app
user clicks link, which downloads .jnlp file
user runs the jnlp file through java web start (part of java SE, user requires java runtime environment JRE to run this)
java web start reads jnlp to get information about the server that holds the corresponding application
jar files get downloaded automatically (the first time) and then the application starts
user gets bored and closes application
the next day, user comes back and clicks your link again
application is already downloaded, so it starts right away
user gets bored again and closes your application
1 day later, you decide to update your application and you deploy the new jar file on your
server, replacing one of the old files
after 2 days user clicks your link again
java web start recognizes that the user has a different version, downloads update automatically and starts the application again
...
..
.
One of my requirements is, on load of page, a file is to be created dynamically and downloaded at a particular location on the client's machine.
In case the file is already present, it has to be over written.
is there any way where we can access the client's system and store the file at the required folder?
I feel one cannot access the client machine when the code is being executed on the server..
Senorio:
1-User click on generate document then it took template stream data ,req. data file and then save two file into client machine.
2-After that template open and it fetch the data file from same directory.
Please help me on this. This is an SOS!!
There are probably other solutions, I use a signed applet for this purpose.
As always, there are a few caveats though:
You can't "force" anything against the will of the user. Applets may be disabled in the client's browser, or they may not even have Java installed. Or the target directory might not be writeable by the user.Your server should handle cases where the client doesn't have the correct version of the file gracefully.
You can't do this from the server side obviously but you also really can't do this from a client script either. Browser security will prevent a page script from modifying contents of the file system.
Your only options will be to run a third-party browser plugin software that has elevated permissions.
Examples of such are
Java Applets
Java WebStart
Microsoft Silverlight
ActiveX
Each one is different and most require some level of user interaction to confirm that they allow plugins to run with elevated security.