Signed Applet = No Permissions ?
I have an applet which does JNDI lookups to use EJBs. This applet was working fine under Weblogic 5.1 SP9 and I'm trying to move it to Orion.
Under Weblogic the applet was not signed and there was no java.policy file either. Somehow it all worked.
Under Orion I'm getting exceptions because I don't have the right privs.
So I added a java.policy file which granted all permissions and I set my java plugin to use this poicly file. Everything worked fine. However this isn't a solution. I need a solution where many ignorant computer users can use the applet and not have to set anything up.
So I signed the applet. But this wasn't enough, I had to install the applet as a trusted CA( because it's self signed i think). It now shows up under the certs section of the java plugin control panel. However I still don't have the permissions I need.
I did get prompted with a java dialog box about allowing this applet to run, etc.. And I picked always trust or something like that. Even so, asking a user to install a root cert it not going to cut it, I suppose I could get a real cert but why bother when this is all in house. So just signing the applet doesnt get me what I want. In fact it didn't seem to do anything at all.
I just want a solution where the end user gets a dialog box and selects "trust this applet" and then everything works. Is this possible?
I'm using 1.3.1 java plugin and JRE on IE 5.5
Thanks
Paul
[1502 byte] By [
spraguep] at [2007-9-26 2:21:21]
Hi, Paul,
Have you found the way to solve this problem, I have the same problem. It seems a lot of people here they just followed the "10 steps", then it's the "happy together" ending, but to me, the "10 steps" didn't work a bit at all.
The error msg I got is "java.lang.RuntimePermission:writeFileDescriptor", I don't want my users to modify the policy file themselves.
Anybody's help are appreciated!
Sorry, I have no more duke dollars :(
Janet.
Suppose you go to a website and you get a popup message saying that an applet from ABC Corporation wants to do risky things to your computer.
Q. How do you know that it is really from ABC corporation, and not something some hacker has done?
A. Because is MUST be signed by one of the root certificate authorities which came with the browser, to say that it came from ABC Corporation.
If there was a way around this, there'd be no point in having signed applets.
OK, you say, why can't I just have a popup that says signed by nobody? Because the no-certificate-no-risky-business rule generally makes for a safer internet.
If you don't want to get external certification for an internal application, the alternative is to talk to whoever sets up and manages your PCs about making installation of an internal certificate part of the standard setup routine.
pweb at 2007-6-29 9:26:24 >
Are you replying to my question? I cannot get what you mean.Janet
hi janet,
the 10 steps policy worked when self-signed certs
were accepted, with jdk1.3 only applets which are signed by those certs which can be verified by root
certs in keystore ${java.home}/jre/lib/security/cacerts
can run without throwing exception. the solution is to include the self-signed cert into this keystore also.
u can readhttp://www.javaworld.com/javaworld/jw-12-2000/jw-1215-security.html
for more info about how plugin and the policy file
interact.
Yes, I had imported the self-signed cert into to the keystore and I know it will work after I modify the policy file, but the problem is that I don't want my users go to modify the policy file. Actually if I modify the policy file, the applet can work fine even though I didn't do anything about the 10 steps, just plain jar file can work fine! So I don't know what the point to self-sign the jar file then still have to modify the policy file.
And one more thing is, when I do the step 10(link to the cert file in the html page), the cert will be imported into IE(I'm using IE 5.5) instead of java plugin, How can I import it into Java plugin?(Yes, I know I can use keytool, but the users don't know how to issue command from DOS prompt).
I have worked with this problem for quite some time, now really become very fed up. The info provided here in this forum are always links to each other.
Janet
u cud do the following:
u can maintain the policyfile
for all users. the only thing yr
users shud do is to
disable the default policy file
options
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
in ${java.home}/jre/lib/security/java.security
and instead include yr the url where u maintain policy for yr users.
hope that'll solve the problems.
in anycase yr users shud include appropriate root certs in cacerts.
the link.
i dont use IE as i work in linux, and i use keytool to import it into the cacerts. may be u can write a gui for yr users to do that.
suresh
one more thing is that u shud write a signed applet which will do the import! if it sounds like chicken and egg probs, give yr users a keystore which will contain yr key and yr users will just copy it to their
${java.home}/jre/lib/security/cacerts
or simply, yr users shud save the linked cert as a text file and using a gui import it to the proper keystore.
one more thing is that u shud write a signed applet which will do the import! if it sounds like chicken and egg probs, give yr users a keystore which will contain yr key and yr users will just copy it to their
${java.home}/jre/lib/security/cacerts
or simply, yr users shud save the linked cert as a text file and using a gui import it to the proper keystore.
