Why has Java Web Start cached this unrelated bit of HTML? - java

I'm developing a new java web start capability for an existing site. All is going well except that one of my test launches, on one of machines has become mysteriously contaminated in a way that is so strange, I'm grasping at straws to explain.
Before the details, some general facts. The script works everywhere else. It fails from this one machine, only when logged in as one particular user. It fails if launched directly from the web, or if the local .jnlp file is launched directly from javaws.
The symptom when it fails is javaws reports "error at line 145", which is itself inexplicable since the jnlp file has only about 15 lines. The smoking gun is that if I use javaws -verbose, I see the following text as the text of the file that failed to parse.
<!--
# Copyright (C) 2009, CyberTAN Corporation
# All Rights Reserved.
#
# THIS SOFTWARE IS OFFERED "AS IS", AND CYBERTAN GRANTS NO WARRANTIES OF ANY
...
plus some suspicious looking javascript. I've determined that this text is what
my router presents when someone connected to the guest wireless network tries to
access the web for the first time.
So my working theory is that once during the testing phase, I booted up my netbook,
accidentally was connected to the guest network instead of the regular network,
managed to access the web jnlp file as the first network access, and got this
page in response instead of the expected.
My question is, where (and why) is this text persisting in the system? I've I ran a search
everywhere, including hidden files, and can't find this text residing anywhere. I've also
flushed javaws caches using the -viewer option.

Do you still see the App in the Java Cache Viewer GUI (javaws -viewer)?
Try to delete the cache at C:\Documents and Settings\[account]\Local Settings\Application Data\Sun\Java\Deployment\cache (or similar, assuming you're using Windows)...
Here's some additional info: http://www.ngs.ac.uk/clearwebstartcache
Have you updated the URL to your JNLP? Here's some discussion going in this direction: https://forums.oracle.com/forums/thread.jspa?messageID=9804718
Personally, I wouldn't bother too much about the how and why - WebStart can be weird at times. Just ix the problem on your "one machine" and try to keep your productive JNLP as stable as possible.

Related

JAVA application with file write/output on linux cant be read by non root user

We have this JAVA webservice that runs on tomcat 9(installed by root).
The webservice creates a generic file log for our client. The problem is only the root user can read and access the file that is being generated.
My question is can I change the output file to be readable for all users by default? (without using chmod everytime the file is generated)
Should it be on code level or configure it on linux?
I have read about this https://docs.oracle.com/javase/tutorial/essential/io/file.html.
But one of our old redhat servers dont have a code level config on its webservice and its working fine.
Thanks
You should not be looking at this from a "java io" side of things.
This is a user permission problem. In other words: probably your tomcat servers shouldn't be running as root in the very first place.
Consider creating a special user that is used to run your tomcat instance. Here you can find guidance how you could do that for an Ubuntu system. And your favorite search engine will for sure know similar links for your favorite Linux distribution, too.
That might also be better from a security perspective: do you really want that people attacking your tomcat ... end up being root on your system if they succeed?!
Long story short: your problem is not some java code within tomcat that writes files; and then other users on your system being unable to access those files. Your problem is that your tomcat service is running as root! Fix the later; and your "initial" problem will be fixed, too.
Final word of warning though: I am not saying that it is easy to change the user setup for you. Maybe it is; but especially if your setup is using "root" for a long time, then there is a certain chance that other things you put in place rely on "being root". So, "not being root" is the right direction; but it might be a painful path to get there, from where you are now.

Java's File.delete() sometimes leaves behind inaccessible files (Windows)

I am trying to programatically purge log files from a running(!) system consisting of several Java and non-Java servers. I used Java's File.delete() operation and it usually works fine. I am also perfectly fine with log files that are currently in use not being deleted, so I just log it as a warning whenever File.delete() returns false.
However, in log files which are currently still being written to by NON-Java applications (Postgres, Apache HTTPD etc., Java applications might also be affected, but I didn't notice yet, and all are using the same logging framework anyway, which seems to be OK) are not actually deleted (which is what I expected), however, File.delete() returns "true" for them.
But not only do these files still exist on the file system (Windows explorer and "dir" still show them), but afterwards they are inaccessible... when I try to open them with a text editor etc. I get "access denied" or similar error messages, when I try to copy them with explorer, it also claims that I do not have permissions, when I check its "properties" with explorer, it gives me "You do not have permission to view or edit this object's permissions".
Just to be clear: before I ran the File.delete() operation, I could access or delete these files without any problems, the delete operation "breaks" them. Once I stop the application, the file then disappears, and on restart, the application creates it from scratch and everything is back to normal.
The problem is that when NOT restarting the application after the log file purge operation, the application logs to nirvana.
This behavior reminds me a bit of the file deletion behavior of Linux: if you delete a file that is still held open by an application, it disappears from the file system, but the application - still holding a file handle - will happily continue writing to that file, but you will never be able to access it afterwards. The only difference being that here the files are still visible in the FS, but also not accessible otherwise.
I should mention that both my Java program and the applications themselves are running with "system" user.
I also tried Files.delete(), which allegedly throws an IOException indicating the error... but it seems there is no error.
What I tried to work around the problem is to check if the files are currently locked, using the method described here https://stackoverflow.com/a/1390669/5837050, but this only works for some of the files, not for all of them.
I basically need a reliable way (at least for Windows, if it worked also for Linux, that would be great) to determine if a file is still being used by some program, so I could just not delete it.
Any hints appreciated.
I haven't reproduced it but it seems like an OS expected behaviour, normally different applications run with different users which have ownership on this type of files but I understand that you want like a master purge Java which checks the log files not in use to delete them (running with enough grants of course).
So, considering that the OS behaviour is not going to change I would suggest to configure your logs with "roll file appender" policies and then check the files that match these policies.
Check the rollback policies for logback to make you an idea:
http://logback.qos.ch/manual/appenders.html#onRollingPolicies
For example, if your appender file policy is "more than one day or more than 1Gb" then just delete files which last edition date are older than one day or size are 1Gb. With this rule you will be sure to delete log files that are not in use.
Note that.. with a proper rolling policy maybe you even don't need your purge method, look at this configuration example:
<!-- keep 30 days' worth of history capped at 3GB total size -->
<maxHistory>30</maxHistory>
<totalSizeCap>3GB</totalSizeCap>
I hope this could help you a bit!!

How to upload files with java applet?

I know similar questions have been asked but i have searched for hours and as of yet have not come up with a workable solution.
I have a Java applet which will be a "paint" like application. So, I need the user to be able to upload images from their file system. I first tried using a JFileChooser which works great in the eclipse environment. However, when put online i get a "java.security.AccessControlException: access denied" exception.
I was thinking that perhaps within the applet i could call a script (located on my server) which would prompt the user to select a file - but i have no idea how to do this. I am using zymic web hosting, so the only supported scripting language is PHP.
I also tried signing the applet. Since i don't want to spend money on certificates, i self signed the applet. When i tried running it, I got an error stating "The Publisher Cannot Be Verified By A Trusted Source".
Any help would be greatly appreciated. - Thanks:)
A trusted applet can most certainly load files from the local file-system. The "Publisher Cannot Be Verified By A Trusted Source" message that is produced by self-signed applets is onerous & scary (for good reason), but if the user OKs it, it works just fine.
Here is a small demo. of exactly that.
Since the 'Next Generation' Plug-In, even sand-boxed applets can access the local file system. See the last 2 links on the Applet tag info page for further details.
Here is an applet that uses the Next Generation file abilities.
Unsigned applets can not access the file system for security reasons.
There is a tutorial about uploading files using PHP here
Maybe you can work that into your page in order to allow the file to be uploaded and then load it from your web server with the applet.
Do keep in mind the warning at the end of that example under the section "php - file upload: safe practices"

How to edit files on the users file system from my web server?

I am really looking for implementation advice as I have entered a new realm that I am not familiar with.
At the simplest level, I would like to find a way that I can read/write to a users machine from my web server. For this to work, I think I will have to install some sort of "plugin" on the users machine which can receive (or poll?) the server for instructions.
The above is the line of thought that I currently have, maybe using JAVA to do this. This needs to work on Linux, Mac and Windows OS.
I am really looking for advice on the above, is it a good idea? Is there a better way of doing this? Is there something out there already that I can build on top of?
I really appreciate all input and advice as this is something I have not done before.
Thanks all
For Java, you could launch a client application via Java Web Start that will be able to perform a limited set of operations on the file system.
If this is too restrictive, then you would need to provide a link to a download of a client application that would be installed / executed on the user's desktop machine.
I'm assuming you want to read and write specific files on the users' machine that are not normally accessible (i.e. not temp files, or files in a sandbox). And you want to do this from your webserver.
As you looking for cross platform, I'd go with java. Given that your needs are simple (read/write files from remote commands) you could probably target JRE 1.4, which is now many years old, but is installed on ca. 98% of desktops (source).
Here's an overview of how you can approach this:
Create a java applet or Java Web Start application that fetches a list of commands from a URL. The URL can contain any specific identification that you need to identify the machine, such as the users ID (see below for alternatives.)
Your webserver generates the list of commands that the applet should execute - create file, read file, write file and sends these as the response.
Sign the applet/application, so that it can escape the restrictions of the sandbox. To do this, you need to obtain a certificate. More on this later.
Inform and educate your users about what the applet is doing. E.g. a page on your site about why they are being asked to trust your certificate and what the implications are.
You can implement this as an applet or an application, the bulk of the work is pretty much the same. I talk about applet, but remember it applies equally to application.
In more detail:
The applet requests a list of commands from a URL. To hamper attempts at using your applet on another malicious site, you should use HTTPS to fetch the list of commands so that the server is authenticated. The URL should be hard-coded into your applet, so that any attempts to change this will break the signing. How you communicate the commands to the applet via the URL is up to you, e.g. you can use XML or use RMI and simply send over the list of commands as an object.
I mentioned using the userid to identify the machine - using the machine's MAC address is also a possibility. See how to get the mac address of the host.
Once you have the list of commands, your applet executes these using java file I/O apis. See File, FileReader/FileWriter in the javadocs. You include appropriate logging so the applets actions can be audited later if necessary. Once the applet has executed the commands, it sends the result of the commands back to the server, either as a POST operation, or another RMI method call, if you settle on RMI.
If you want to continually send commands from the server, then the applet can poll the URL/invoke the RMI method regularly. A Timer can help with this.
With communciation errors, it will be necessary for the client to request the list of commands more than once. Thus each time you produce a list of commands from the server, it is given an id. The server gives out the same list with the same id until it receives acknowledgement from the applet that the commands have been executed.
To sign the applet, you should obtain an rsa certificate from a certficiate authority. You can self-sign, but then you are opening the door to others modifying your app and impersonating your certificate. Details on obtaining and using certificates are given here.
If you don't know java, then all of this may not make a huge amount of sense, and it's not a trivial project to get started on, particularly considering the implications for your users if your implementation has holes and defects.
It may be wise to exercise caution: although you can do this, doesn't necessarily mean you should. I imagine that most expert users would frown on the use of this app, and would not accept the certificate. And then there is culpability - if your app accidentally deletes a critical file through a bug, misconfiguration, human error etc, how will you be prepared for that?
For the user, a web browser plugin may be the easiest, since the user won't have to manage yet another running application, however it has its limitation such as having to develop a plugin for each browser. In addition, the user would need their browser running.
You could have the user install a desktop application, which they would have to keep running, so installing it as a service might be ideal.
You could also use a plugin as a wedge between the web browser and a desktop application, which is how Flash works.
To really know you will have to answer the "why" question, why do you wan tot do this.
If you are just trying to store some state on the user's machine that you need to have locally then for small things you can fall back on cookies, or for larger needs you can use the new Web Database features in HTML5 http://dev.w3.org/html5/webdatabase/
If you need to access specific files then you are actually going to have to circumvent the security sand boxing that Java does when run on a webpage. I will leave that for others to go into, I don't know how to do it off hand myself.
In my opinion, Applet will be a better solution. I have made one applet which downloads a zip file from the server on client machine into temp folder, extracts the zip file into a directory specified by client (browser user) and then deletes the zip file.
thanks.
The lowest hanging fruit might be to provide WebDAV access through your web server to a given set of files, as this allows the users to see the files as a part of their usual filesystem with all their usual tools. You then do not have to do all that functionality.
Looks like Slide can deploy on Tomcat, and JBoss has ModeShape.
Will that be useful enough?

Cross-platform executable/runtime delivery method

I need assistance finding a delivery method that best fulfills the following requirements:
We wish to deliver a single file to my clients.
Clients should be able to launch this file from the operating system shell - much like running an '.exe' on Windows.
After being launched, the program/script should be able to display a window with HTML content. this may be done using a stand alone program, a runtime or by running within a browser.
We need the ability to embed a resource within the delivered file, such as an mp3 file, which i can later extract programmatically.
Optimally, the solution should run on Windows, Mac and Linux machines. Less than perfect cross-platform interoperability is acceptable, but we want as broad a penetration as possible.
Clients should not need to pre-install anything (unless it is done transparently), pre-configure anything, or approve any thing for this to happen.
For example:
We could use a regular executable file, written in C++ to do this, but it will not be cross-platform.
We could use a sliverlight XAP file, an adobe Flex file or a Java JAR, but internet explorer warns users when local content is launched. In addition these approaches mean that we have less than perfect penetration, even though it is acceptable in these cases.
We could use a python (or equivalent) script, but the installed-base (penetration) of the python interpreter is not good enough.
Using a standard HTML is not enough because of the difficulty of embedding resources in it. Embedding Silverlight XAML or uuencoded content in HTML causes IE to display a warning.
Using something along the lines of a jpeg as a delivery method is not rich enough since we need to display HTML.
..but internet explorer warns users when local content is launched..
I don't get it, what's the problem with IE saying "Hey this app is trying to run your files!"
I don't mean you don't have a good reason for this, it is just, I don't get it.
IE will only warn the user if the app has not been downloaded and try to access local resources, for instance if running from an applet or a JNLP like this one:(click on the first orange button you see )
But if the users download the jar and run it from the computer ( double click on it ) the app is local and can run without problems.
The jar file is a zip file after all, so you can attach your mp3 file with it. Double click is supported in the desired platform, and the HTML content could be either a local file ( un-packed along with the mp3 file ) or an internet web page.
Java is preinstalled on those OS already.
"internet explorer warns users when local content is launched"
There's a reason for this. How can they distinguish your excellent, well-behaved, polite application from a virus?
Since the line between your app and a virus is very, very blurry, go with any of Silverlight XAP file, an adobe Flex file or a Java JAR.
The IE business is a good thing, not a bad thing.
You could try using the 'Jetty' application server.
This supposes there is a working java environment on the target machine.
Jetty is java servlet container but it is possible to configure
everything (web server, html templates, applications, etc.) in a
single executable jar, which launches the web server and opens a default page.
Exactly how the jar file is launched will vary from platform to platform
but otherwise the user interface will be identicle, and, as its a java application
you can do pretty much anything one it has started.
Sounds like MIME HTML does exactly what you want - unfortunately, it is not supported by many browsers other than IE.
I'd investigate Adobe AIR. It can display both HTML and Flex content in a desktop application without using a web browser. However this will require installation of the AIR runtime, also I'm not sure if the Linux version is out of the beta stage.
http://www.adobe.com/products/air/
You can also use a binary for each platform.
As per your description the app is very simple, and porting from one platf to another sounds like just matter of re-compile and offer binary based on the dist.
Is this an option?

Categories

Resources