1.5 allows setStub() by unsigned applets?

I have an applet that is embedded in a JFrame. It worked fine in 1.4 but I just tried j2re-1_5_0-beta2-windows-i586 and get "java.security.AccessControlException: access denied (java.awt.AWTPermission setAppletStub)...
at java.applet.Applet.setStub(Unknown Source)"
Is setStub() not allowed by unsigned applets in 1.5?
Thanks

I have the same problem.
Trying to track it down, did you get any feedback from anyone ?

Similar Messages

Signed and unsigned applet

Hi all,
I want to create an applet that is firstly loaded as a normal (i.e., unsigned) applet. The user can use several features of the applet without seeing a security warning dialog. But when the user uses a certain feature of an applet (such as saving the data to his computer), there will be a security warning dialog that asked the user to allow the (same) applet to access the local harddrive. If the user allows, the applet will be switch to signed mode without having to reload.
In short, is there a way to switch between an unsigned applet to a sign applet without reloading the applet?
Thank you,
vaxim

It is possible if and only if your using different applets. In the same applet there is no possibility of switching signed and unsigned. But I think you can do this by specifying the certificate name.

Remembering username and password in an unsigned applet...

Does anyone have any ideas how my unsigned applet could remember the username and password entered by a user?
Previously, I was using a signed applet so could store the username and password in a persistent text file, but now I need to provide an unsigned applet solution - so does anyone have any suggestions for how my applet could remember and recall the username and password?
Many thanks,
James

Take global variable and store pass and user name in it .
or getParameter() and setParameter() u can set parameter define in html file as global . so multiple applet in same webpage can access this pass and user name

Unsigned applet

Hi, I have a simple question... �Can an unsigned applet connect to the same IP where it was downloaded but to another port (says 3306)?
Regards,
Neuquino

most probably it couldn't. in order to socket connection established, u have to sign the applet otherwise it fails...

Unsigned applet: some machines can copy to clipboard, others can't

My understanding of Java applet security says that an unsigned applet cannot copy-to or paste-from the system clipboard. However, on at least two systems at my office (but not mine) the user can highlight text in one of our applets, hit Ctrl-C and copy the text to the clipboard. All machines are current vintage, running MS XP and Java 1.4.2. I've checked the java.policy files and they are identical--there are no non-standard permissions in them.
Now my boss is complaining that I told him this couldn't be done without going the signed applet route. Does anybody know what's going on?

First of all if you're developing applets for your company (or another one) make sure they
have the jre set up correctly.
Any respectfull IT person within a company has IE security set up so why not the jre as
wel?
Using the default jre installation in your company? Are you allso using the default IE
install or did you not agree with some settings there?
Anyway here is how I think you should set up the jre for your companys people:
I think a good configuration would be a keystore and policy on the company's
Intranet to be used by everyone and if so needed a keystore and policy in the user home
folder to be edited only by admins. Add the 2 keystores to the java.security and the
admins can configure any special privileges to special applets (like IE security zones
but more detailed).
Add the following line to all codebases: "grant { " section in the java.policy/
permission java.lang.RuntimePermission "usePolicy";
Now the user does not have the option of "do you trust" for signed applets. I think this
is a verry good idea because anyone with a jdk can sign their jar.
About someone beeing able to copy and the other one not, I guess you've given the
user too much freedom in changing their settings (the msjvm settings in IE). The
applet is probably not even run with the SUN jre because you are using the Applet tag.
Now I am not even sure if hitting crl + c does anyting with an unsigned applet but I would guess that accessing the clipboard from code should not be possible.

Unsigned applet load failure via HTTPS

Java Plug-in 1.5.0_06
MSIE 6.0
Unsigned applet loading via HTTPS failed.
We used a relative URL in an APPLET tag :
<APPLET CODEBASE="/TEST/" ARCHIVE="test.jar" CODE="nl.myorganisation.test">
The plugin does not seem to reuse the browser SSL-session.
It looks like the plugin does not find installed certificates in Explorer stores.
The 2th and 3th connection retry use an erroneous URL.
network: Connecting https://myorganisation.nl/TEST/test.jar with proxy=DIRECT
security: Loading Root CA certificates from <jre-home>\lib\security\cacerts
security: Loaded Root CA certificates from <jre-home>\lib\security\cacerts
security: Loading SSL Root CA certificates from <jre-home>\lib\security\cacerts
security: Loaded SSL Root CA certificates from <jre-home>\lib\security\cacerts
security: Loading Deployment SSL certificates from <user-home>\Data\Sun\Java\Deployment\security\trusted.jssecerts
security: Loaded Deployment SSL certificates from <user-home>\Data\Sun\Java\Deployment\security\trusted.jssecerts
security: Loading certificates from Deployment session certificate store
security: Loaded certificates from Deployment session certificate store
security: Loading certificates from Internet Explorer ROOT certificate store
security: Loaded certificates from Internet Explorer ROOT certificate store
security: Checking if certificate is in Deployment session certificate store
security: Checking if SSL certificate is in Deployment permanent certificate store
network: Connecting https://myorganisation.nl/CGI-BIN/nl/myorganisation/test.class with proxy=DIRECT
security: Loading certificates from Deployment session certificate store
security: Loaded certificates from Deployment session certificate store
security: Checking if certificate is in Deployment session certificate store
security: Checking if SSL certificate is in Deployment permanent certificate store
network: Connecting https://myorganisation.nl/CGI-BIN/nl/myorganisation/test.class with proxy=DIRECT
security: Loading certificates from Deployment session certificate store
security: Loaded certificates from Deployment session certificate store
security: Checking if certificate is in Deployment session certificate store
security: Checking if SSL certificate is in Deployment permanent certificate store
load: class nl.myorganisation.test not found.
Does anybody have any suggestion ?
Thanks and greetings,
Marc

First, Java plugin don't use browser https connection starting JRE 1.4, for running an applet in https server, the browser need to establish a https connection first, then Java pugin will use another https connection.
Second, Java plugin can read certificate from browser, starting JRE 1.5, you can go to Java control panel, Advanced tab, under security, check on the box:
"Use certificate and keys in browser keystore"
This way the Java plugin will read the certificate from browser too. (It will work automatically in IE browser, if you use Mozilla, you have to install JSS package first).
To answer your question, you can either turn on that option or import https certificate into JRE keystore (using Java control panel) for https connection.
Hope that answered your question.
Dennis

Browser settings to accept unsigned applets

Hi,
I'm writting an applet that uses a socket, therefore I need to sign my applet to view it into my browser. So every time I change my code I need to resign the applet.
Can I set my browser so I will accept unsigned applet?, this will be a lot easier to test and change the code of the applet.
I'm using a IE6 browser.
Thanks in advance,
Pieter

Yes if you have a JRE installed.
You can edit your java.policy file so that any java applet started on your machine will be given all priviledges.
Obviously for general use(i.e. untrusted applets) this would be quite dangerous.
You can add the following to your java.policy file....
grant{
permission java.security.AllPermission;
};

Connecting to a remote servlet from an unsigned applet

My applet connects to a remote servlet (on a different server). I could obviously connect to it fine with a signed applet, but now my applet is no longer signed.
I understand an unsigned applet can access a servlet on the same web server host, but the problem is that the servlet is on a different server...
Is there some simple way I can create a file (html or whatever) on the web server host that can accept requests from the applet and redirect them to the remote servlet?
Cheers,
James

If I understand what you're saying, no.
But perhaps you can install the applet on the server that you want to connect to.

SAXParser inside unsigned Applet: Validation with DTD

Hello!
I am trying to run an applet that performs some XML parsing ideally with DTD validation.
The issue is that I can't access files directly, but using tricks such as Class.getResourceAsStream() which I can do fine for my XML file my XML file. But then this xml has a reference to test.dtd (also in the jar file).
When the parser runs, it tries to open test.dtd "illegally" and a security exception is thrown. Any advice in how to avoid this?
BTW, I have already thought of:
* Traslating the DTD to a Schema
* Disabling validation
Would work, but not the solution I'm looking for :)

It doesn't seem like the SAXParser allows it, but if you use an XMLReader, you can specify an EntityResolver class.
The EntityResolver is called when SAX wants to open a resource. Your code can supply an InputSource to point to the resource you want.
Dave Patterson
Message was edited by:
d.patterson

File Access with unsigned Applet through editing the java.policy file

I'am starting to lose my hair on this...
I am trying to get an applet to run so that it can access the file system to move files on my local maschin. Because this applet is only running on my VM i can change the java.policy to avoid the signing of the applet.
first of all, if i wrote in the java.policy file
grant {
permission java.security.AllPermission;
};everything is working perfekt.
But I have not the intention to open the gates for any applet out there, so i want to limit the access to my applet. With every of the following versions I get at best an
java.security.AccessControlException: access denied (java.io.FilePermission...
My Setup
My Java Version: jre1.6.0_02
My applet is located unter the url
http://admin.mydomain.com/applet.jar
In Html i tryed the following different versions of loading the applet - none worked
<applet codebase="http://admin.mydomain.com/" name="shortcut" code="start.class" archive="applet.jar" width="0" height="0"></applet>
<applet codebase="http://admin.mydomain.com" name="shortcut" code="start.class" archive="applet.jar" width="0" height="0"></applet>
<applet name="shortcut" code="start.class" archive="http://admin.mydomain.com/applet.jar" width="0" height="0"></applet>in java.policy i tryed following versions with every html applet load version
grant codeBase "http://admin.x-press.de/-" {
permission java.security.AllPermission;
grant codeBase "http://admin.x-press.de/+" {
permission java.security.AllPermission;
grant codeBase "http://admin.x-press.de/applet.jar" {
permission java.security.AllPermission;
};why is it with
grant {
permission java.security.AllPermission;
};working, and not with the other versions?
i am almost bold now, please try to save my last hair from falling down.
any suggestion would be nice
thanks, feyyaz
Message was edited by:
feyyazdogu

I read the mentioned documentation and your right, some of my versions were wrong, but after reading the doumentation again i came to following result which should had worked but didn't.
java.policy
grant codeBase "http://admin.mydomain.com/*" {
permission java.security.AllPermission;
HTML File
<applet codebase="http://admin.mydomain.com/" name="shortcut" code="start.class" archive="applet.jar" height="0" width="0"></applet>if I am entering http://admin.mydomain.com/applet.jar i can download the jar, so the archive lays in the correct directory.
what i am doing wrong? do i have to change an additional file somewhere else?

WebStart Applications have same security level like unsigned Applets

Hi,
I have coded an Applet that can connect to data of my server using new URL(getDocumentBase(), "localfile.bla");, but now I have converted it to an application loaded with WebStart. I can't access the data with new URL("http://www.myserver.com/localfile.bla");, but a I don't have a DocumentBase, too. Do I Have to set an argument in the jnlp file with the DocumentBase, in order to access local data?
Or are there any other possibilities?!?
Thanks,
Greets

You have to set the code base in your JNLP file in the codebase attribute of the <jnlp> element:
<jnlp spec="1.0" codebase="www.myserver.com">
</jnlp>You should then be able to get hold of the code base from within the application using the following code:
import java.net.URL;
import javax.jnlp.BasicService;
import javax.jnlp.ServiceManager;
URL codebase=((BasicService)ServiceManager.lookup("javax.jnlp.BasicService")).getCodeBase();

After upgrading to Java 7 update 71 JVM doesen't allow to run signed applets

How to reproduce:
- delete all 32-bit Java in Control Panel
- delete contents of c:\%USER%\AppData\LocalLow\Sun\
- install http://java.sun.com/update/1.7.0/jinstall-7u71-windows-i586.cab
- go to site https://www.sod.pfron.org.pl/ - URL, site contains signed aplets and SSL
You will get
" javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target "
Exception.
On previous version of java (update 51, update 67) everythings works fine.
But there are some differences between versions:
java 51 contains c:\%HOME%\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs
java 67 doesn't contains c:\%HOME%\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs but works
java 71 doesn't contains c:\%HOME%\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs and don't work

With Java 7u11 Oracle increased the default security level to help reduce the of recently discovered exploits getting past the security sandbox.
That said, I seem to recall from a few years ago that any untrusted component delivered to the client might cause the entire application to be treated as untrusted (as it should), and this may be the case here.
Although license issues may prevent you from doing this, I have found that unpacking and then repacking-and-resigning (with your own key) all 3rd party JARs can get around this, but only you can decide whether this is (a) legal and (b) advisable in the first place.

SocketPermission error in applet when accessing the same domain

Hello, my applet downloads the contents of an URI from the same domain, using a relative URI. This should be AFAIK an unprivileged operation and should be always allowed, even for unsigned applets, such as mine.
(In contrast to accessing URIs from a different domain, which requires the applet to be signed or self-signed & confirmed).
Indeed, the applet works perfectly under Windows, both with MSIE+Microsoft JVM, MSIE+Sun JVM and SeaMonkey+Sun JVM and Opera+Sun JVM.
In contrast, under my Gentoo Linux, in SeaMonkey+Sun JVM this doesn't work. Under both Windows & Linux the Sun JVM version is 1.6.0, SeaMonkey version 1.1.7, Java plugin "Java(TM) Plug-in 1.6.0_03-b05". - Everything is emerged from the current stable Portage tree (ebuilds www-client/seamonkey [1.1.7], virtual/jre, dev-java/sun-jdk [1.6.0.03], plus I created a symlink 'libjavaplugin_oji.so' in directory '/usr/lib/seamonkey/plugins' pointing to '/usr/lib/jvm/sun-jdk-1.6/jre/plugin/i386/ns7/libjavaplugin_oji.so'
I have made no changes to my java.policy file. [Yet it seems that such rule as "allow URI access in the same domain" cannot be expressed in this file's language]
The error message I get is exactly what I would get have I tried to access an URI from a different domain. [See below].
Googling as well as searching Sun's forums failed to give an answer. Has anyone have had similar problems? Is it more likely to be just a configuration/Gentoo problem, a more general problem, or perhaps the problem is just between the monitor and the keyboard?
Any help is most welcome. TIA,
Jiri Svoboda
------- Pasted error message -----
java.security.PrivilegedActionException: java.lang.reflect.InvocationTargetException
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.plugin.liveconnect.SecureInvocation$2.run(SecureInvocation.java:141)
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.plugin.liveconnect.SecureInvocation.CallMethod(SecureInvocation.java:122)
     at sun.plugin.navig.motif.AThread.handleRequest(Native Method)
     at sun.plugin.navig.motif.AThread.JNIHandleLoop(AThread.java:40)
     at sun.plugin.navig.motif.AThread.run(AThread.java:32)
Caused by: java.lang.reflect.InvocationTargetException
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at sun.plugin.javascript.JSInvoke.invoke(JSInvoke.java:19)
     at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at sun.plugin.javascript.JSClassLoader.invoke(JSClassLoader.java:70)
     at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(SecureInvocation.java:566)
     ... 7 more
Caused by: java.security.AccessControlException: access denied (java.net.SocketPermission 81.2.194.76:80 connect,resolve)
     at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
     at java.security.AccessController.checkPermission(AccessController.java:546)
     at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
     at java.lang.SecurityManager.checkConnect(SecurityManager.java:1034)
     at java.net.Socket.connect(Socket.java:513)
     at sun.net.NetworkClient.doConnect(NetworkClient.java:155)
     at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
     at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
     at sun.net.www.http.HttpClient.<init>(HttpClient.java:233)
     at sun.net.www.http.HttpClient.New(HttpClient.java:306)
     at sun.net.www.http.HttpClient.New(HttpClient.java:323)
     at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:788)
     at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:729)
     at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:654)
     at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:977)
     at java.net.URL.openStream(URL.java:1009)
     at AudioPlayer.getAudioStream(AudioPlayer.java:32)
     at AudioPlayer.startPlaying(AudioPlayer.java:133)
     ... 17 more

Thank you for contacting us to let us know you are experiencing a problem.   Yes, we have addressed the issues we were experiencing earlier.
I believe the problem you are facing is bcause you must use the original user ID you provisioned with your Xfinity Home account. Unfortunately, we only support a single user ID per account on the mobile applications today. We do plan to change this in the future.
I will private message you with the user ID to try on your mobile account.

Applet cannot be openned by Netscape 6.2

When our customers try to open our applet with Netscape 6.2, they get an AccessControlException: access denied(java.lang.RuntimePermission accessClassInPackage.sun.misc).
Anyone knows what wrong here and what is the solution?
Thanks,
Li

You are probably trying to do something in your code that is not allowed by an unsigned applet, for example accessing a file or sending TCP/IP packets out of the computer. To allow this kind of stuff you need to sign the applet.

Java.security.AccessControlException: access denied when loading from a jar

Hello!
I am trying to deploy an applet into a browser but I have encountered a security problem.
The name of the applet is SWTInBrowser(not exactly mine, it's an example from the web).
package my.applet;
import org.eclipse.swt.awt.SWT_AWT;
import java.applet.Applet;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import java.awt.Canvas;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Listener;
import org.eclipse.swt.widgets.Event;
import org.eclipse.swt.graphics.Point;
import org.eclipse.swt.layout.FillLayout;
public class SWTInBrowser extends Applet implements Runnable{
     public void init () {
           /* Create Example AWT and Swing widgets */
           java.awt.Button awtButton = new java.awt.Button("AWT Button");
           add(awtButton);
           awtButton.addActionListener(new ActionListener () {
            public void actionPerformed (ActionEvent event) {
             showStatus ("AWT Button Selected");
           javax.swing.JButton jButton = new javax.swing.JButton("Swing Button");
           add(jButton);
           jButton.addActionListener(new ActionListener () {
            public void actionPerformed (ActionEvent event) {
             showStatus ("Swing Button Selected");
           Thread swtUIThread = new Thread (this);
           swtUIThread.start ();
          public void run() {
           /* Create an SWT Composite from an AWT canvas to be the parent of the SWT
          widgets.
            * The AWT Canvas will be layed out by the Applet layout manager. The
          layout of the
            * SWT widgets is handled by the application (see below).
           Canvas awtParent = new Canvas();
           add(awtParent);
           Display display = new Display();
           Shell swtParent = SWT_AWT.new_Shell(display, awtParent);
//           Display display = swtParent.getDisplay();
           swtParent.setLayout(new FillLayout());
           /* Create SWT widget */
           org.eclipse.swt.widgets.Button swtButton = new
          org.eclipse.swt.widgets.Button(swtParent, SWT.PUSH);
           swtButton.setText("SWT Button");
           swtButton.addListener(SWT.Selection, new Listener() {
            public void handleEvent(Event event){
             showStatus("SWT Button selected.");
           swtButton.addListener(SWT.Dispose, new Listener() {
            public void handleEvent(Event event){
             System.out.println("Button was disposed.");
           // Size AWT Panel so that it is big enough to hold the SWT widgets
           Point size = swtParent.computeSize (SWT.DEFAULT, SWT.DEFAULT);
           awtParent.setSize(size.x + 2, size.y + 2);
           // Need to invoke the AWT layout manager or AWT and Swing
           // widgets will not be visible
           validate();
           // The SWT widget(s) require an event loop
           while (!swtParent.isDisposed()) {
            if (!display.readAndDispatch()) display.sleep ();
}It works perfectly in the Applet Viewer, but not in the browser. In the browser, I only get two buttons working, the SWT button doesn't appear, because of this error:
Exception in thread "Thread-21" java.lang.ExceptionInInitializerError
     at org.eclipse.swt.widgets.Display.<clinit>(Display.java:130)
     at my.applet.SWTInBrowser.run(SWTInBrowser.java:52)
     at java.lang.Thread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission sun.arch.data.model read)
     at java.security.AccessControlContext.checkPermission(Unknown Source)
     at java.security.AccessController.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
     at java.lang.System.getProperty(Unknown Source)
     at org.eclipse.swt.internal.Library.loadLibrary(Library.java:167)
     at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151)
     at org.eclipse.swt.internal.C.<clinit>(C.java:21)
     ... 3 moreI have exported the application in a jar, and in that jar I have put the swt.jar that the application need for the displaying of the third button, swt button.
Here is also the HTML file:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=Cp1252"/>
    <title>
      Test
    </title>
</head>
<body>
    <p>
          <applet code="my.applet.SWTInBrowser"
                    archive="Test.jar"
                    width="1400" height="800">
          </applet>
    </p>
</body>
</html>Could anyone please help me solve this problem?

This is in reply to the first post. I don't know what happened after.
Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission sun.arch.data.model read)
     at java.security.AccessControlContext.checkPermission(Unknown Source)
     at java.security.AccessController.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
     at java.lang.System.getProperty(Unknown Source)
     at org.eclipse.swt.internal.Library.loadLibrary(Library.java:167)
     at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151)
     at org.eclipse.swt.internal.C.<clinit>(C.java:21)
If you read the above trace from bottom to top, it shows none of you classes, only classes from that Eclipse library, which seems to loadLibrary() a native DLL. In order to do this, it needs to call System.getProperty( "sun.arch.data.model" ). This call is not allowed from un unsigned applet. So I guess you need to sign the applet and this problem will go away. Many other problems may follow. Just read very very carefully all the related documentation, which I did not.

1.5 allows setStub() by unsigned applets?

Similar Messages

Maybe you are looking for