Using an applet embedded in html page to communicate with database - java

I have created an applet that communicates with a MS Access database (or at least, it should). It works fine when I run it through Dr Java or NetBeans, but when I embed the .class file in an html page and open the html page, it seems to run but none of the changes it is supposed to make to the database actually happen and it cannot retrieve data from the database either. What do I need to do?
Note: the html file, the class file, and the java source file are all on my computer, and in the same folder. The html file is not published or anything, I just created it myself to test the applet.

If you want the database on a server, you need to have it on the same server as the applet is on. E.g. Use Jetty and write a Servlet that communicates with the database via JDBC. The applet then has to communicate with your Servlet, maybe as a web service.

applets run in a sandbox environment . if applet requires access to user system resources it needs to be signed.
package your ".class" files in a jar . have an html file outside the jar that references your jar inside applet tag. then sign your applet jar. see http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html
-----------UPDATE------------------------------
There are two ways of connecting to a database on the server side.
1- The hard way. Untrusted applets cannot touch the hard disk of a computer. Thus, your applet cannot use native or other local files (such as JDBC database drivers) on your hard drive. The first alternative solution is to create a digitally signed applet which may use locally installed JDBC drivers, able to connect directly to the database on the server side.
2- The easy way. Untrusted applets may only open a network connection to the server from which they were downloaded. Thus, you must place a database listener (either the database itself, or a middleware server) on the server node from which the applet was downloaded. The applet would open a socket connection to the middleware server, located on the same computer node as the webserver from which the applet was downloaded. The middleware server is used as a mediator, connecting to and extract data from the database

(Comment by OP on the other thread.)
Could you please explain how the applet can "phone home" to its own server?
I suspect the basic problem with your current approach is that the JRE is getting confused as to whether the DB and applet are on the same 'server'. The first thing to do is stop thinking about folders or directories (or their associated URLs), and do everything, including access the applet, via. your local server. So the URL to the applet should be something like..
http://localhost:8080/the/applet.html
Then make sure all calls to the DB are done through the server as well.

Related

update MDB file remotely from other java web server over http

How to update an MDB file from other machines remotely over the HTTP?
I have 2 machines that are connected by the internet, on the first, I have an MDB file and on the other, I have a java web application, I want to send an SQL query from the java web application to update the MDB file on the other machine over the HTTP.
I tried to use FTP, but it is transferring the whole file b
A file such as word, or power-point or Access?
Well, a horse is a horse is a horse.
A file is a file is a file.
You don't connect to a word file to update it. You don't connect to a Excel file, or a power-point file. And you don't connect to a Access file. You OPEN a file, and THEN modify it. You can't open nor modify files over FTP, nor can you modify them over HTTP either. And you can't even do that with a plane jane text file. These are files - you have to open them to modify them. Or pull a whole copy to one side. Update that file, and then send it back.
So, you don't want to confuse the concept of a simple file, or file based system like say a text file, excel file, or Access file. These are NOT servers or say a service that you connect to. You never open a MySQL file - you connect to a server + service via tc/ip (a socket conneciton) and then send commands back and forth. You NEVER open or touch that MySQL data file. The server updates that file - not you, and not your code.
So, Access is not a server based, or socket connection based service. It is a file based system - not un-like a text file. You don't connect to a text file, you HAVE to open that file - modify it and then save it. You can't do that over http. In fact you can't even do that with FTP either. You can pull the whole file, modify and then send it back to where you got that file from.
Now, you could however setup + create some web service calls or entry points on the one site. You could send that web site some commands, and then code behind on that web site can open up that text file, word file, or in this case the Access file and make changes . But once again, just like MYSQL or say the web server? You not opening the remote file direct - are you? You are (and can) thus setup some code or web methods (even REST ones) that accept commands, and those (even sql update commands) could then be run by that remote server/service and thus update the file on that target system. In the case of Access data files?
If you look VERY close, even a ODBC connection string ALWAYS ALWAYS resolves to a valid windows path name (and a full legal qualified windows path name at that).
so, while there is a ODBC driver, the software driver still in fact uses a standard windows OS file open command against that plane jane file sitting in the hard disk. So to update that Access file, you need the driver - since it knows how to open that file, and how to update the delicate data file structures inside. So, even via ODBC? Well, it not a socket connection and you not connecting to a server on the other end - but in fact opening a simple windows file. In fact this means that you not only require DIRECT file rights to that access data file - but you actually need the windows file system!
However, sqLite is the SAME thing. There are thus some jdbc drivers. This JDBC concept is VERY similar to ODBC, but is for web based systems. You install a library on one end (where sqlite resides), and then that web service can take your sql commands (updates or query pulls), and thus the web site code now opens that local file, executes sql against it, or does a query pull , and then returns the results of your query - and the web query calls are done via that web service (rest calls) on that server. So, you can in theory shuffle commands between two web servers - and there are some types of "drivers" such as jDBC standards that in theory do wind up giving you a similar experience to ODBC.

executing jar in browser

When I am executing a jar file from the browser, is the class file running on the client end or on the server end?
I am developing a security web application where files are encrypted and decrypted. I need this to be done on the client side through a pin which client chooses.
Therefore when an jar file is running on the browser, is the class file where encryption and decryption is done processes on the client end or in the server end?
You can launch the jar file with jnlp ( Webstart) but it will not run on browser. Only a launch. You can execute code In Applet / JApplet, which will be in browser. Depends what you need at business logic.
mostly as matheszabi mentioned what business demands.
you are not executing jar anytime in client end. Via Applet/JApplet you are loading the byte source into browser which then executes your actions. For this you need to have java run time to be installed on the client machine for browser support.
if you are using jsp/servlet model you would understand the java execution is always on the server side.

Is it possible to connect an OutputStream to the download window of a browser fron a java applet?

see, i am developing a web application that downloads files from a server via http requests, but in a case the file isn't in the server but in the applet itself, i mean, some binary content is dynamically generated inside the applet and it must be downloaded. Of course i can use the java libraries to save the file in the client file system (if the applet is a signed one), but i was wondering if it can be done connecting the java OutputStream to the browser's download window, in other words, start a download from an applet.
Am i a crazy person ?
by the way, is it possible to do something similar from javascript ?
No, it is not possible to get around security by attaching the output of an applet to the standard file download mechanisms of a browser.
OTOH, since the Next Generation Java Plug-In, it is no longer necessary to have a signed and trusted applet in order to save files(/bytes) to the local file-system. Chase the links in the Applet info. page for more details. For a demo. of using the JNLP API services (that the plug-in2 hooks into for this functionality) see the File service demo..
You can if e.g. you upload the file to the server and then force browser (via LiveConnect or otherwise) to open that file from the server.
As far as I'm aware, there's no cross-browser way to emulate downloading from within an applet. So you should create that download yourself, and let browser do what it does best.
Obviously, it might well make sense to move the actual creation of the stream to your server side.

Recommended server for JNLP

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
...
..
.

Force Download on client machine

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.

Categories