2012-09-29 29 views
2

有沒有人遇到過這個?這使得我很難獲得一個appplet工作。我認爲它不工作的原因是由於我的程序中的套接字與服務器進行通信。但是,我無法弄清楚如何阻止它,而谷歌沒有幫助。我無法得到一個異常,因爲谷歌瀏覽器的java控制檯沒有輸出錯誤,只是在點擊錯誤的小程序之後給我一個彈出窗口,說它出錯了。如果需要代碼,我會添加。提前致謝。Java:安全例外 - 非法網址重定向

security: --- parseCommandLine converted : -Djava.net.preferIPv4Stack=true 
into: 
[-Djava.net.preferIPv4Stack=true] 
basic: Added progress listener: [email protected] 
basic: Plugin2ClassLoader.addURL parent called for http://voidchar.com/Other/DatRLTest.jar 
basic: Plugin2ClassLoader.addURL parent called for http://voidchar.com/Other/SharedClasses.jar 
security: Blacklist revocation check is enabled 
security: Trusted libraries list check is enabled 
network: Cache entry found [url: http://voidchar.com/Other/DatRLTest.jar, version: null] prevalidated=false/0 
cache: Resource http://voidchar.com/Other/DatRLTest.jar has expired. 
network: Connecting http://voidchar.com/Other/DatRLTest.jar.pack.gz with proxy=DIRECT 
network: Connecting http://voidchar.com:80/ with proxy=DIRECT 
basic: exception: illegal URL redirect. 
java.lang.SecurityException: illegal URL redirect 
at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source) 
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source) 
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source) 
at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source) 
at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source) 
at com.sun.deploy.cache.DeployCacheHandler.get(Unknown Source) 
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) 
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) 
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) 
at sun.plugin.PluginURLJarFileCallBack.downloadJAR(Unknown Source) 
at sun.plugin.PluginURLJarFileCallBack.access$000(Unknown Source) 
at sun.plugin.PluginURLJarFileCallBack$1.run(Unknown Source) 
at java.security.AccessController.doPrivileged(Native Method) 
at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source) 
at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source) 
at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) 
at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) 
at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) 
at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source) 
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source) 
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source) 
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source) 
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source) 
at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source) 
at java.security.AccessController.doPrivileged(Native Method) 
at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source) 
at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source) 
at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source) 
at java.security.AccessController.doPrivileged(Native Method) 
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source) 
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source) 
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source) 
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source) 
at java.security.AccessController.doPrivileged(Native Method) 
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source) 
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source) 
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) 
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) 
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) 
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) 
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) 
at java.lang.ClassLoader.loadClass(Unknown Source) 
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source) 
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source) 
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) 
at java.lang.Thread.run(Unknown Source) 
Ignored exception: java.lang.SecurityException: illegal URL redirect 
basic: Dialog type is not candidate for embedding 
basic: Removed progress listener: [email protected] 
basic: Loading Java Applet Failed... 
security: Accessing keys and certificate in Mozilla user profile: null 
security: Reset deny session certificate store 

編輯:這裏是我用來加載小程序的html代碼。


    {applet width=800 height=800 archive='DatRLTest.jar,SharedClasses.jar' code='vc.voidwhisperer.datrl.main'} 
    {PARAM name="java_arguments" value="-Djava.net.preferIPv4Stack=true"} 
    {/applet} 

的小於&大於跡象被替換由於這樣的事實,它不喜歡我試圖把東西他們。

編輯#2:我自簽名的jar,這仍然在發生。我還沒有想出如何解決這個問題..

最後編輯:經過多小時的工作,我終於遇到了一個解決方案,這要感謝irc頻道的朋友。下面是它是如何固定的一般要點:

  • 如果你看一下輸出的具體線路:網絡:連接http://voidchar.com/Other/DatRLTest.jar.pack.gz與代理= DIRECT。
  • 查找該文件時,它不存在。
  • 對文件類型做了一些研究,它是一個pack200 jar,它可以使用jar來製作,然後使用它進行以下操作:打開cmd並鍵入'pack200 example.jar.pack.gz [JarLocation]'。
  • 現在,將example.jar替換爲jar文件的名稱,但將.pack.gz保留在那裏。
  • 現在,將該文件上傳到與小應用程序相同的目錄,並嘗試再次加載小應用程序。

注:確保小程序已簽名!希望這有助於他人解決我遇到的問題。

+0

我遇到http://www.ol-in-berlin.de/gadget/reitti.jar同樣的問題,當客戶端更新到Java 7中。在客戶端禁用Java下一代插件是第一個(壞)解決方案。幸運的是,我發現你的這篇文章並提供.pack.gz文件。感謝分享它。 (也許你應該把它作爲一個自我回答)現在,如果有人能夠提供詳細的解釋,爲什麼會發生這種情況,這將是很好的。 – bodo

回答

4

你的小應用程序違反了「同源」的限制,這是旨在防止討厭的小應用程序用戶默認Applet的安全限制。

請參閱this blog post瞭解限制的解釋以及爲何強制執行。


你能做些什麼呢?最好的做法是重新構建你的applet和/或服務,以便重定向完全移除,或者重定向到一個不違反限制的URL。如果這不是一個選項,您將需要使您的小程序成爲「可信任的小程序」;例如請參閱this tutorial以瞭解問題。


UPDATE

我錯了有關使小程序信任的小程序。它不會幫助。我查看了OpenJDK源代碼(herehere),並且似乎執行「同源」安全檢查時不考慮安全策略。 (查找與該消息拋出異常的代碼......)

所以你唯一的選擇是從同一個主機和端口的網頁鏈接到它服務於小程序。換句話說,不要違反「同源」規則。

+0

我自行簽署了小程序。它仍然不會加載。並且所有類都與試圖加載它的頁面位於同一臺服務器上。我將我使用的html代碼添加到orignal文章中。 – VoidWhisperer

+0

唯一可能導致這種情況的原因是我的小應用程序通過插件連接到遠程ip ......我不能做太多的工作來解決這個問題嗎?我很確定它試圖訪問的兩個.jar文件都在同一個網絡服務器上,除非它試圖從目錄以外的地方訪問它 – VoidWhisperer

+0

是否有任何簡單的方法來診斷錯誤到達哪一行來自,因爲看着堆棧跟蹤,它沒有說明異常來自哪裏,因此弄清楚錯誤來自哪裏確實有點麻煩。 – VoidWhisperer

0

我使用Java 1.7.0_09時,看到一個客戶的服務器上的同樣的問題。如果我使用Java的早期版本,那麼沒有問題。如果我在不同的服務器上運行相同的Applet,那麼沒有問題。

我終於找到了一個修復程序。我清除了我的Java緩存。 (這是不是瀏覽器緩存不同。)

在Windows 7中,您可以:

  1. 啓動Java控制面板,
  2. 點擊 「常規」 選項卡,
  3. 「Internet臨時文件」 下點擊「設置」,
  4. 單擊「刪除文件」,
  5. 只選擇「緩存的應用程序和小程序」並點擊確定。

花了將近一分鐘,清除我的Java高速緩存。

然後一切正常。

2

至於我的研究就這個問題時請求的java小程序,並得到一個HTTP響應300造成的。首先,java將嘗試加載applet的壓縮版本,即「yourjarfile.jar.pack.gz」。如果服務器提供HTTP 404,則按預期工作。但是,如果服務器提供HTTP 300響應,則java假定存在重定向目標,如果沒有設置則失敗。

從我的經驗,你可以做以下的事情來解決服務器端的問題:

  1. 如果你的小程序由一個jar文件,並沒有數據被加載之後,您可以壓縮與您的小程序pack200工具,並用新文件替換原始jar。確保.pack.gz文件擴展名附加到原始文件。
  2. 如果你有一個Apache並完全控制你的服務器,你可以卸載mod_speling。請確保您運行的環境的其他部分正常。
  3. 如果您可以使用.htaccess文件,則可以禁用對applet從中加載的文件夾進行拼寫檢查。爲此,創建一個內容爲「CheckSpelling off」的.htaccess文件。如果已經存在.htaccess文件,只需將此行添加到它。

我希望這可以幫助一些人出來。