Riven
« League of Dukes » JGO Kernel  Posts: 5870 Medals: 255
Hand over your head.
|
 |
«
Reply #30 on:
2010-04-06 07:58:57 » |
|
and finally yes signed/unsigned does not work anymore ( after 3 years of using it... this is just ununderstandable & STUPID ! ) and always show a security dialog... bravo... clap clap to Sun
Actually, if you add "Trusted-Library: true" to the manifest, it does not immediately show the security dialog, but... once it does, it either hangs or Class.forName("some.secure.package.SecureClass") throws a ClassNotFoundException, because the classloaders are strictly separated. There must be a way... |
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
DzzD
|
|
«
Reply #31 on:
2010-04-06 08:03:14 » |
|
Actually, if you add "Trusted-Library: true" to the manifest, it does not immediately show the security dialog, but... once it does, it either hangs or Class.forName("some.secure.package.SecureClass") throws a ClassNotFoundException, because the classloaders are strictly separated.
There must be a way...
thanks, I am looking on this solution right now, I hope it will do the trick... at least until the 1.6-20 release get out .... |
|
|
|
kappa
« League of Dukes » JGO Kernel Posts: 2360 Medals: 59
★★★★★
|
|
«
Reply #32 on:
2010-04-06 08:13:57 » |
|
LWJGL AppletLoader also broke due to this sudden update and change on how classloaders work with mixed signed/unsigned jars. However its fixed now and LWJGL 2.4 should be out soon.
Anyway since the loader shows the security dialog at initialisation its easy to work round any later issues due to the extra permissions, what you guys are trying to do is gonna be pretty tricky now due to the changes (i.e. get security dialog to show from an unsigned jar).
|
|
|
|
|
Games published by our own members! Go get 'em! 
|
|
|
DzzD
|
|
«
Reply #33 on:
2010-04-06 08:21:11 » |
|
LWJGL AppletLoader also broke due to this sudden update and change on how classloaders work with mixed signed/unsigned jars. However its fixed now and LWJGL 2.4 should be out soon. nice to know you manage to fix it for LWJGL, but does it apply for people having made Applet with older LWJGL ? as a side note: 3DzzD Applets still works too ( either you press yes or no they will work ) but the problem, what make me angry is that you now get a scary popup at startup ... how Sun can made such fundamental change !? |
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #34 on:
2010-04-06 08:48:35 » |
|
how Sun can made such fundamental change !?
versions 6u14 (and up) were bad too:  |
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
kappa
« League of Dukes » JGO Kernel Posts: 2360 Medals: 59
★★★★★
|
|
«
Reply #35 on:
2010-04-06 08:51:21 » |
|
nice to know you manage to fix it for LWJGL, but does it apply for people having made Applet with older LWJGL ?
only effects ppl using an older LWJGL who were using a mix of signed and unsigned jars (by that I mean only the lwjgl_util_applet.jar and lzma.jar), shouldn't effect those that were signed all the jars. |
|
|
|
|
Markus_Persson
JGO Kernel  Posts: 2092 Medals: 10
Mojang Specifications
|
|
«
Reply #36 on:
2010-04-07 08:12:40 » |
|
I had all jars signed with the same certificate and it still happened to me. I think the reason was that some of the jars were also lzma compressed, causing java to consider them to be unsigned binary files.
Adding "Trusted-Library: true" to the manifest in the two jars directly loaded by java made all the problems go away.
|
|
|
|
|
DzzD
|
|
«
Reply #37 on:
2010-04-07 09:48:38 » |
|
I really cant understand how and who validate such change in the plugin... this seems so stupid & risky...
1 - it is incompatible with old Applet and make severals of them crash or display scary & confusing popup
2 - it DOES NOT make anything more secure and then it is only a useless & regressive change : I think about that using liveconnect, untrusted code can still command trusted code (via delayed or not javascript) without any warning but this is just more boring & complicated to do this way for real world project and so profesional wont use this way but hackers will ... so it make real company work lot more complicate while it does not make hackers life harder...
how the hell Sun/Oracle validate such Genius new plugin ideas ?
|
|
|
|
princec
« League of Dukes » JGO Kernel Posts: 8089 Medals: 96
Eh? Who? What? ... Me?
|
|
«
Reply #38 on:
2010-04-07 09:52:26 » |
|
Who knows. I wonder how hard it is to write a plugin for browsers. Can't be that difficult. I've got a LWJGL+JRE at about 3mb if anyone's interested and it could probably be even smaller still. Cas  |
|
|
|
kappa
« League of Dukes » JGO Kernel Posts: 2360 Medals: 59
★★★★★
|
|
«
Reply #39 on:
2010-04-07 14:07:01 » |
|
hmm, going the custom plugin route would be cool as it'd give us complete control over how the plugin works, runs and would finally give us a chance to get it right (something that Sun/Oracle have failed at for the last decade) However going the custom plugin route is IMO a rather difficult task, especially as you'd have to get it right on all the platforms + different browsers. It'd also require doing C/C++ combined with Java (jni?) which is always a pain. Also ppl don't like installing plugins, just take the example of Unity3D, that is one plugin that IMO got almost everything right and nailed the user experience. However many ppl just avoid Unity3d games as they don't want to install yet another plugin. Its hard to ignore a present user base of about 60% of all computers already having the java plugin. I think you can still get a decent user experience with the java plugin (provided you jump lots of hoops, bugs, limitations, issues, security dialogs, etc) still IMO easier then going the custom plugin route where its an uphill battle to get users to install it. |
|
|
|
|
Games published by our own members! Go get 'em! 
|
|
bobjob
JGO Ninja Posts: 646 Medals: 14
David Aaron Muhar
|
|
«
Reply #40 on:
2010-04-09 07:40:34 » |
|
A plugin would be great, if it had JRE to fall back on.
|
|
|
|
|
DzzD
|
|
«
Reply #41 on:
2010-04-09 19:28:14 » |
|
I would love it and really believe that it is doable, but unfortunatly it is only interresting if you can reach at least something like 50% of market place wich will probably requiere huge money to be competitive against flash/java : advertisments / contract with major : MS / mozilla / google / apple (NB: a contract/accord with MS will be far a sufficient start ...), or requiere an excellent idea that would make people think that it is a requiered/needed plugin (as flash)
but sure with a cupple of volunters we could have done better plugin (including plugin release update & managment) then what Sun did for last ten years... IMHO : Sun try to go too fast and do not finish/fix current issue, dont take care of existing works, release update at a too high frequency
|
|
|
|
h3ckboy
JGO Kernel Posts: 1645 Medals: 4
|
|
«
Reply #42 on:
2010-04-09 19:33:22 » |
|
A plugin would be great, if it had JRE to fall back on.
is that possible? cause if so, then ppl dont HAVE to get it, just only if they want something better |
|
|
|
|
bobjob
JGO Ninja Posts: 646 Medals: 14
David Aaron Muhar
|
|
«
Reply #43 on:
2010-04-09 22:18:52 » |
|
is that possible? cause if so, then ppl dont HAVE to get it, just only if they want something better
I dont see why not, if you had something like: 1
2
3
4
5
6
7
| <jgo width="100%" height="90%" code="MainApplet" archive="unsigned.jar, signed.jar">
<param name="separate_jvm" value="true">
<applet width="100%" height="90%" code="MainApplet" archive="unsigned.jar, signed.jar">
<param name="separate_jvm" value="true">
<p ALIGN=center>You need the JGO Plug... click here link blah blah blah</p>
</applet>
</jgo> |
Im assuming that the plugin would work in its own vm. or rather in a seperate vm for each instance. It should work after installing, without restart of browser. Would be a big task though, what to include, and what to strip back on. Kaffe might be a good starting place as the plugin is only needed for applets. there would be a few core security issues to work through im sure. anyway just some ideas. I would be willing to invest a decent chunk of time into a project like this edit: mac wouldnt be a problem as it uses its own VM, that doesnt give such ugly restrictions |
|
|
|
|
DzzD
|
|
«
Reply #44 on:
2010-04-10 13:25:50 » |
|
one possible solution may be to do ... but sooo boring.... myUnignedApplet.html 1
| <APPLET archive="unsigned.jar" MAYSCRIPT></APPLET> |
mySignedApplet.html 1
| <APPLET archive="signed.jar" MAYSCRIPT></APPLET> |
when requiere secured privilege from myUnignedApplet.html: 1
| this.getAppletContext().showDocument("mySignedApplet.html","myHiddenFrame"); |
and then acces signed applet method via DOM/Javascript but I dont like it, that's really not a clean/final solution |
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #45 on:
2010-04-10 13:40:14 » |
|
Good idea, might work, but it's a horrible workaround.
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
bobjob
JGO Ninja Posts: 646 Medals: 14
David Aaron Muhar
|
|
«
Reply #46 on:
2010-04-15 07:09:37 » |
|
I decided to go with a front page without restricted needs. then when it requires permissions, it opens up another URL on "_self" and passes information via a URL query string.
|
|
|
|
|
|
ryanm
« League of Dukes » JGO Strike Force Posts: 788 Medals: 4
Used to be bleb
|
|
«
Reply #48 on:
2010-04-16 10:17:35 » |
|
Awesome stuff, they apparently don't even test the update announcements!
|
|
|
|
|
kappa
« League of Dukes » JGO Kernel Posts: 2360 Medals: 59
★★★★★
|
|
«
Reply #49 on:
2010-04-16 10:18:12 » |
|
They *might* have fixed some of the things that were broken in u19
nope unfortunetly they haven't, u20 was simply rushed out to fix the jws exploit that was giving java/oracle bad press on almost all the tech sites. |
|
|
|
|
endolf
« League of Dukes » JGO Kernel Posts: 1597 Medals: 2
Current project release date: sometime in 3003
|
|
«
Reply #50 on:
2010-04-16 11:53:47 » |
|
I didn't install u19, I just installed u20 and neither my webstart app (uses LWJGL) or jinput applet present any extra warning dialogs. They are unchanged so as they were before this sorry mess started.
HTH
Endolf
|
|
|
|
Mr. Gol
Full Member Posts: 214 Medals: 1
|
|
«
Reply #51 on:
2010-04-16 13:53:23 » |
|
edit: mac wouldnt be a problem as it uses its own VM, that doesnt give such ugly restrictions
Too early to say. Apple's Java version always lags behind Sun's, it's currently at 1.6.0_17. Who knows what will happen in the next release?  |
|
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #52 on:
2010-06-22 12:52:25 » |
|
I found a workaround to delay the security dialog, using two applets: one signed and one unsigned. This is the HTML with the two applets (the signed applet is commented out): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
| <html>
<head>
<script type='text/javascript'>
function openSignedApplet()
{
var holder = document.getElementById('signed_holder');
var html = holder.innerHTML; var off = html.indexOf('<applet');
var end = html.indexOf('</applet>')+9;
holder.innerHTML = html.substring(off, end); }
</script>
</head>
<body>
<div id='unsigned_holder'>
<applet name="unsigned"
code="MixedUnsignedApplet.class"
archive="/unsigned.jar"
width="512" height="64">
</applet>
</div>
<hr>
<div id='signed_holder'>
<!--
<applet name="signed"
code="MixedSignedApplet.class"
archive="signed.jar"
width="512" height="64">
</applet>
-->
</div>
</body>
</html> |
This code is used by both applets to find eachother: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
| public class MixedAppletCommunication
{
public static Applet waitForCompanion(Applet self)
{
while (true)
{
Applet applet = getCompanion(self);
if (applet != null)
{
return applet;
}
Thread.sleep(100L);
}
}
public static Applet getCompanion(Applet self)
{
Enumeration<Applet> applets = self.getAppletContext().getApplets();
while (applets.hasMoreElements())
{
Applet applet = applets.nextElement();
if (applet == null)
{
continue;
}
if (applet == self)
{
continue;
}
if (applet.getClass().getName().equals(self.getClass().getName()))
{
continue;
}
return applet;
}
return null;
}
} |
The unsigned applet activates (uncomments) the signed applet using: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| AppletPluginUtil.evalJavascript(unsignedApplet, "openSignedApplet();");
public class AppletPluginUtil
{
public static Object evalJavascript(Applet applet, String script) throws IllegalStateException
{
try
{
Class< ? > clazz = Class.forName("netscape.javascript.JSObject");
Object jsObject = clazz.getMethod("getWindow", Applet.class).invoke(null, applet);
Method jsEval = clazz.getMethod("eval", String.class);
return jsEval.invoke(jsObject, script);
}
catch (Exception exc)
{
throw new IllegalStateException(script, exc);
}
}
} |
Both applets are in seperate classloaders, so AFAIK, the only way to communicate between the applets is to write a protocol around applet.setName() and applet.getName() on both applets. That means all your transfered data must be serialized, converted to a String, and passed to the other applet using applet.setName(String); At the moment I'm sending byte[]s back and forth, as char[]s, with two bytes per char (no encoding), which is fast. You can hook into the setName() call using applet.addPropertyChangeListener("name", listener), so that you don't have to poll getName() for updates. I implemented this, and I can, using rather highlevel code, request a FileInputStream in the unsigned applet, pass the request to the signed applet, create it and pump it through getName()/setName() in both applets, and reconstruct an InputStream in the unsigned applet, which can be read like any other stream. 1
2
3
4
5
6
| AppletPluginUtil.evalJavascript(unsignedApplet, "openSignedApplet();");
InputStream in = unsignedApplet.createRemoteFileInputStream(new File(path));
OutputStream out = unsignedApplet.createRemoteFileOutputStream(new File(path));
Pair<InputStream, OutputStream> socket = unsignedApplet.createRemoteSocketStreams(host, port); |
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
CommanderKeith
JGO Wizard Posts: 1455 Medals: 9
|
|
«
Reply #53 on:
2010-06-22 22:09:51 » |
|
Genius! Do you think they'll classify this as a security threat and make another dysfunctional update?
|
|
|
|
bobjob
JGO Ninja Posts: 646 Medals: 14
David Aaron Muhar
|
|
«
Reply #54 on:
2010-06-23 05:25:07 » |
|
Riven strikes again. Genius! Do you think they'll classify this as a security threat and make another dysfunctional update?
As fas as being a security risk I personally doubt it, as it still would require signing of the applet to get secure access. |
|
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #55 on:
2010-06-23 10:36:10 » |
|
Riven strikes again.
As fas as being a security risk I personally doubt it, as it still would require signing of the applet to get secure access.
That's the same with any signed/unsigned code, and Oracle crippled exactly that. |
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
Riven
« League of Dukes » JGO Kernel Posts: 5870 Medals: 255
Hand over your head.
|
|
«
Reply #56 on:
2010-06-23 10:38:04 » |
|
Besides that, I have another slower solution (inefficiently bruteforcing 'something' at max 8MB/sec), which, for the sake of making sure it won't get crippled, I keep a secret...  also, we can always communicate through javascript. |
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings |
|
|
|
