The history of Java security has been parallel to the main releases of Java: JDK 1.0, JDK 1.1 and Java 2 SDK, Standard Edition, V1.2 5 : 1. The JDK 1.0 security model was very strict. Local code was granted access to all the system resources, while a remote applet was always considered untrusted, and could be used almost only for cosmetic functions, like the decoration of a Web page. 2. JDK 1.1 still considered local code as completely trusted, with full access to all of the system resources. However, JDK 1.1 also offered Java developers the possibility to apply a digital signature to the code they wrote. By looking at the digital signature, the user on a client machine could decide whether a particular remote code was to be considered trusted or not. If untrusted, that remote code would run in a restricted environment. If trusted, that code would be considered as a local code, with full access to all of the system resources. The JDK 1.1 security model was more attractive, but still presented several limitations. For example, remote code with a trusted signature was granted full access to all the system resources, as well as local code. So, even when you wanted to grant a signed remote code, say, only read access to a particular file in a particular directory of your system, you had to grant it full read access to all your files and all your directories. Moreover, that code was automatically granted the permission to write on your system, install other code, open a socket, and a lot of other things. This happened without your intervention or your awareness. 3. The Java 2 security model implements fine-grained access control. You can now classify the Java code that is to run on your system basing your judgement on the URL location where that code resides and/or the owners of the code itself. The owners of the code are identified through their digital signatures. Multiple signatures for a single piece of code are allowed in Java 2. Possibilities are now endless. You can say that a piece of code coming from a particular location and/or signed by particular signers can only read that file and write in that directory. Other code coming from another location and/or signed by other entities can open only a specific socket, while still other code can be classified to have full access. Moreover, in Java 2, even local code can be subjected to security restrictions. In this section we will demonstrate to you that Java is not a threat to security, provided that your Java system is configured in the correct way. On the contrary, the security features that are part of the Java programming language itself can really improve the overall security of your system. 5 In this book, Java 2 SDK, Standard Edition, V1.2 (J2SDK) is sometimes referred to as Java 2 SDK You are here:CodeIdol > Java > Java 2 Network Security > page: 3031323334353637383940
AJAX popular information C# language guides Windows books and cookbooks
.......
С 2009 года мы стали переводить структура сайта на различные языки. Сайт теперь будет содержать книги не только на английском языке, но также и на других европейских языках, в том числе и на Русском языке.