make groovyConsole browser friendly

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.5.6
  • Fix Version/s: 1.6-beta-2
  • Component/s: Swing
  • Labels:
    None

Description

It would be of use to easily be able to embed a groovy console in a web page as an applet. Binding the service tier of a web application to the console and exposing this to administrators or users via the console would offer a much richer and more comfortable operating environment than evaluating scripts POSTed from simple textarea boxes on web forms.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Danno Ferrin added a comment -

You'll need to sign the jar. Tested with this simple page...

<html>
<body>
<applet archive="groovy-all-1.6-beta-2-SNAPSHOT.jar" code="groovy.ui.ConsoleApplet" width='800' height='600' />
</body>
</html>
Show
Danno Ferrin added a comment - You'll need to sign the jar. Tested with this simple page... 
<html>
<body>
<applet archive="groovy-all-1.6-beta-2-SNAPSHOT.jar" code="groovy.ui.ConsoleApplet" width='800' height='600' />
</body>
</html>
Hide
Permalink
Kennard Consulting added a comment -

Hey guys,

Thanks for an awesome product!

Can I just clarify: when I try the above simple page with the 'groovy-all-1.6-beta-2.jar' from the Beta 2 distribution, I get a security error.

The note above says I 'need to sign the jar'. Do you mean I have to sign the Groovy JAR itself? Surely you don't want everybody who wants to put this on a Web page having to self-sign your Groovy JAR?

Is there no way it can just work out of the box? Either by trapping the security exception or having Groovy/Codehaus sign the JAR? After all, it is Groovy that is asserting there are no security problems with the Console, not the developer embedding it on their Web page (who cannot be expected to verify the inner workings of the console).

Show
Kennard Consulting added a comment - Hey guys, Thanks for an awesome product! Can I just clarify: when I try the above simple page with the 'groovy-all-1.6-beta-2.jar' from the Beta 2 distribution, I get a security error. The note above says I 'need to sign the jar'. Do you mean I have to sign the Groovy JAR itself? Surely you don't want everybody who wants to put this on a Web page having to self-sign your Groovy JAR? Is there no way it can just work out of the box? Either by trapping the security exception or having Groovy/Codehaus sign the JAR? After all, it is Groovy that is asserting there are no security problems with the Console, not the developer embedding it on their Web page (who cannot be expected to verify the inner workings of the console).
Hide
Permalink
Danno Ferrin added a comment -

You have to sign the groovy jar itself.

This is a limitation imposed on groovy by the JVM itself. We cannot trap the security exception because it is acting as a guard preventing us from doing what Groovy needs to do (reflection based method invocations).

Signing the groovy jar is fairly easy for a self signed cert: http://ww2.cs.fsu.edu/~steele/SECURITY/appletSecurity.html However nobody has publicly released a root-signed jar publicly available yet.

Show
Danno Ferrin added a comment - You have to sign the groovy jar itself. This is a limitation imposed on groovy by the JVM itself. We cannot trap the security exception because it is acting as a guard preventing us from doing what Groovy needs to do (reflection based method invocations). Signing the groovy jar is fairly easy for a self signed cert: http://ww2.cs.fsu.edu/~steele/SECURITY/appletSecurity.html However nobody has publicly released a root-signed jar publicly available yet.
Hide
Permalink
Kennard Consulting added a comment -

Danno,

Thanks for the quick reply!

If signing is unavoidable that's fair enough. However I'm still puzzled as to why each developer has to sign (and distribute) their own version of groovy.jar, rather than the Groovy team signing the JAR?

Isn't signing meant to mean 'the signor promises the following JAR will not hurt your system'? If that's true, shouldn't the signor be the Groovy team who wrote the code, not each and every developer who tries to embed the applet?

I just think signing (even self-signing) is an extra unnecessary hurdle for developers?

Regards,

Richard.

Show
Kennard Consulting added a comment - Danno, Thanks for the quick reply! If signing is unavoidable that's fair enough. However I'm still puzzled as to why each developer has to sign (and distribute) their own version of groovy.jar, rather than the Groovy team signing the JAR? Isn't signing meant to mean 'the signor promises the following JAR will not hurt your system'? If that's true, shouldn't the signor be the Groovy team who wrote the code, not each and every developer who tries to embed the applet? I just think signing (even self-signing) is an extra unnecessary hurdle for developers? Regards, Richard.
Hide
Permalink
Danno Ferrin added a comment -

It's about money. In order for a signature by the groovy team to mean anything it would need to be signed on a cert that is signed by a Certificate Authority. Those run several hundred a year. So it's about money, that's why it's not done.

Show
Danno Ferrin added a comment - It's about money. In order for a signature by the groovy team to mean anything it would need to be signed on a cert that is signed by a Certificate Authority. Those run several hundred a year. So it's about money, that's why it's not done.
Hide
Permalink
Kennard Consulting added a comment -

Fair enough.

But perhaps the advice should be to subclass GroovyApplet into your own little JAR and sign that JAR, rather than groovy.jar itself. I'm thinking if you sign the groovy.jar, Java will have to redownload it (all 4MB of it) even if you already have groovy.jar in your cache from some other Web site?

Show
Kennard Consulting added a comment - Fair enough. But perhaps the advice should be to subclass GroovyApplet into your own little JAR and sign that JAR, rather than groovy.jar itself. I'm thinking if you sign the groovy.jar, Java will have to redownload it (all 4MB of it) even if you already have groovy.jar in your cache from some other Web site?
Hide
Permalink
Danno Ferrin added a comment -

For an applet (at least pre 6u10) IIRC all jars have to be signed by the same signer or they are all treated by the security system as unsigned. Besides, it isn't the Groovy applet that requires the signature, it the stuff in various org.codehaus.groovy packages. So just signing the applet gets you nothing since the code tripping the security alarm is in the 4MB download.

Show
Danno Ferrin added a comment - For an applet (at least pre 6u10) IIRC all jars have to be signed by the same signer or they are all treated by the security system as unsigned. Besides, it isn't the Groovy applet that requires the signature, it the stuff in various org.codehaus.groovy packages. So just signing the applet gets you nothing since the code tripping the security alarm is in the 4MB download.
Hide
Permalink
Kennard Consulting added a comment -

Excellent point. In that case, I will just have to sign the groovy.jar itself. Thanks for all your help, and sorry for wasting your time.

This would all be a lot easier if everyone could just trust each other

Show
Kennard Consulting added a comment - Excellent point. In that case, I will just have to sign the groovy.jar itself. Thanks for all your help, and sorry for wasting your time. This would all be a lot easier if everyone could just trust each other
Hide
Permalink
Kennard Consulting added a comment -

Hey Danno - me again.

I have tried implementing the above, and it works really well locally or over an Intranet. Once out on the Internet, however, the console applet seems to take FOREVER to start up. If you go to...

http://metawidget.sourceforge.net/live-demo/demo.html

...it downloads the JAR and then just sits there on a grey screen. If you open the applet console and press '5' you'll see it does...

network: Connecting http://metawidget.sourceforge.net/live-demo/groovy/lang/DelegatingMetaClassBeanInfo.class with proxy=DIRECT
network: Cache entry not found [url: http://metawidget.sourceforge.net/live-demo/groovy/lang/DelegatingMetaClassBeanInfo.class, version: null]

...for every single class it needs. Essentially ignoring the downloaded JAR and reconnecting back to the server for each class. Is this related to Groovy's ClassLoader?

Richard.

Show
Kennard Consulting added a comment - Hey Danno - me again. I have tried implementing the above, and it works really well locally or over an Intranet. Once out on the Internet, however, the console applet seems to take FOREVER to start up. If you go to... http://metawidget.sourceforge.net/live-demo/demo.html ...it downloads the JAR and then just sits there on a grey screen. If you open the applet console and press '5' you'll see it does... network: Connecting http://metawidget.sourceforge.net/live-demo/groovy/lang/DelegatingMetaClassBeanInfo.class with proxy=DIRECT network: Cache entry not found [url: http://metawidget.sourceforge.net/live-demo/groovy/lang/DelegatingMetaClassBeanInfo.class, version: null] ...for every single class it needs. Essentially ignoring the downloaded JAR and reconnecting back to the server for each class. Is this related to Groovy's ClassLoader? Richard.
Hide
Permalink
Danno Ferrin added a comment -

use the codebase_lookup param and set it to false:

<PARAM NAME='codebase_lookup' VALUE='false'>

here's some's blog post on the subject:

http://www.runningasroot.com/blog/2008/08/08/more-on-applets-and-codebase_lookup/

Show
Danno Ferrin added a comment - use the codebase_lookup param and set it to false: <PARAM NAME='codebase_lookup' VALUE='false'> here's some's blog post on the subject: http://www.runningasroot.com/blog/2008/08/08/more-on-applets-and-codebase_lookup/
Hide
Permalink
Kennard Consulting added a comment -

Brilliant. Works like a charm.

Thanks so much,

Richard.

Show
Kennard Consulting added a comment - Brilliant. Works like a charm. Thanks so much, Richard.

People

  • Assignee:
    Danno Ferrin
    Reporter:
    Darren Davison
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: