Further to my earlier comment. I would also question whether making the applet trusted would make any difference. It seems that given its current behaviour this would just allow it to freely read and write to the client rather than reading and writing from the server.
Regards, Susan Hoddinott http://www.hexworx.com ----- Original Message ----- From: "Susan Hoddinott" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Friday, July 04, 2003 1:15 PM Subject: Re: Compensating for applet security restrictions > Hello, > > I have thought about signing but unfortunately I have many of these files > which can be automatically created by users and therefore I cannot expect > them to have CA. Can you give an example as to how deployment of the > program as a Java Application would differ as effectively this is what I am > doing. The first applet just takes parameters and either runs the program > as an applet or an application but the security which is inherited appears > to be that for an applet in either case? > > Regards, > Susan Hoddinott > http://www.hexworx.com > > ----- Original Message ----- > From: "Atreya Basu" <[EMAIL PROTECTED]> > To: "'Tomcat Users List'" <[EMAIL PROTECTED]> > Sent: Thursday, July 03, 2003 7:15 PM > Subject: RE: Compensating for applet security restrictions > > > > > > If you need to read and write to a file, just keep the files on the > > server. You can pull a resource off the originating server to read > > something. Writing to a file is probably going to be a problem however. > > You could always sign the applet and then you would be able to read and > > write all you wanted. > > > > The other option is to simply deploy it as a Java Application instead of > > an Applet. That seems a lot more appropriate for what you are trying to > > do. > > > > Atreya > > _____________________________________ > > Atreya Basu > > Developer, > > Greenfield Research Inc. > > e-mail: atreya (at) greenfieldresearch (dot) ca > > -----Original Message----- > > From: Susan Hoddinott [mailto:[EMAIL PROTECTED] > > Sent: July 3, 2003 2:35 AM > > To: Tomcat Users List > > Subject: Compensating for applet security restrictions > > > > Hello, > > > > I currently have a JSP with an APPLET tag (including EMBED and OBJECT > > references) which runs a JAR file located on my server. The program > > runs fine but because the APPLET is run by the Java plug-in whenever it > > needs to read or write data it attempts to read or write the data from > > or on the client machine, which is clearly inappropriate. I do not want > > to use servlets as I would like to distribute the APPLET and program > > when I have finished and do not want to assume servlet support. > > > > The jar file first program is a JApplet and this creates a JFrame using > > a normal class file. All other programs are normal classes (i.e. > > non-applets). I want to use the graphics environments on the client > > machine as my own web server does not have an installed graphics > > environment. > > > > I have been investigating URLConnections, Sockets, Proxy Servers and RMI > > and have been left feeling confused as I am unclear which is the best > > approach and all seem very complicated to overcome what seems to be a > > simple problem. Furthermore, all examples seem to use a single text > > file whereas I want to default all IO to the server rather than the > > client. Does anyone know a solution for this problem? > > > > Regards, > > Susan Hoddinott > > http://www.hexworx.com > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
