The Altair Community is migrating to a new platform to provide a better experience for you. In preparation for the migration, the Altair Community is on read-only mode from October 28 - November 6, 2024. Technical support via cases will continue to work as is. For any urgent requests from Students/Faculty members, please submit the form linked here
"Java Applet Alert -- SOLVED --"
spitfire_ch
Member Posts: 38 Maven
Hi,
on my machine at work I get bothered by Java "applet alerts" when I try to use Rapidminer extensions, such as the great new Automatic System Construction. I get as far as Step 3, but then the following Alert pops up:
APPLET ALERT
The applet is attempting to create new thread groups
Allow | Disallow | Stop Applet
By clicking allow, the process continues, but only for a fraction of a second before the alert appears again. So I can only advance the process by constantly clicking "Allow", which is not an option.
I have read that this might have something to do with security policies or TrendMicro. When I click Disallow, I get the following message:
com.trend.iwss.jscan.runtime.AppletTrapStopError: Applet disabled by IWSS Javascan site policy.
However,I can't find TrendMicro on my machine - so maybe its a policy of the network.
Either way, as I user I clearly don't have the right to change that policy, nor can I ask the admins to lower security levels.
If this really is a security problem, maybe the way how Rapidminer handles applets should be adjusted, so that is also runs on machines with stringent security policies.
If somebody has an advise, I would be very grateful!
Thank you very much
Hanspeter
on my machine at work I get bothered by Java "applet alerts" when I try to use Rapidminer extensions, such as the great new Automatic System Construction. I get as far as Step 3, but then the following Alert pops up:
APPLET ALERT
The applet is attempting to create new thread groups
Allow | Disallow | Stop Applet
By clicking allow, the process continues, but only for a fraction of a second before the alert appears again. So I can only advance the process by constantly clicking "Allow", which is not an option.
I have read that this might have something to do with security policies or TrendMicro. When I click Disallow, I get the following message:
com.trend.iwss.jscan.runtime.AppletTrapStopError: Applet disabled by IWSS Javascan site policy.
However,I can't find TrendMicro on my machine - so maybe its a policy of the network.
Either way, as I user I clearly don't have the right to change that policy, nor can I ask the admins to lower security levels.
If this really is a security problem, maybe the way how Rapidminer handles applets should be adjusted, so that is also runs on machines with stringent security policies.
If somebody has an advise, I would be very grateful!
Thank you very much
Hanspeter
Tagged:
0
Answers
How annoying! By chance I was talking about sterile jars to a chum quite recently, so I suspect you're on the right track with... especially if you check this out..
http://esupport.trendmicro.com/Pages/IWSx-3x-Some-files-and-folders-are-added-to-the-Jar-files-after-passin.aspx
Hope that is useful!
Good weekend
Thanks for your reply! I also stumbled over said page, but couldn't follow the indicated steps because I couldn't find Trend Micro on my machine. Especially Step one proved to be tricky:
1. Log on to the IWSS web console.
I looked and googled for this console, but couldn't find it. Do you by chance know how I could open this console? I doubt I have the rights to change anything, but it would be worth a try.
Btw. I also tested Rapidminer on my computer at home - there its working like a charm (except for the problem with starting the Java virtual machine mentioned in the other thread). But well, having full control over your computer configuration is a bit different from being restricted in the company's network. And yeah, it also showed me how extremely useful the plugin would be which I can't use at work
Good weekend, you too!
Hanspeter
However, I don't have any privileges to change firewall settings.
I found some new information on the following site, which might provide a workaround:
http://faq.javaranch.com/java/HowCanAnAppletReadFilesOnTheLocalFileSystem
However, I am not a Java guy I don't understand most of it. It seems as if I could try to add CodeBases as PolicyEntries using policytool.exe. According to the following page http://download.oracle.com/javase/tutorial/security/tour1/wstep2.html
I need to add the URL, name of the applet etc.
I tried already, but so far unsuccessful. My principal problem is that I don't really know what to add. For example, right at start up of rapid miner, I get an applet error concerning an applet wanting to connect to http://www.myexperiment.org/workflows.xml?num=100
So I added this URL, but have no idea how this applet is called like. I tried myexperiment, but that didn't work.
Is anyone familiar with this kind of information?
Any help is greatly appreciated!
Best regards
Hanspeter
might be it would be a solution to sign RapidMiner. Might be the settings would be different for known programs that can prove their identity.
Unfortunately we can't do much about the problem with the paren extension, because the source code is not under our control, but you could ask the community members who contributed it, if they could avoid creating new TaskGroups.
The applet wanting to connect to myexperiment is RapidMiner itself, so you simply should add the URL you are downloading RapidMiner from to the PolicyEntries.
Greetings,
Sebastian
Thanks a lot for that hint, I will do as suggested and also try to contact the paren creators.
Greetings,
Hanspeter
So far my policy contains the following entries: The major problem certainly is that I don't really know what I am doing - I am no Java guy. So I don't know whether I have added the correct URLs, whether I have added them the right way or not ... If anyone knows, please let me know
Best regards
Hanspeter
(old post:)
Hi Sebastian
I tried to add the RapidMiner Update location ( http://rapidupdate.de:80/UpdateServer ) to the policy, but so far to no avail. Then it dawned upon me that simply creating a policy file won't do the trick. I saved into the C:\Programme\Java\jre6\bin folder, but I fear it won't be used.
On the tutorial page ( http://download.oracle.com/javase/tutorial/security/tour1/wstep3.html ) they say:
The examples in this lesson and in the Quick Tour of Controlling Applications lesson assume that you stored the policy file in the Test directory on the C: drive.
So, I guess that RapidMiner assumes the policy files to be in a specific location, too. Or would I even have to change code somewhere in order to get the policy file being used?
Any hints on that are greatly welcome.
Thank you very much and best regards
Hanspeter
well actually I would have to take a deeper look into this matter as well. If you would be enterprise customer I could invest more time, but as you might understand, we cannot spend hours and hours to help people integrating the (service and guarantee free) community edition...
Greetings,
Sebastian
yes, I certainly understand. But I think I am on the right track, now. I share this info although I am not an enterprise customer ;-) Matthias Reif from the PaREn-team suggested to look for the com\trend directory inside the jar files. I didn't know jar files are in fact zip files and by renaming it you can actually open them.
After some search I found the files in my personal folder:
c:\Documents and Settings\***\.RapidMiner5\managed\
It turns out, that the com\trend directory is not contained in rmx_paren-5.0.1.jar, but rather in rmx_parallel-5.0.1.jar, which PaREn depends upon. However, simply deleting the com\trend directory doesn't do the trick, because this causes another error: java.lang.NoClassDefFoundErrcr: com/trend/iwss/jscan/runtime/CallContext
It appears, that TrendMicro automatically adds this directory to jar files when you download them from within a network that is protected by TrendMicro. At home, I don't use TrendMicro, so I will try to overwrite the jar-files at work with those from home (or maybe the entire rapidminer directory).
To avoid such problems for other users, you might offer alternative downloads for all extensions, that are usually installed by the update feature. Presumably, if you downloaded the extensions as zip files, rar files etc. instead of jar files, TrendMicro wouldn't add its annoying payload to them.
Maybe a change in the update-manager itself could do the trick, as well. Instead of fetching jar files, you could simply rename the files on your server to e.g. .txt files, fetch them by the update-manager and then rename them back to .jar on the users computer.
I know, I am not an enterprise customer, but these problems could certainly also occur to an enterprise customer. If anybody is behind paranoic shields such as TrendMicro and alike, it is enterprises The above suggestions might help to avoid some trouble for these customers.
Best regards
Hanspeter
P.S. I will report here if the files from home did the trick.
actually the Updates are fetched via HTTP, and stored in files with the ending .jar. But since they aren't fetched with name over the network I would rather assume, that TrendMicro runs on your local machine and "infects" the files locally. Don't think we should start cheating your own IT department, would do us any good, if the IT Departments are pissed
Did you try to ask some IT guy to actually sign the jar files? There must be some mechanism to allow the usage of jar files...
Greetings,
Sebastian
I could not find any try of TrendMicro on my local machine. That why I think the files got "infected" somewhere underway (we have to connect to the outside world through a proxy). However, not all the jar-files show the TrendMicro-"infection" (I like this term of yours for security software . So there is also a slight possibility that the "infection" was in fact introduced by the developpers of the extensions themselves, but on a machine with "non-paranoid" security policies they wouldn't do any "harm". I will soon see if that's true when I am home. If it is, trying to convince the IT guys of signing the jar files is the last option left. If not and the files from home do the trick on my machine at work, I will probably be happy and let it be. Unless of course you require the information from our IT guys.
Well, I'll let you know, soon.
Best regards and thanks for your help
Hanspeter
I just checked at home and the jar files here indeed do NOT contain the com\trend folder. So it must be the network of the company that "infects" the files. I now copied all the files related to rapidminer from my homecomputer and will see tomorrow if I can get it work on my computer at work.
Cheers
Hanspeter
EDIT: That did the trick. I replaced the files rmx_community-5.0.1.jar and rmx_parallel-5.0.1.jar with those from home. Now, everything is working fine
Thanks for the support ans best regards
Hanspeter
Cheers,
Ingo
Out of curiosity, I compared the original rmx_parallel-5.0.1 archive with the one changed by TrendMicro. It seems that TrendMicro not only adds the \com\trend folder, but additionally also changes the following files:
\com\rapidminer\ConcurrencyTools.class
\com\rapidminer\operator\executor\ParallelUnitExecutorService.class
\META-INF\MANIFEST.MF
This explains why simply deleting the added folder doesn't work.
I cannot properly open the .class files, but besides lots of undecodable code it adds stuff like
L(ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/Object;)V
·(com/trend/iwss/jscan/runtime/CallContext
addArg·>(Ljava/lang/Object;)Lcom/trend/iwss/jscan/runtime/CallContext;
·(com/trend/iwss/jscan/runtime/CallContext!
getNextObjectArg·()V#$
"%·.com/trend/iwss/jscan/runtime/MiscPolicyRuntime'
preFilter·-(Lcom/trend/iwss/jscan/runtime/CallContext;)V)*
(+·(com/trend/iwss/jscan/runtime/CallContext-
setResult·(Ljava/lang/Object;)V/0
.1·.com/trend/iwss/jscan/runtime/MiscPolicyRuntime3
etc.
And it adds a lot to the manifest:
ParseRule-Descriptor:
Implementation-Title: Parallel Processing
Group-Descriptor:
Initialization-Class: com.rapidminer.ParallelPluginInit
Implementation-Version: 5.0.001
Implementation-Vendor: Rapid-I
Name: com/trend/iwss/jscan/runtime/CallContext.class
SHA1-Digest: uXiE1WdbVnSNIDZoKzcaz3Qgnz8=
MD5-Digest: wgfF3q4DSU7oK1A+n9mPOg==
Name: com/trend/iwss/jscan/runtime/WindowPolicyRuntime.class
SHA1-Digest: sqlglw6roeTadEziV/lC1ne7Sjo=
MD5-Digest: nTt6cYdSI5vNuA/NfF2B9g==
etc.
Cheers,
Hanspeter