Zero-installation least steps ideas/solutions

Alk · May 5, 2011 7:48AM

Hi all, I am looking for solutions to make the zero-installation free viewer open a specific iok with the fewest clicks/steps for my scenario below. Installing Omniscope is not an option at the moment for the end user due to admin/security settings.

I have access to a private online file sharing/project management website where users can login and download files (protected by individual username and passwords and HTTPS/TLS certificates) where I upload my iok files for distribution. E-mailing the iok file is also another option.

I have thought of one solution below, but it requires too much user interaction for my users;
(after uploading Omniscope.jar and the iok to the private website)... download Omniscope.jar file, download the iok, open Omniscope.jar, click Open file, locate the iok and double-click it.
Whenever the user wants to see the iok, they have to open Omniscope.jar, click Open file, locate the iok and double-click it again.

I have tried to use the link-builder tool to upload the .jnlp file to the private website and automatically run the iok, but when the user runs the .jnlp, Omniscope free viewer says the iok located on the website is corrupted (probably because it is located on a secure website, although the user is logged in via the web-browser).

Does anyone have suggestions of how to make the process easier for the end user? I would ideally like one file which the user has to open which will run the free viewer and iok.

Some solutions like the following would be good:
a) Integrating the .jnlp or .jar file with the iok so all the user needs to do is double-click one file or URL to open and run the iok
b) Getting the .jar file to automatically run the iok without the user needing to click open and locate the iok
c) Double-clicking the iok file which will cause the .jar or .jnlp file to run and open the iok (similar to how it works with the installed Omniscope)
d) Making the .jnlp file download the iok from the password protected/secure site (of-course, the .jnlp cant have passwords, but the user will be logged in to the site when clicking the .jnlp)

Many thanks for any ideas/solutions.

steve · May 5, 2011 9:37AM

Omniscope Online is clearly the best solution. If the IOK file is hosted using HTTP authentication over HTTPS, it should be quite possible to have a 1 click (in total) solution using Omniscope Online (web start).

Set up a test account with some sample files for us and we'll have a look at what the issues are.

The only other solution I can think of is to create a JAR file containing the IOK file in addition to the Omniscope Viewer, but this would be ~ 20mb and would require development to get the file to open.

Alk · May 5, 2011 10:41AM

Hi Steve, thanks for the reply.

I do not know much about web security, but would HTTP authentication over HTTPS hinder security? Also, if the user requires a username/password to logon in order to download the iok, would Omniscope Online still work? There is not much flexibility with changing the back-end of the resource I use to share the files unfortunately as it is using another service I do not have much control of.

I have tried to replace the https://... with http://... for the iok location in the link-builder to no avail - the end result is the same (corrupt iok message).

Yes, I agree, the disadvantage of the jar file would be a larger download and a more complicated process. Do you have any guidance manuals as to how users would go about doing this (assuming it doesn't break any EULAs)?

steve · May 5, 2011 11:04AM

It sounds like your service is using some other authentication mechanism and the server is sending back a login page rather than IOK binary data. You can test if HTTP authentication works by using "https://username:password@domain.com/path/to/file.iok".

HTTP basic authentication over HTTPS is as secure as HTTPS. The SSL/TLS encryption of the transported data includes the HTTP basic authentication details. So it's fine to use from a security perspective (providing you're using HTTPS).

The JAR file idea is not one we wish to promote, and would require development on our part. An variation is to write your own Java app to extract the Omniscope JAR and the IOK file and launch Omniscope, using the IOK as a single command-line argument.

Alk · May 5, 2011 12:23PM

Hi Steve,

It looks like HTTP authentication is disabled then, as the username:password... does not work. I've asked the host if they can do anything and am awaiting a reply from them.

Is there a command-line argument/parameter which I can add to the IOK which will cause the JAR to open the actual IOK rather than only open the JAR file? Or is there something within the JAR file such as properties which will open the IOK which I can embedded in the JAR?

Extracting the JAR and IOK and launching Omniscope and the IOK will not work because the IOK has no file association with Omniscope so Windows comes up with the "Windows cannot open the file" prompt.

Thanks for the continued support.

steve · May 9, 2011 12:40PM

From tonight in 2.6 b623 or later, you will be able to embed an IOK file and have it open automatically when you double-click the JAR file. Thus creating a one-stop-shop bundled "viewer + data" executable JAR.

You will need to call the file "default.iok" and embed it in the root of the JAR file (a JAR is a renamed ZIP file).

Post back if you get this to work.

(Note: The JAR file's digital signature may become invalid, which will cause warnings if you try to host it using Java Web Start, but not when double-clicking a downloaded JAR file. If you wish to host it using Java Web Start, you will need to obtain a code-signing certificate and sign the JAR file yourself.)

Alk · May 10, 2011 5:20AM

Steve, that's fantastic. Just tested it now and it's working exactly as I'd like it to.

Thank you very much for your assistance and adding the new feature. Always pleased with the quick implementation of new features with Visokio.

For some reason, when replacing the AppSplashImage.png with another png file, it's a black block rather than what it would show in Omniscope, but its no major problem, I can live with that.

Thanks again :)

steve · May 10, 2011 8:24AM

Glad to be of help. Not sure what you mean with AppSplashImage - post a screenshot and the PNG you are using.

Alk · May 10, 2011 9:36AM

Hi Steve,

Please find attached a PNG I tried to use as a splash-screen and a screenshot with the PNG in the installed Omniscope's "C:\Program Files\Visokio Omniscope\Branding folder" working as it should, and the other screenshot with a black rectangle which is what I see when I replace the AppSplashImage.png within the jar file - the "Omniscope.jar\branding\" folder in order to try getting a custom splash-screen.

steve · May 10, 2011 2:40PM

Could it be a case sensitivity issue with the image filename?

Alk · May 11, 2011 4:47AM

No, the filename (including case) are exactly the same as that of the original AppSplashImage.
I have also tried to open the default AppSplashImage, add a tiny dot within it in MSPaint and save it back into the Branding folder, but that also results in the black rectangle splash-screen, so the dimension/number of pixels should also not be affecting it.

steve · May 11, 2011 6:46AM

Alk,

The reason this happens is that Omniscope.JAR is digitally signed, but the image has been changed. The different signature is detected by Java and assumed to be tampering, so the image cannot be loaded.

We sign the JAR to allow it to be run with full permissions from Web Start without warnings. Since your users are downloading and double-clicking the JAR, the signature isn't required.

To remove the signature:
- Edit the META-INF/MANIFEST.MF and remove all but the header lines - everything after "Main-Class: Start".
- Delete the VISOKIO.RSA and VISOKIO.SF files.

It seems that adding files (such as default.iok) to the JAR don't cause a problem, only changing existing files.

Steve

Alk · May 11, 2011 7:22AM

That's great Steve, it works.
Thanks.

On another note, I've noticed by using your instructions to remove the signature, the start-up time for the no-install version of Omniscope (including loading my default.iok) has reduced from 45seconds to 15seconds.
Sweet!

tommyc · June 2, 2011 12:04PM

Hi Steve,
This is in response to your post "From tonight in 2.6 b623 or later, you will be able to embed an IOK file and have it open automatically when you double-click the JAR file. Thus creating a one-stop-shop bundled "viewer + data" executable JAR."

We are interested in sending out a self-contained player & file as described there, but do not know how to do that within Omniscope. What is the process of doing this?

Thanks.
Tommy

steve · June 3, 2011 4:43AM

We don't officially support this approach, but have made it possible if you are willing/able to engineer it.

Instructions:
1. download Omniscope.jar for the version you want from the download page
2. rename to Omniscope.zip
3. open in a zip program such as 7zip
4. edit the META-INF/MANIFEST.MF and remove all but the header lines - everything after "Main-Class: Start"
5. delete the VISOKIO.RSA and VISOKIO.SF files.
6. add the IOK file you want to embed as "default.iok" in the zip root
7. optionally, apply rebranding as described here, merging the branding folder with the one in the zip: http://www.visokio.com/kb/rebranding
8. close the zip program and rename back to Omniscope.jar

This will only work for downloading and double-clicking on a system with Java 5 or later installed. For web start use, this will not work without digitally re-signing the JAR.

You should be able to automate this yourself if you need to produce a daily file, for example.

Let me know if I've missed anything.

tommyc · June 3, 2011 9:09AM

Thanks Steve! I will let you know if I come across any snags.

tommyc · June 3, 2011 4:32PM

Worked perfectly. Thank you very much!

tommyc · June 7, 2011 3:24PM

Steve... everything worked great and I love the fact that you can do the rebranding as well. The one question I have is in the "automation" process you mentioned. You are correct in that we are always using the daily builds for our desktop installed Omniscope app, so any time we would want to produce a "zero-install embedded data" file we'd need to use the daily build of the .jar file. How would I go about automating it? Essentially I'd like to be able to have the daily build data refresh but not overwrite our rebranding and keeping the Manifest.MF empty along with removing the RSA and SF files. Thanks in advance.

steve · June 15, 2011 6:34AM

Sorry for the delay responding. So, you want to automate injecting the latest IOK file? Do you also want to automate getting the latest JAR from our website, or do you want to stick to a trusted/known version?

tommyc · June 15, 2011 11:36AM

Thanks Steve... Never thought about automating the injection process, but I'm sure people here might be interested in simplifying the process, even though I think it's fairly straight forward of adding the default.iok to the zip file and then renaming as jar.

But the biggest time saver would be to automate the process of me d/l the daily build from the site, swapping in the branding folder that contains our rebrand info and the stripped out Manifest.mf file.

steve · June 16, 2011 4:08AM

WARNING: for the benefit of other readers, as Tommy pointed out in another post, there is a major flaw with this approach: memory allocation. When you execute a JAR file, it uses the default limit of 128mb, which is inadequate for all but the smallest IOK files.

This is one of the reasons we do not officially support this approach.

It is possible to develop a fix for this, whereby upon double-clicking the JAR file will re-execute itself with a larger memory allocation.

An alternative solution would be to bundle the existing JAR file (with or without branding customisations), and the IOK file, and a bootstrap Java class file, into a 'parent' JAR file. On double-clicking this, the embedded JAR + IOK would be extracted to a temp folder and launched with correct memory allocation.

Both of these approaches would require bespoke development.

steve · June 16, 2011 4:12AM

Regarding automating this process - as this is not something we support, you will need to build this yourself, but I can give you some tips. I'll leave this until you ask for it (given the memory issues you may not need this).

steve · June 17, 2011 6:09AM

Tommy, is resolving this a key issue for you? We are considering the "alternative solution" listed above.

tommyc · June 17, 2011 1:12PM

Hi Steve, I think the key issue is the memory allocation as opposed to automating the updating of the daily builds, etc. To be able to have a rebranded JAR with an embedded IOK that is launched with the correct memory allocation would be ideal as described in the alternative solution.

I know the only other limits of the webstart deployment that would be to ideal to have would be the ability to see web views and the ability to export to PPT.

Thanks for following up.
Tommy

tjbate · June 17, 2011 2:14PM

Tommy-

Limitations imposed by Web Start mean that Web Start-deployed free Viewers cannot directly export PPT files, just as they cannot directly export XLS files. They CAN however, export CSV files (if empowered to do so) which can be opened in Excel.

Similarly, although they cannot export images directly to PowerPoint, they CAN export the image of any tab as image files in open formats such as JPG, GIF & PNG...all easy to paste into PowerPoint.

Just open any IOK file in a Web Start deployed free Viewer and go File > Save screen image (or just press Ctrl+Shift+P)

steve · June 17, 2011 2:35PM

Note that while PPT isn't available from the JAR/Webstart, PDF *is* available.

steve · June 17, 2011 2:39PM

Tommy, regarding the memory allocation issue, we are looking into providing a fully supported system for this approach as per alternative solution, including a tool to do the packaging for you. Please watch this space.

tommyc · June 17, 2011 3:12PM

Excellent... thank you very much for the hard work.

steve · September 30, 2011 12:51PM

See here:
http://forums.visokio.com/discussion/1030/custom-executable-jar-2.6-
(restricted to alpha-partners)

	AppSplashImage.png	142K
	Splashscreen jar file.PNG	44K
	Splashscreen Omniscope.PNG	54K

Welcome!

Categories

Ideas Parade

Tagged