2013-04-18 12 views
7

Tak więc zainstalowaliśmy wersję Java 7u21, która ma za zadanie wzmocnić zabezpieczenia apletów. Niestety zaostrzyło to tak bardzo, że nasz aplet już nie działa. Niedobrze.Nie można uruchomić apletu używając Java 7u21

Ciekawostką jest to, że przestało działać tylko podczas pracy z JWS. Jeśli uruchomimy go jako standardowy aplet ze standardowej strony internetowej, wszystko działa dobrze.

W trybie JWS otrzymujemy problemy bezpieczeństwa przynajmniej na odbiciu i java.lang.Thread.setDefaultUncaughtExceptionHandler.

Certyfikaty wyglądają dobrze.

Informacje o wydaniu z Oracle nie dostarczają wiele informacji na temat jakichkolwiek elementów związanych z JWS.

Moje pytanie do społeczności brzmi: czy ktoś ma pomysł lub (jeszcze lepiej) rozwiązanie tego?

Dodatkowe informacje związane z danym sugestie/komentarze:

Ten aplet jest prowadzony przez setki klientów zewnętrznych na całym świecie tak zmieniających zasady zabezpieczeń nie jest niestety rozwiązaniem. Problem jest powtarzalny dla klientów. Mogę jednak potwierdzić, że zmiana pliku zasad rozwiązuje problem.

Po uruchomieniu apletu z Tomcat uruchomionego z Eclipse (co oczywiście nie oznacza podpisanego apletu), wyświetla powiadomienie ostrzegawcze w przeglądarce zgodnie z oczekiwaniami. Będąc łatwowierną osobą, którą jestem, pozwalam uruchomić aplet, ponieważ został uruchomiony z mojego własnego środowiska programistycznego. To nadal powoduje błąd bezpieczeństwa.

Rozważałem, czy jest to błąd w Javie, ale chcę sprawdzić, czy ktoś jeszcze widzi ten sam problem. Myślę, że wszyscy wiemy, że czas naprawy Oracle nie zawsze jest najlepszy ...

Dzięki za wszelkie dane wejściowe.


dziękuję Tony, twoja sugestia zrozumcie mnie możliwość tworzenia apletów w 7u21, propperly; Za krok naprzód uważałem fakt, że podpisuję i budzę wiele apletów jeszcze w przeglądarkach, nad 7u21. Nie zrobię tego dzisiaj wcześniej. Ale dostaję się w pułapkę od kilku godzin, ponieważ nie udało mi się obudzić mojego pierwszego apletu innej firmy ze starszej aplikacji, którą mam (tj. Dobrze działającej w JVM 1.6 lub starszej wersji).

Aplety zaangażowane, podpisałem je, ale zawsze otrzymuję błąd: SecurityException - "Zła nazwa klasy apletu". Mam aplety i kod html je wywołujący, problem polega na tym, że mój pierwszy aplet w łańcuchu (ani żaden inny w łańcuchu invoke) może nie zachowywać się tak jak inne podpisane aplety robią propperly (te aplety pochodzą ze strony internetowej java na szkolenia), ten prosty aplet strony trzeciej nie uruchamia się i nie wyrzuca wyżej wspomnianego wyjątku. Mój aplet thrid części nie wiem, co robi wewnętrznie. Przepraszam, że mogę prosić o konkretny przypadek, który nie jest łatwy do rozwiązania bez kodu źródłowego, jednak proszę mi zaufać, aby powiedzieć mi jakikolwiek pomysł bez względu na to, który jest.

pozdrawiam

+1

Sprawdź błąd DB dla trafień. Jeśli nic nie znalazłeś, podnieś nowy. –

+1

Może to daje bardziej szczegółowe informacje: [Java 7 Update 21 Security Improvements in Detail] (http://blog.eisele.net/2013/04/java-7-update-21-security-improvements.html) – Jesper

Odpowiedz

4

Mój kolega go złamać. Oddanie wódki polskiemu człowiekowi może czasami przynieść potrzebną inspirację. :-)

W każdym razie wygląda na to, że znacznik bezpieczeństwa jest teraz wymagany w informacjach jnlp wysyłanych do apletu (dane zwracane z typem zawartości ustawionym na plik application/x-java-jnlp).

Dodając

<security> 
    <all-permissions/> 
</security> 

to działa.

Mam nadzieję, że to pomoże.

1

Poniższy cytat z Security stronie dokumentacji Java SE jest istotne:

"The standard java policy files can be used to enhance the permissions granted to untrusted apps. In addition to $JRE_HOME/lib/security/java.policy and $USER_HOME/.java.policy (used by all java programs), applications and applets loaded by Java Web Start and Java Plug-in load two additional policy files, whose location can be configured by the deployment configuration properties: deployment.user.security.policy and deployment.system.security.policy."

sprawdzić pliki polityczne w tych lokalizacjach.

4

Oto strona, która to wyjaśnia.

Oracle Code on Mixed code

Co trzeba zrobić, to wziąć wszystkich słoikach są uzyskać nową linię TrustedLibrary w pliku manifestu. Dla mnie oznaczało to przekompilowanie starszego kodu. Prawdopodobnie można po prostu oddzielić bieżące słoiki, a następnie włączyć w tym linię TrustedLibrary.

Musisz również podpisać cały swój kod. Nie tylko aplet. Oznacza to, że jeśli masz 3 słoiki, cały kod we wszystkich 3 słoikach musi być również podpisany.

1

Dodatkowa wskazówka dla wszystkich programistów używających niepodpisanych apletów. W zeszłym tygodniu na konferencji JAX2013 Wolfgang Weigand z Oracle wspomniał, że po wydaniu wersji Java 7 w październiku 2013 będzie tylko najwyższy poziom suwaka bezpieczeństwa apletu, tzn. Tylko aplety podpisane z zaufanym (nieautoryzowanym) certyfikatem będą w stanie biegać. Do tej pory ta informacja nie została jeszcze opublikowana na oficjalnej stronie internetowej Oracle.

Odpowiedź powyżej cytuje ze strony java6 Bezpieczeństwa mogą być nieco nieaktualne z powodu ostatnich zmian w zabezpieczeniach Java Platform

+0

podpisywanie słoików za pomocą klucza z własnego magazynu kluczy już nie będzie działać? – Perneel

+0

@Perneel Jeśli Oracle zdaje sobie sprawę z tych ulepszeń bezpieczeństwa, jak wyjaśniono na konferencji, odpowiedź brzmi "tak". – mschenk74