A fost găsită o intrare fără semnătură în resursă (Programare, Java, Jar, Jnlp, Java Web Start)

Marc Rasmussen a intrebat.
a intrebat.

Am următorul fișier JNLP:

<jnlp spec="1.0+" codebase="http://****:****" href="tcm2012.jnlp">
  <information>
    <title>TCM 2012</title>
    <vendor>Drift og Performance, *** Servicecenter</vendor>
    <homepage href="http://******"/>
    <description/>
  </information>
  <security>
    <all-permissions/>
  </security>
  <resources>
    <j2se version="1.6+"/>
    <jar href="tcm2012.jar"/>
  </resources>
  <application-desc main-class="com.****.kundeservice.TCMApplication"/>
</jnlp>

Acum, atunci când încerc să rulez de pe web, primesc următoarea eroare:

Found unsigned entry in resource

Cu următoarea exepție

com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://*****:****/tcm2012.jar
at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
at com.sun.javaws.security.SigningInfo.check(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Știe cineva cum se poate rezolva această problemă?

Comentarii

  • Aveți nevoie ca borcanele dvs. să fie semnate pentru JNLP. –  > Por Makky.
  • @Makky Jar-ul meu este semnat –  > Por Marc Rasmussen.
  • ok ..sunt încă valabile totuși? –  > Por Makky.
  • Ar trebui să fie programul a funcționat acum câteva săptămâni –  > Por Marc Rasmussen.
  • Examinați cu atenție ieșirea din jarsigner -verify tcm2012.jar utilizând un SDK 1.7.0_25+ (ideal). –  > Por Andrew Thompson.
5 răspunsuri
martins.tuga

Acest lucru a funcționat pentru mine:

Mergeți la Control Panel/Java.

Apoi faceți clic pe butonul „Settings” și activați opțiunea „Keep temporary files on my computer”.

E ciudat, dar a funcționat!

Comentarii

  • De asemenea, merită să examinați MANIFEST.MF al jar-ului (nesemnat) menționat în JarSigningException. Acest fenomen pare să fie legat de intrările de informații despre versiunea pachetului (de exemplu, Name: com.package.foo) prezente în manifestul jar-ului nesemnat. A se vedea, de asemenea: web.archive.org/web/20140301230037/http://blog.atlashost.eu:80/… –  > Por Attila Csipak.
  • De fapt, există o legătură mai proaspătă către conținutul de mai sus: nowaker.net/post/… (Se pare că autorul, Damian Nowak, și-a mutat blogul pe propriul domeniu din 2014). –  > Por Attila Csipak.
Horcrux7

Problema poate apărea și cu versiuni Java mai vechi, dacă semnați cu o versiune mai nouă de Java.

  • Semnați cu 1.8u74 și mai vechi funcționează cu toate versiunile
  • Semnați cu 1.8u101 și mai nou funcționează cu 1.7u80 și mai nou, dar nu și cu versiuni mai vechi pe client.

Se pare că există o modificare incompatibilă în algoritmul de semnare.

CARCARLO

Am avut o problemă similară cu aplicațiile mele.

I’ ve o aplicație java swing implementată cu javaws:

  • când execut aplicația folosind JRE 1.6, primesc excepția
  • când execut aplicația folosind JRE 1.7 și JRE 1.8, aplicația funcționează.

Am verificat toate jar-urile, MANIFEST.MF etc. și totul era în regulă. în cele din urmă am descoperit că am folosit un nou endpoint TSA pentru a-mi semna jar-urile.

Din această resursă http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html citescPentru a genera ștampila de timp, jarsigner comunică cu TSA cu ajutorul protocolului Time-Stamp Protocol (TSP) definit în RFC 3161. În cazul în care reușește, simbolul de ștampilare a timpului returnat de TSA este stocat împreună cu semnătura în fișierul de bloc de semnături.

Cineva poate oferi mai multe informații despre această problemă? În special, nu vreau să fiu obligat să folosesc un anumit TSA.De ce există aceste diferențe între TSA?Mulțumesc.

Vadzim

În cazul meu, applet-ul chiar avea o intrare nesemnată în dosarul META-INF. )O modalitate de a remedia asta ar fi să îl resemnați.Dar în java 8 applet-urile auto-semnate erau retrogradate la aproape același nivel cu cele nesemnate. Iar applet-ul nu necesita privilegii suplimentare.Așa că era suficient doar să designificat și adăugați la lista de site-uri de încredere.

Ben

Am avut aceeași problemă când am compilat pe calculatorul meu linux maschine (cu JDK 6 U45).Dar am primit această eroare doar atunci când am încercat, de asemenea, să să pornesc aplicația semnată cu Java 6 U45.

Atunci când încerc să pornesc aplicația cu o mai nou Java-Version (de exemplu, Java 8), aplicația a funcționat în mod normal, fără niciun mesaj de eroare.

Atunci când am folosit un windows maschine pentru a compila proiectul (tot cu 6 Update 45), în mod ciudat, acesta funcționează și atunci când folosesc Java 6 U45 pentru a porni.

Doar cei 2 cenți ai mei….Cheers!