java.security.AccessControlException: access denied ("java.net.SocketPermission" "smtp.gmail.com" "resolve")

Question

I am using GlassFish Server 3.1 and the Java mail Api 1.4.5.

Scenario: I have an applet, that when clicked it sends an email message.

Send the mail works perfectly on Netbeans AppletViewer, but it turns into hell when added to the browser and trying to send the email from there.

I have read for hours, about policy files, signed/unsigned applets...etc.

I have tried using the signed applet (plenty of tutorials out there for signing it, was quite simple using the keytools from java). When I run it on the browser it asks for permission because it´s a self-signed certificate, I give it permission , but it still spits out the same exception.

I have also tried modifying java.poilcy file adding

permission java.net.SocketPermission "smtp.gmail.com:587", "listen,resolve";

But nothing.

I know it´s that exception because I activaded the Java Console in the Java Control Panel. I really don´t know what else to do.

Here is the code that sends the email:

    String host = "smtp.gmail.com";
    String from = *****;
    String pass = ******;
    Properties props = new Properties();
    props.put("mail.smtp.starttls.enable", "true");
    props.put("mail.smtp.host", host);
    props.put("mail.smtp.user", from);
    props.put("mail.smtp.password", pass);
    props.put("mail.smtp.port", "587");
    props.put("mail.smtp.auth", "true");

    Session session = Session.getDefaultInstance(props, null);
    this.message = new MimeMessage(session);
    message.setFrom(new InternetAddress(from));

    InternetAddress toAddress = new InternetAddress(this.to);
    this.message.addRecipient(Message.RecipientType.TO, toAddress);

    this.message.setSubject(this.subject);

    this.message.setText(this.body);

    Transport transport = session.getTransport("smtp");
    transport.connect(host, from, pass);
    transport.sendMessage(this.message, this.message.getAllRecipients());
    transport.close();

Solution 1

JApplet is in a "sandbox" on it's own, given different permissions than regular applications (applications are only executed when the users chooses directly to do so, hence, the user accepts the consequences). A JApplet executes when a browser downloads it, giving the user no option whatsoever, that´s why if you want to have your applet deployed and executed by others (when the applet accesses servers others than the one from which it is deployed) it must be signed (either a self-signed certificate or a certificate signed by an authorized organization, which usually implies paying some fees) so that the user can "Accept" the consequences of using said Applet, allowing it "out of the sandbox".

For some reason, signing it with a self-cert using keytolls and jarsigner did not work for me whatsoever. Even though when I accessed the webpage and the browser warned me about executing the applet (giving me the option to not execute it) and I accepted said warning, it seemed the JApplet was not getting it´s permissions.

My boyfriend suggested moving the email class out of the "sandbox". He solved it (bless him!), moving the emailClass (the one which uses the java mail api) to the server gave no problems whatsoever. Using the Front Controller Command for Client-Server Arquitecture, all I had to do was implement my Controller class with the code that I posted at the beginning of the question, and send from my applet (when the button was clicked) an http-request with the toEmailAddress, subject, and body to my servlet.

Works perfect.

Solution 2

You must sign the applet so it can connect to a host other than the one it was loaded from, and either you must use a non-self-signed-certificate or the user must accept the certificate when prompted.

Solution 3

Several things to look at:

1) double check and make sure your applet signing is correct:

• http://www-personal.umich.edu/~lsiden/tutorials/signed-applet/signed-applet.html

2) Look at crossdomain.xml:

• access denied (java.net.SocketPermission 127.0.0.1:8080 connect,resolve)

3) Look at applet.policy

• Why does my applet get a java.security.AccessControlException: access denied (java.net.SocketPermission ...), and how can I avoid it?

Solution 4

Distribute you program with JNLP with signature, is easy and solve this kind of situations.

Check tutorials about JNLP of your IDE and read this for more info: http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html

View more solutions

Comments

[Chayemor]

I have signed the applet with the following instructions keytool -genkey -keystore akeystore -keyalg rsa -dname "CN=Johanna Daniel, OU=Universidad, O=Universidad, L=Atlanta, ST=GA,C=NL" -alias aks -validity 3600 -keypass password-storepass password // jarsigner -keystore akeystore -storepass password-keypass paswword -signedjar ArkanoidS.jar Arkanoid.jar aks I have also used the -verify option of jarsigner to "verify" that my ArkanoidS.jar was signed. It was this jar (the SIGNED ONE) that I added to my webapplication and to the html tag. It´s still not working.

[user207421]

@Joy So you've satisfied one out of the three conditions I enumerated.

[paulsm4]

Hi - I'm glad you resolved it :). As you saw, there were two issues: 1) the applet needed to be "signed", and 2) access was not "cross-domain"

[Chayemor]

I don´t understand what conditions wheren´t fulfilled. You asked for the applet to be signed with either a non-self-signed-certificate or a self-signed-one (in the last case, the user will be prompted to accept to execute the applet even though it's been signed from a non-authorized entity, meaning it has a self-signed certificate). I did all of that, when executed on the browser I was prompted by it, and I accepted the terms and told it to execute it. It kept on getting the same exception.

[Satish]

signing it with a self-cert using keytolls and jarsigner did not work for me either. I am using jre7. I am trying to read a file stored in desktop.

[user1568901]

I'm fighting the same error from JNLP launched applications right now. Work fine when run directly from the JAR, but when JNLP launched fail the same way. :-(

[Daniel De León]

Your app must be run out of the sandbox to access more resources, and there is another way to achieve it too, but is more annoying for the user that just accept a signature.