My primary concern is someone co-opting the signed Jmol applet in order to
surreptitiously transfer files from the user's machine to a server. That is
considered a very big security issue. So in Jmol it is set up to always
throw up a dialog, and the equivalent on the HTML side is to have an <input
type="file"> tag that requires user input as well. Provided we work within
those restrictions, we should be OK.
What the new security of FF3 has done, in my understanding, is to not allow
a server access to the local file path to a file. The server can get the
data, but it cannot browse a directory or even find the directory name of
the file that is to be transferred.
It does pose a problem, I know. If you use the input tag, you can only send
the information to the server, not to the applet, and if you use the
applet's own dialog, you can read the file but not send it to the server! It
is this "read the file AND send it to the server" that is the problem.
I believe you should be able to do this with a little Ajax. It would go:
1) Jmol loads file from its dialog
2) Jmol passes file data pointer to JavaScript
3) JavaScript uses an AJAX call to send data to server
4) AJAX call returns with data for Jmol (possibly) or display as an image
(for example)
Now, the problem, I think, is that there could be limitations on how much
data is transferred depending upon the browser. Is that the issue?
The way to do this now is simply to use the INPUT tag with type="file" to
send a file to the server and then have Jmol pick up that file. But that
requires intermediate temporary storage on the server. And it doesn't allow
local file handing. Still not great.
So, let's see...
The signed applet does not have access to the function "getAbsolutePath" any
more than the browser does. I'm pretty sure that's true. So you no longer
have access to exactly where a file is.
jmolGetPropertyAsString("filecontents") , ah, yes!
You have to realize that Jmol is using a VERY special trick to read files
from the hard drive. Basically, there is one thread and one thread alone
that can do that -- it's the one that started the applet. So when the applet
is started, Jmol creates a special thread from that that waits for commands
that involve load and uses THAT thread instead for that. The thread that
runs JavaScript cannot do this. So when you use functions like that from
JavaScript, you get that security violation. I won't mention how many hours
and days it took me to figure that out! But it's definitely the key to how
the applet works. We can load files from the local drive specifically
because we are loading them as scripts and files to display using that
special mechanism.
So then the only thing we really need is a way to make sure that you are
reading the file properly.
Do try this:
http://chemapps.stolaf.edu/jmol/docs/examples-11/s.htm
click first the html link "test load" on the bottom right.
Then click the link "test show".
What these do is
a) load the local file data into a variable.
b) create a model from that variable data rather than from the local file
itself
c) show the contents of the variable in JavaScript.
I think this should be all you need.
Bob
Bob
On Mon, Feb 22, 2010 at 11:13 AM, Rolf Huehne <[email protected]>wrote:
> On 02/22/2010 05:34 PM, rob yang wrote:
> > Rolf, I did look at Jena3D before to see if someone else has already
> invented the wheel, but from what I can tell, Jena3D uses the browser file
> tag to upload to the server 1st, and then displays jmol applet loading these
> files from the server. So in other words, I thought it was a
> "browser->server->jmol" pipeline. But if I didn't read it right, I am
> curious to hear more about the "Jmol->browser->server" implementation that
> you are referring to.
> Yes, you are right. For file upload Jena3D uses "Browser->Server->Jmol".
> This is necessary to allow local file viewing with the unsigned applet.
>
> The "Jmol->Browser->Server->Browser" pipeline is used for getting a
> snapshot of the current view from the unsigned applet into the browser.
>
> The problem here is to display the snapshot in the browser, so that the
> user can save the image manually.
> The command 'jmolGetPropertyAsString("image")' generates a base64
> encoded JPEG image and puts it into a Javascript variable.
> Firefox and other browsers could display this image directly, but not
> IE. Although there are also workarounds for IE I prefered installing a
> single reliable method for all browsers. So the Javascript variable is
> actually a form parameter. And after Jmol generated the image the form
> is sent to the server. The server decodes the base64 and sends back the
> plain JPEG image which is displayed in the browser.
>
> So what is needed is a form definition. Then the parameters must be set,
> especially the image data. And finally the form must be submitted.
> This all happens within the "onClick" definition of the "snapshot"
> button within Jena3D:
>
> <input class="jmol" type="button" id="snapshot" value="snapshot"
> onClick='document.getElementById("bounce_image").target=Math.random();
>
> document.getElementById("IMAGE_DATA").value=jmolGetPropertyAsString("image");
> document.getElementById("IMAGE_WIDTH").value=jmolEvaluate("_width");
> document.getElementById("IMAGE_HEIGHT").value=jmolEvaluate("_height");
> document.getElementById("bounce_image").submit()'>
>
> > Namely, I wonder if the route of passing the file contents of jmol to
> browser and then browser to server is do-able.
> >
> So you would have to replace the command
> 'jmolGetPropertyAsString("image")' by a command to get the file content.
>
> If you were lucky it would be 'jmolGetPropertyAsString("file")'. I don't
> know it. But I am rather sure that there is some way to get the file
> information into a Javascript variable.
>
> The only problem I observed here was the data size. There seems to be
> some system dependent security restriction in the amount of data
> transferred from Jmol to the browser.
>
> Regards,
> Rolf
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Jmol-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
