ndt-users list created

[Seth Peery <>]

Excellent observation, Tom.

Matt, to help you decide which method is most appropriate for your 
environment, the difference in the two is basically whether you serve 
the .jar file from the same webserver that hosts your other web content, 
or whether you serve the .jar file from the NDT server itself, using the 
built-in fakewww (:7123) or a traditional webserver (:80) installed on 
said NDT box.  A signed applet can open a testing socket to _any_ NDT 
server, while an unsigned applet retrieved via remote codebase can only 
open a socket to the server from whence it came.

The following graphic provides a side-by-side comparison of the 
architecture of each approach.



*FIGURE 1: Comparison of NDT remote codebase vs. signed applet architecture*
[inline graphic also attached as .jpg for plain-text e-mail clients]

Tom's method has the advantage of not requiring applet signing (which, 
depending on your browser, may result in the user seeing a popup 
confirmation informing them that the applet will run with elevated 
privileges).  If you have control of your own NDT server and know in 
advance that you will only be testing against that machine, this is 
probably the better approach.

If you don't have control over an NDT server, you can still use Tom's 
method to request a jarfile from someone else's NDT server.  For 
example, pasting this <applet> tag in any web page will embed the 
MeasurementLab NDT client in your page, and will test against a testing 
server determined by the DONAR system:


         **<applet name="NDT" code=Tcpbw100.class
         codebase="http://ndt.iupui.donar.measurement-lab.org:7123";
         ARCHIVE="Tcpbw100.jar" width=400 height=400> </applet>**

If you're running your own NDT server, you would simply edit the 
'codebase' parameter to point to your server, as Tom suggested.

If you use the remote codebase method, omit the testingServer parameter, 
as the default (and only permitted) behavior in the unsigned client is 
to connect to the server in the applet codebase parameter.  If, for 
example, you try to get an applet from a remote codebase on someone 
else's server (say, MLab), and then tweak the testingServer parameter to 
point to your own server, you'll still get the exception in the subject 
heading of this e-mail.

For extra credit (left as an exercise to the reader), you can even use 
PHP (or server-side programming language of your choice) to write the 
codebase parameter dynamically and perform server selection at runtime 
depending on a set of factors you consider in your application logic.

Again, the distinction here is that in the signed applet method, the 
_applet_ can use the testingServer parameter to decide where it wants to 
test, but in the remote codebase method, you (in your application 
logic/hardcoded APPLET tag) need to decide in advance where you want to 
test against and then retrieve the .jar file from that server -- the 
testing endpoint is then determined by the codebase parameter and the 
testingServer parameter is not used.

The chief advantage of the signing method is that the applet, once 
loaded, can test against an "arbitrary" NDT server that you may or may 
not have control over without reloading the .jar file from somewhere 
else.  In the early days of our involvement with NDT, I found this 
method useful to enable me to serve the applet from my web server, 
instead of NDT's fakewww server, and later to implement some custom 
failover logic in the client that allowed me to sequentially try other 
people's NDT servers in a list.  So there are specialized circumstances 
when you might want to use signing, but as Tom points out, remote 
codebase may be the best method if these don't apply to you.

Summary:  if the applet .jar file lives on your web server that is _not_ 
the NDT server, and you want to be able to test against any NDT server 
by varying the testingServer parameter, use the signing method, but if 
you can serve (or consume) the applet directly from your NDT server (or 
someone else's), and don't want to deal with applet signing, use Tom's 
recommended approach.

Hope this helps you and/or others on the list.

____________________________________________________
Seth Peery
Senior GIS Architect, Enterprise GIS
Virginia Tech Geospatial Information Sciences (0197)
Virginia Polytechnic Institute and State University

(540) 231-2178
http://gis.it.vt.edu/



On 3/5/2011 12:22 PM, Tom Throckmorton wrote:
> On 3/5/11 11:55 AM, Seth Peery wrote:
> > Matt,
> >
> > I see that you're using the testingServer<PARAM>  to point the applet to
> > your own NDT server.  When I developed the functionality for the NDT
> > client to be able to do this, I had to use a bit of a workaround -- you
> > must sign the applet in order to circumvent the security model of the
> > JVM.  By design, unsigned Java applets can only open sockets to the
> > machine from which their codebase was served.
> > java.lang.SecurityException: Permission denied is one of the common
> > errors you'll receive if your applet is trying to access a resource
> > outside of the JVM's "sandbox".  I would try signing the applet (see,
> > for example,
> > http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html)
> > and see if this fixes your problem.
> +1 on that.
>
> One other thing worth noting is that it is also possible for the web
> content and NDT service to live on different servers without signing the
> applet, by making the jar file available on the NDT server and
> specifying a 'codebase' for the applet, like so:
>
> <applet name="NDT" code=Tcpbw100.class
>    codebase="http://NDTserver_IP_or_name/"; ARCHIVE="Tcpbw100.jar"
>    width=580
>    height=300>
> <PARAM NAME="testingServer" VALUE="NDTserver_IP_or_name">
> </applet>
>
>
> Cheers,
>
> -tt
>
> > ____________________________________________________
> > Seth Peery
> > Senior GIS Architect, Enterprise GIS
> > Virginia Tech Geospatial Information Sciences (0197)
> > Virginia Polytechnic Institute and State University
> >
> > (540) 231-2178
> > http://gis.it.vt.edu/
> >
> >
> >
> > On 3/5/2011 9:45 AM, Jason Zurawski wrote:
> > > Matt;
> > >
> > > On 3/5/11 9:03 AM, 
> > >
> > >  wrote:
> > > > Hi Jason,
> > > > #  jar -vtf /var/www/pms/Tcpbw100.jar
> > > >        0 Wed Feb 16 19:50:54 CST 2011 META-INF/
> > > >       75 Wed Feb 16 19:50:54 CST 2011 META-INF/MANIFEST.MF
> > > >      611 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$1.class
> > > >      462 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$2.class
> > > >      462 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$3.class
> > > >      603 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$4.class
> > > >      509 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$5.class
> > > >    45395 Wed Feb 16 19:50:54 CST 2011 Tcpbw100.class
> > > >      585 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$clsFrame$1.class
> > > >      505 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$clsFrame.class
> > > >      371 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$Message.class
> > > >     1311 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$MyTextPane.class
> > > >     2110 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$OsfwWorker.class
> > > >     1549 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$Protocol.class
> > > >      876 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$StatusPanel$1.class
> > > >     2289 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$StatusPanel.class
> > > >     3620 Wed Feb 16 19:50:54 CST 2011 Tcpbw100$TestWorker.class
> > > > I think the content is the same as yours ,
> > > > I am using IE8 with oracle java (build 1.6.0_24-b07) ,
> > >
> > > Try disabling this and using the Java provided by IE instead.  If this
> > > doesn't work I would suggest using a debugging tool to get more
> > > information.
> > >
> > > Have you modified the original Java source in some way?
> > >
> > > -jason
> > >
> > >
> > > > Add this as follows to my page:
> > > > <applet name="NDT" code=Tcpbw100.class ARCHIVE="Tcpbw100.jar" width=580
> > > >    height=300>
> > > > <PARAM NAME="testingServer" VALUE="myserver_IP">
> > > > </applet>
> > > >
> > > > Any hint ?
> > > >
> > > > Thanks and best regards,
> > > > Matt
> > > >
> > > > -----Original Message-----
> > > > From: Jason Zurawski 
> > > > [mailto:]
> > > > Sent: Saturday, March 05, 2011 9:09 PM
> > > > To: 
> > > >
> > > > Cc: 
> > > >
> > > > Subject: Re: java.lang.SecurityException: Permission denied
> > > >
> > > > Matt;
> > > >
> > > > The Class files are located in the jar itself, you won't need to put
> > > > them in the same directory:
> > > >
> > > > > [zurawski@psndt2
> > > > >  ndt]$ jar -vtf Tcpbw100.jar
> > > > >        0 Wed Aug 11 16:41:34 EDT 2010 META-INF/
> > > > >       75 Wed Aug 11 16:41:34 EDT 2010 META-INF/MANIFEST.MF
> > > > >      611 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$1.class
> > > > >      462 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$2.class
> > > > >      462 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$3.class
> > > > >      603 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$4.class
> > > > >      509 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$5.class
> > > > >      371 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$Message.class
> > > > >     1311 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$MyTextPane.class
> > > > >     2110 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$OsfwWorker.class
> > > > >     1549 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$Protocol.class
> > > > >      876 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$StatusPanel$1.class
> > > > >     2289 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$StatusPanel.class
> > > > >     3620 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$TestWorker.class
> > > > >      585 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$clsFrame$1.class
> > > > >      505 Wed Aug 11 16:41:32 EDT 2010 Tcpbw100$clsFrame.class
> > > > >    44997 Wed Aug 11 16:41:34 EDT 2010 Tcpbw100.class
> > > > If you do the same to your classfile, do you see similar contents?
> > > >
> > > > Which version of Java are you using for IE, is it Sun/Oracle Java or is
> > > > it the version that came with IE?
> > > >
> > > > What is the entire contents of your<applet>   tag in the html file?  Does
> > > > it look like this:
> > > >
> > > > > <applet code=Tcpbw100.class ARCHIVE="Tcpbw100.jar"
> > > > >      width=700 height=320>
> > > > > </applet>
> > > > Or are you using something else?
> > > >
> > > > Thanks;
> > > >
> > > > -jason

Attachment: NDT_signing_vs_remote_codebase.jpg
Description: JPEG image