I know there's a guide on how to create a libGDX applet, but I feel it's highly outdated and somewhat confusing. Here's what I've already done:
Created applet class in my desktop project:
public class DesktopApplet extends LwjglApplet {
private final static LwjglApplicationConfiguration DEFAULT_CONFIG =
new LwjglApplicationConfiguration() {
{
width = 512;
height = 512;
}
};
public DesktopApplet() {
super(new Core(),DEFAULT_CONFIG);
}
private static final long serialVersionUID = -1916205038641068252L;
}
Exported desktop project as a regular jar. Added the project's jar (along with gdx and all lwjgl jars in "applet/basic" folder).
Created a html file, based on basic lwjgl applet and the tutorial:
<applet code="org.lwjgl.util.applet.AppletLoader" archive="lwjgl_util_applet.jar" codebase="." width="512" height="512">
<!-- Name of Applet, will be used as name of directory it is saved in, and will uniquely identify it in cache -->
<param name="al_title" value="mygametitle">
<!-- Main Applet Class -->
<param name="al_main" value="my.packages.desktop.DesktopApplet">
<!-- List of Jars to add to classpath -->
<param name="al_jars" value="mygamejar.jar, gdx.jar, gdx-backend-lwjgl.jar, lwjgl_applet.jar, lwjgl.jar, jinput.jar, lwjgl_util.jar">
<!-- signed windows natives jar in a jar -->
<param name="al_windows" value="gdx-natives.jar, gdx-backend-lwjgl-natives.jar, windows_natives.jar">
<!-- signed linux natives jar in a jar -->
<param name="al_linux" value="gdx-natives.jar, gdx-backend-lwjgl-natives.jar, linux_natives.jar">
<!-- signed mac osx natives jar in a jar -->
<param name="al_mac" value="gdx-natives.jar, gdx-backend-lwjgl-natives.jar, macosx_natives.jar">
<!-- signed solaris natives jar in a jar -->
<param name="al_solaris" value="gdx-natives.jar, gdx-backend-lwjgl-natives.jar, solaris_natives.jar">
Created a keystore file. Deleted default lwjgl signing (META-INF folders), added timestamps to the signing command, created a bash script for jar signing and - finally - signed all jars. While signing produces no errors, jarsigner -verify returns one warning "This jar contains entries whose certificate chain is not validated." and I'm not sure how to get rid of it. Here's my signing command: jarsigner -keystore .keystore -digestalg SHA1 -tsa http://timestamp.comodoca.com/rfc3161 -storepass mypass $jar gdxkey.
Changed Java security level to medium. It allowed me to - finally - run the applet without security errors (thanks kabb!).
The applet... doesn't work. It stays that an error occurred when "Switching applet". I'm not sure if I exported the right projects - should I include a jar with desktop project or just the core and manually add all assets and libraries?
The issue is that the applet is self signed. As of JDK7u51, self signed and unsigned applications are blocked if your java security settings are set to high or above. You can read more about this here.
To be able to test your applet, you can simply go to the java control panel, go to the security tab, and set the security level to medium.
However, if you wish for other people to be able to run your applet without having to go through the hassle of changing their security settings, you'll have to get a certificate by a Certificate Authority, and sign your applet using that. Unfortunately, this costs money, and there is no workaround to it that I know of.
If you want to run your game in a browser, you could consider using GWT instead. LibGDX has some tutorials on it's wiki on how to setup a project with GWT. However, it could be a hassle, especially if you're using libraries not supported by GWT.
Related
Background
I am trying to use bouncy castle library to decrypt private keys in my war. Now I tested the code first in a standalone app and it worked fine. Now when I am testing it as a webapp in Wildfly8.0 am facing some issues with Bouncy castle.
The Wildfly 8.0 am using has bouncy castle provider module installed. The BC version being used in v1.46.
The code that I have developed uses v1.51.
I have followed the steps mentioned here:
https://developer.jboss.org/thread/175395
bouncycastle + JBoss AS7: JCE cannot authenticate the provider BC - Specifically followed instructions provided in For a specific deployment (preferred)
Already tried
Installing the JCE policy files.
Adding to the provider list.
Problem
The error I am getting is :
unable to read encrypted data: JCE cannot authenticate the provider BC
And the code which triggers the above error, in as follows :
PKCS8EncryptedPrivateKeyInfo kp = (PKCS8EncryptedPrivateKeyInfo) keyPair;
InputDecryptorProvider pkcs8dec = new JceOpenSSLPKCS8DecryptorProviderBuilder()
.setProvider(new BouncyCastleProvider())
.build("somepass".toCharArray());
PrivateKeyInfo pko = kp.decryptPrivateKeyInfo(pkcs8dec);<-- ##Error here
Also to add the details,in my pom.xml I have added the jar with compile scope, so the libs are copied into the war and get installed in WEB-INF/lib.
Any tips to fix the above problem?
I. Combining the idea of Peter (#comment) and https://developer.jboss.org/thread/175395, create "your own bc version" with a custom name:
Create an 'my.bouncycastle' module in the following manner:
Under $JBOSS_HOME/modules, create directory 'my/bouncycastle/main'. Directory 'my' might not be there. ;)
Copy bcprov-[your-version].jar into my/bouncycastle/main
Create file 'bcprov-[your-version].jar.index' in my/bouncycastle/main, which is basically the output of a jar -tf command without the ".class" lines. (pipe&edit...)
I put a blank line at the top because these .index files always seem to have one. I have attached this file as "bcprov-jdk16-1.46.jar.index".
Create a file called "module.xml", also in my/bouncycastle/main, which will point to the jar file and reference module "javax.api" as a dependency.
I have attached this file as 'module.xml'.
The module is complete.
Since I am deploying in an EAR file, I had to add a module dependency entry to my EAR's META-INF/jboss-deployment-structure.xml file, under the section, like so:
(the statement also applies to WAR files, when deployed on top-level, use the custom name as module reference)
<deployment><dependencies><module name="my.bouncycastle" slot="main" export="true"/>
Make certain that the ear's /lib directory does NOT contain bcprov-[your-version].jar. (actually II.)
Notes:
The 'slot="main" and 'export="true" parameters are very important in the jboss-dependency-structure.xml file...
II. Adjust your maven dependency(ies) to:
<scope>provided</scope>
Note: Don't change the maven dependecy(ies group artifacts) to "my.bouncycastle", only the scope, this will ensure you a nice compile-time-behavior by the most IDE's AND will prevent your (maven-)war/jar/ear-plugin from packaging it into libs! (And which would be anyway the correct scope for a dependency like this.)
I am trying to create a deployment rule set as described here: link
I created a simple rule, to allow everything from localhost like
<rule>
<id location="http://localhost" />
<action permission="run" />
</rule>
After I self-signed the jar file and deployed it in Windows when I try to run a self-signed app(jnlp) from localhost it is still blocked.
Application Blocked by Deployment Rule Set.
Can not verify self-signed Deployment Rule Set jar
Q: Can anyone tell me why is not working? Do I have to sign the deployment jar with a verified certificate? I tried to use the deployment rules to avoid the block for my application. I don't want to lower the security or add my site to the trusted list.
Looks like the rule set jar has to be signed with a verified cert:
The rule set defined in the ruleset.xml file must be packaged in a signed JAR file named DeploymentRuleSet.jar. The JAR file must be signed with a valid certificate from a trusted certificate authority.
(from http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_rules.html#package)
This article seems to offer an alternative, which involves importing the self-signed cert on all target machines:
https://blogs.oracle.com/java-platform-group/entry/self_signed_certificates_for_a
HTH
I just have been throught this process and I was successfull. I followed this blog post to make my own ruleset and it worked like a charm. But with only one trick the command to sign the jar the NA must be replaced by the certificate password or you must omit the storepass parameter so it will ask the password interactively.
I think you should check:
You imported your cert as a signing CA so the jar signature can be verified (see the blog post).
Your ruleset follows the specification strictly. I had to remove some comments I added to the ruleset as it failed.
Remove the http:// from the location
I need a suggestion to solve the following problem.
I have two web applications (let's say WEBAPP-A and WEBAPP-B) running under the same application server. Each login page in each application page activates a specific applet
(let's call them JAPP-A and JAPP-B, respectively). These two applets need to use the same DLL.
Each applet (JAPP-A or JAPP-B) works OK when accessing the application separately (in our case the browser used is Internet Explorer 8.0 and the JRE version of the client is 1.7.0_45). However, when redirecting from WEBAPP-A to WEBAPP-B, the applet JAPP-B crashes.
I get the error:
UnsatisfiedLinkError: 'DLL already loaded in another classloader'
So I have tried to use the same classloader for JAPP-A and JAPP-B by setting the same CODEBASE value inside the applet tag and deploying the JAR containing the JAPP-B code under the CODEBASE path, but we got the same error message.
Can anyone suggest an alternative approach in order to get the applet JAPP-B working correctly?
Deploy each applet in it's own Java Virtual Machine. E.G. from Applet Deployment Parameters: separate_jvm.
<APPLET archive="my_applet.jar" code="MyApplet" width="300" height="300">
<PARAM name="java_arguments" value="...">
<!-- use a separate JVM for this applet! -->
<PARAM name="separate_jvm" value="true">
</APPLET>
Why gwt-recaptcha-1.0.0.Beta2.jar blocks script tags in recaptcha jar while linking modules?
In my web application using GWT, I am using captcha verification. For using captcha I used Claudius Hauptmann's gwt-recaptcha-1.0.0.Beta2.jar. In the gwt.xml file of this jar there is a script configuration as follows:
<module>
<inherits name="com.google.gwt.user.User"/>
<script src="https://www.google.com/recaptcha/api/js/recaptcha_ajax.js"/>
</module>
When I run the project it ignores loading the scripts by giving these messages in console:
Linking modules
Bootstrap link for command-line module 'com.web.Ask'
Linking module 'ask'
Invoking Linker Cross-Site-Iframe
Ignoring the following script tags in the gwt.xml file
https://www.google.com/recaptcha/api/js/recaptcha_ajax.js
raphael.js
I would like to know what is the exact reason for ignoring these file. How to resolve it.
PS: before some days it was working perfectly and after some config changes it stopped.
I am not sure about this fix,
please try
Remove linker elements from your GWT module XML like
<add-linker name="xsiframe" />
<set-configuration-property name='xsiframe.failIfScriptTag' value='FALSE' />
I maintain an Eclipse RCP application launched with WebStart. Java 7 u45 made some security changes, and now my application crashes on startup.
I've added to the manifest:
Permissions: all-permissions
Codebase: *
Trusted-Library: true
This removed all of the warning messages from the Control Panel. But I still have a classloader issue when trying to load my IApplication implemenentation, probably the first of my classes to load. This is new to update 45.
I have experienced the same issue and managed to solve it by doing following:
In all manifest files (for each JAR in your RCP project) add these attributes:
Application-Name: My App Name
Permissions: all-permissions
Codebase: *
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Trusted-Library: true
Second part of solution is to make jnlp properties secure by adding jnlp prefix. I have found solution here. You need to do this for framework properties (osgi, eclipse..) and for your properties E.g. instead of:
<property name="eclipse.product" value="com.amdosoft.oct.ui.product"/>
<property name="osgi.instance.area" value="#user.home/Application Data/myApp"/>
<property name="osgi.configuration.area" value="#user.home/Application Data/myApp"/>
<property name="my.App.property" value="someValue"/>
use
<property name="jnlp.eclipse.product" value="com.amdosoft.oct.ui.product"/>
<property name="jnlp.osgi.instance.area" value="#user.home/Application Data/myApp"/>
<property name="jnlp.osgi.configuration.area" value="#user.home/Application Data/myApp"/>
<property name="jnlp.my.App.property" value="someValue"/>
Download eclipse launcher with sources from here
In web start launcher you need to change back property names to old values (without jnlp prefix). You can do that by adding this part of source into main method of WebStartLauncher class.
Properties properties = System.getProperties();
// copy properties to avoid ConcurrentModificationException
Properties copiedProperties = new Properties();
copiedProperties.putAll(properties);
Set<Object> keys = copiedProperties.keySet();
for (Object key : keys) {
if (key instanceof String) {
String keyString = (String) key;
if (keyString.startsWith("jnlp.")) {
// re set all properties starting with the jnlp-prefix
// and set them without the prefix
String property = System.getProperty(keyString);
String replacedKeyString = keyString.replaceFirst("jnlp.", "");
System.setProperty(replacedKeyString, property);
}
}
}
Export you new launcher as runnable JAR and put it in the same directory where your JNLP file is located.
Edit JNLP file by adding this line:
<jar href="myAppLauncher.jar"/>
inside tag and edit your application-desc tag like this:
<application-desc main-class="org.eclipse.equinox.launcher.WebStartMain">
</application-desc>
When 7u25 came out, my application would crash with a classloader issue (sometimes, it was weird). The fix involved nixing my "Components.jnlp" deployment strategy. I had my library files in a separate .jnlp (Components.jnlp, as per a solution I read online back in 2010) and my main .jnlp (launch.jnlp) would load that .jnlp.
Now, it seems the Netbeans-generated .jnlp is sufficient and I no longer need any separate .jnlp for library components. I'm not sure if eclipse gives you an auto-generated .jnlp or not.
In the end, changing the launch.jnlp involved me having to give my clients a new installer that would load the new .jnlp onto their computers. It sucked but it worked.
Also, I'm not sure what Codebase: * is supposed to do. Why don't you just put your actual codebase in there?
If you did not deploy your app with that approach then this answer probably won't help. Might help somebody.
We've had multiple JNLP files up until now, and it seemed to work.
We install our app on customer internal networks, so we can't set a codebase other than * without resigning the entire set of jars for each customer.