[java]Applets, rmi en stubs, securityproblemen

[Goldme]

Ik ben op dit moment bezig een Client/Server applicatie te maken die gebruik maakt van RMI.

De server is een java class terwijl het de bedoeling is dat de client een applet is. De client is echter niet zomaar een client, de client logt namelijk in bij de server EN hij voert zichzelf ook in in een rmiregistry, de client is dus als het ware ook een kleine server(omdat de server af en toe wat methoden zal aanroepen op de client).

Kortom, de client en server registreren zichzelf allebei op een (in dit geval zelfde) rmiregistry zodat ze aan allebei de kanten methoden kunnen aanoepen op elkaar.

Nou zal dit geen probleem zijn als zowel de client als server een applicatie zijn, het is dan simeplweg opstarten met de juiste policy-file(zelfgemaakte) meegegeven en het werkt.

Tijdens het testen was de client nog een gewoon een applicatie en toe werkte het perfect(de client en server vonden elkaar wederzijds vlekkeloos op de rmiregistry). Nu heb ik de client omgebouwd tot een applet en krijg ik de volgende foutmelding op de server zelf:

classcastException: Servant_Stub
(rest van stacktrace)

De client(applet) vindt de server en kan alles daarop aanroepen, de server probeert de client weer te pakken te krijgen maar kan denk ik de stub niet krijgen.

Aangezien het als applicatie wel werkte denk ik dat dit puur te maken heeft met de security van de applet. Die heeft denk ik niet de permissie om de stub van de schijf te lezen en door te geven aan de server. Weet iemand hoe ik die permissie wel kan regelen?

Weet iemand of het uberhaupt mogelijk is om met een applet RMI te gebruiken? ik kan de client(als applet zijnde) blijkbaar wel binden aan de rmiregistry(geen foutmelding bij binden) maar anderen kunnen de stub blijkbaar niet krijgen.

En als het niet mogelijk is, weet iemand dan een manier om de server in staat te stellen de clients te bereiken, afgezien van method-returns die via rmi dus gewoon werken.

Mijn programma is een soort chatclient met een centrale server, hoe kan ik aan alle clients(die bij de server bekend zijn) dan een bericht sturen als er een bericht is binnengekomen als ik ze niet kan bereiken? een andere methode zou zijn dat de clients constant een methode aanroepen om te checken of er berichten zijn maar dat is niet echt het toppunt van efficientie te noemen.

[momania]

Check dit eens: http://www.hta-bi.bfh.ch/~daepm/rmidb.html

Hier staat een voorbeeld van een RMI connectie vanuit een Applet

[Goldme]

momania schreef op 22 oktober 2002 @ 00:22:
Check dit eens: http://www.hta-bi.bfh.ch/~daepm/rmidb.html

Hier staat een voorbeeld van een RMI connectie vanuit een Applet

Dat is een simpele connectie naar een DB, dat is geen probleem. Het gaat erom dat een applet blijkbaar zichzelf niet bij een rmiregistry kan aanbieden, ik moet een manier vinden om dat wel zover te krijgen.

Ik heb ook het volgende geprobeerd(nadat de server en rmiregistry opgestart waren):

appletviewer -J-Djava.security.policy=c:\mijnpad\java.policy start.html

Hierdoor zou hij in theorie alle rechten krijgen die een applicatie ook heeft, de policy-file bevat:

code:

grant
{
    permission java.net.SocketPermission "*:1024-65535","connect, accept";
    permission java.io.Filepermission "c:\\temp\\-", "read";
    permission java.awt.AWTPermission "accessEventQueue";
    permission java.lang.RuntimePermission "queuePrintJob";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.jdbc.odbc"; // for ODBC-JDBC bridge
    permission java.net.SocketPermission "*", "connect, listen";
    permission java.io.FilePermission ">", "read, write, delete";
    permission java.util.PropertyPermission "JQDPermission", "read";
    permission java.util.PropertyPermission "user.home", "read";
    permission java.util.PropertyPermission "java.version", "read";
    permission java.util.PropertyPermission "file.encoding", "read"; // for ODBC-JDBC bridge
};

Maar ik blijf de classcastexception krijgen.

[momania]

Lijkt mij dan dat er misschien een code foutje in is geslopen, er vanuit gaande
dat wanneer het volgens jou met de security te maken heeft er een security exception
moet optreden.