Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Applet depends on jar file - causes RuntimePermission error

 
Michelle Kyamo
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My applet depends on a jar file. (this one: https://swing-layout.dev.java.net/servlets/ProjectDocumentList?folderID=11880&expandFolder=11880&folderID=0 ) It runs fine on my computer and at least two others. On another computer, it will not run. Here is the error message.

I guess it seems to be not allowed to look at the methods that exist inside the jar file?

I don't understand why there are security problems or extra permissions needed, since the applet does not try to access or affect anything on the users computer or anything fishy like that.

How can I fix this? Do I need to sign my applet? I do not understand how to do that. If I do sign it, doesn't that mean that users will get a security popup asking them to trust me that the code isn't malicious? For my application, such a popup is not acceptable, and shouldn't be needed since this applet doesn't try to affect anything outside itself.

Thanks for any help.

 
Ulf Dittmer
Rancher
Posts: 42969
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My applet depends on a jar file. It runs fine on my computer and at least two others. On another computer, it will not run.

Given the nature of that library, it's quite possible that it does different things on different operating systems and/or different JVM versions - only some of which may not be allowed by the applet security model.

I guess it seems to be not allowed to look at the methods that exist inside the jar file?

The error message states that the library tries to use the reflection API in a way that the applet classloader doesn't allow.

I don't understand why there are security problems or extra permissions needed, since the applet does not try to access or affect anything on the users computer or anything fishy like that.

Well, the reflection API can be used to undermine security, so its use is limited in the applet sandbox.

Do I need to sign my applet? I do not understand how to do that. If I do sign it, doesn't that mean that users will get a security popup asking them to trust me that the code isn't malicious? For my application, such a popup is not acceptable, and shouldn't be needed since this applet doesn't try to affect anything outside itself.

Yes, to make this problem go away you'd need to sign the applet, and yes - the user would get a popup dialog about trusting a certificate. (If you want to read up on that, see HowCanAnAppletReadFilesOnTheLocalFileSystem.)

Since the library is open source you could check out why it's performing this operation, and maybe patch that out; if you're just wanting to use some of its GUI features, then I agree there should be a way to do that without resorting to potentially forbidden reflection features.
 
Michelle Kyamo
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ulf Dittmer wrote:

Since the library is open source you could check out why it's performing this operation, and maybe patch that out; if you're just wanting to use some of its GUI features, then I agree there should be a way to do that without resorting to potentially forbidden reflection features.


Thank you for your help.


The reason I am using that jar file is so that I can use GroupLayout even if the users java is version 5 instead of version 6 (as on many Macs). I have now looked at the source of it, and found the problem seems to be in this method (which I don't call directly, but I guess is called in order to set up the layout):



It calls java.lang.Class.getDeclaredMethod which throws the SecurityException

getDeclaredMethod

public Method getDeclaredMethod(String name,
Class<?>... parameterTypes)
throws NoSuchMethodException,
SecurityException

Returns a Method object that reflects the specified declared method of the class or interface represented by this Class object. The name parameter is a String that specifies the simple name of the desired method, and the parameterTypes parameter is an array of Class objects that identify the method's formal parameter types, in declared order. If more than one method with the same parameter types is declared in a class, and one of these methods has a return type that is more specific than any of the others, that method is returned; otherwise one of the methods is chosen arbitrarily. If the name is "<init>"or "<clinit>" a NoSuchMethodException is raised.

Parameters:
name - the name of the method
parameterTypes - the parameter array
Returns:
the Method object for the method of this class matching the specified name and parameters
Throws:
NoSuchMethodException - if a matching method is not found.
NullPointerException - if name is null
SecurityException - If a security manager, s, is present and any of the following conditions is met:

* invocation of s.checkMemberAccess(this, Member.DECLARED) denies access to the declared method
* the caller's class loader is not the same as or an ancestor of the class loader for the current class and invocation of s.checkPackageAccess() denies access to the package of this class

Since:
JDK1.1


When you said I may be able to "patch that out", do you mean change the code in the jar file? I could maybe try deleting this portion since I can see there is another "if" further down that deals with "Aqua" again, but I don't really know enough about it to know if this might break something else. Also, if I change the code I have to make the jar again on my own, which would get rid of any signing they may have put on it. Will that cause another security problem?

 
Ulf Dittmer
Rancher
Posts: 42969
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Comparing strings using the "==" operator ...

When you said I may be able to "patch that out", do you mean change the code in the jar file? I could maybe try deleting this portion since I can see there is another "if" further down that deals with "Aqua" again, but I don't really know enough about it to know if this might break something else.

Yes, that's what I meant. Try replacing the complete try/catch block with just the contents of the "catch" block. You'd only see a difference on OS X anyway (the Mac Look&Feel is called "Aqua").

Also, if I change the code I have to make the jar again on my own, which would get rid of any signing they may have put on it. Will that cause another security problem?

If the jar file was signed, no security exception would be happening in the first place.
 
Michelle Kyamo
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ulf Dittmer wrote:Comparing strings using the "==" operator ...


Hey, I didn't write it!



If the jar file was signed, no security exception would be happening in the first place.


My code wasn't signed, but I thought it was possible that the jar file which I am just using and didn't write may be. I am not sure how to tell.

Thank you again for your help, I will try that.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic