[Java] Relatieve paden

[patrick.k]

Dit klinkt misschien makkelijk en als iets dat je zo op google vindt en dat dacht ik eerst ook, maar het valt tegen. Het gaat hier om een applet gemaakt met java (dus geen .exe maar een .class). Ik wil vanuit mijn applet graag een volgende applet starten door hiervan de html pagina aan te roepen waar deze applet in is opgenomen. Nu is mij dit al gelukt met een absoluut pad bijvoorbeeld d:/java/menu.html. Nu stop ik de usb stick met de classes en html bestanden in een andere pc en nu heeft deze een andere drive letter gekregen waardoor de koppeling niet meer werkt. Nu zoek ik dus de code waarmee ik een bestand in dezelfde map kan openen zonder daarvoor de drive letter genoemd te moeten hebben. Ik heb het onder andere al geprobeerd met System.getProperty("user.dir") en file.getAbsolutePath maar dit werkt volgens mij allemaal niet omdat je in een applet met iets meer beveiliging te maken hebt dan in een applicatie.

Alvast bedankt voor de hulp
Gr patrick

[Verwijderd]

Ik zou dit eens diagonaal doorlezen

[patrick.k]

Wat ik er zo snel uithaal staat er dus dat het in principe niet kan, maar ik zal morgen eens proberen iets met de url te doen. Aangezien alle classes en html files lokaal zijn opgeslagen moet het mogelijk zijn om de drive letter uit de url te halen aangezien deze erin vernoemd moet staan. Met deze letter is het hoo ik dan weer mogelijk uiteindelijk tot een absoluut pad te komen. In ieder geval bedankt voor de snelle reactie want deze informatie was ik nog niet tegengekomen en ik post het nog wel even als het is gelukt om het pad te bepalen via de url.

Edit: Het is gelukt. Voor de genen die geïnteresseerd zijn, ik heb het met de volgende code gedaan:
String stringpath;
URL path = this.getCodeBase();
stringpath = path.toString();

en stringpath is dan alleen het pad met de slash erachter, dus zonder bestandsnaam. Dus bijvoorbeeld: file://E:/java/

[ Voor 21% gewijzigd door patrick.k op 01-02-2011 15:26 . Reden: oplossing gevonden ]

[Cobalt]

Als je problemen hebt met rechten, moet je een Policy bestand maken en deze bekent maken aan de SecurityManager. (java -Djava.security.manager -Djava.security.policy=myPolicy.policy) Met de juiste policy kan je alles doen met een applicatie, applet of javafx. Zonder policy file kan je ook al vrij veel.

voorbeeld van een policy file

Java:

grant {
   permission java.io.FilePermission "${user.home}", "read";
}

http://download.oracle.co...security/permissions.html

Als je paden langer dan 255 karakters wilt moet je \\?\ voor het pad zetten.

[ Voor 75% gewijzigd door Cobalt op 05-02-2011 21:02 ]

[patrick.k]

Zoals ik al zei is het al gelukt, maar toch bedankt. Ik heb alleen een vraagje over het maken van dat policy-bestand. Heb je hiervoor toestemming van de gebruiker voor nodig of iets dergelijks? Anders lijkt me de ingebouwde beveiliging vrij nutteloos als je deze zelf kunt opheffen zonder permissie van de eindgebruiker.

[Cobalt]

Je kan met een policy file de rechten beperken tot wat echt noodzakelijk is voor jouw applicatie, applet of JavaFX applet. Hiervoor heb je geen toestemming van de gebruiker nodig.

Een Java applicatie krijgt standaard redelijk wat rechten. Deze kan je verruimen tot wat je nodig hebt. Zolang je binnen de rechten van de user die de applicatie uitvoerd blijft heb je geen toestemming nodig.

Java applets en JavaFX applets (eigenlijk alle applicaties die via Java WebStart gerunt worden) hebben beperkte rechten en runnen in een soort van sandbox modes. Zodra je de jar signeerd kan je deze applets meer rechten geven d.m.v. een policy file.

Mocht de applicatie meer rechten nodig hebben dan de user die de applicatie uitvoerd en de standaard Java policy. Dan kan je niet anders dan zelf een policy maken met de benodigde rechten. En eventueel het process zelf naar een hoger user niveau tillen dat wel de juiste rechten heeft. (Als je hiernaar opzoek bent kan je zoeken naar "elevated privilege" of "elevating process" of ShellExecute(). Zo wordt het vaak genoemd voor Windows). Onder Windows XP is het nauwelijks nodig om het proces onder een andere user te runnen met meer rechten. Onder Windows 7 zals je zien dat je veel vaker het process onder een user moet runnen met meer rechten om bepaalde taken te kunnen uitvoeren. Bij applicaties die via Java WebStart gestart worden, vraag de JRE op basis van de policy file zelf om meer rechten.


Het is natuurlijk afhankelijk van wat voor applicatie je schrijft. Maar in de meest ideale situatie, schrijf je een policy file die alle rechten van jouw applicatie beperkt tot dat wat echt noodzakelijk is voor de applicatie. De policy bepaald wat mag in de sandbox waarin jouw applicatie draait. Om te voorkomen dat bij een exploit in jouw applicatie onnodig veel toegang tot het systeem verkregen kan worden.

Interessante linkjes:
http://download.oracle.co...echnotes/guides/security/

http://jaasbook.wordpress.com/ Een poging van Michael Coté om een boek te schrijven over Java Security genaamd JAAS in Action. Dit is nooit uitgegeven in boek vorm. Hij heeft het op zijn site gepubliceerd in 2005.

[ Voor 113% gewijzigd door Cobalt op 06-02-2011 14:52 ]

[patrick.k]

Het is zeker handig dat het kan, maar ik blijf het vreemd vinden dat je standaard bijna geen rechten hebt in applets, maar dat je zelf zonder toestemming van de gebruiker aan jezelf meer rechten kunt verlenen. Dan vraag ik me af wat het nut ervan is om een appplet standaard zo weinig rechten te geven. En als er standaard te veel rechten in zouden zitten voor de op dat moment ingelogde gebruiker zal windows dit waarschijnlijk zelf blokkeren.

[Remus]

Een applet kan zichzelf niet meer rechten geven dan de gebruiker toelaat. Om überhaupt iets meer te mogen dan dingen op te vragen van zijn eigen host (same origin policy) moet de applet signed zijn. Als een applet signed is, dan krijgt de applet alle rechten die een normale Java applicatie ook heeft op basis van de standaard policy.

Wat Cobalt beschrijft is juist het omgekeerde: een applicatie (of signed applet) kan zijn eigen rechten beperken met een specifieke policy tov de normale policy, zodat het moeilijker is om de betreffende applicatie te misbruiken. Deze specifieke policy kan echter niet buiten de standaard policy om (als de standaard policy beperkender zou zijn dan AllPermissions.

[Cobalt]

Remus heeft gelijk.

Op http://download.oracle.co...yment-guide/security.html staat dat als de applicatie om AllPermission vraagt d.m.v. een policy en de applicatie is signed en het certificate zit in een van deze deployment.user.security.trusted.certs of deployment.system.security.trusted.certs keystore dan wordt de applicatie vertrouwd. De user zal wel een popup krijgen, met de vraag of de user het vertrouwd, mocht het certificate nog niet in een van deze keystores zitten.