Internet програмиране с Java

---

Започнахме темата за създаването на Java аплети, а сега ще довършим изложението по тази тема и ще продължим с Web приложения.
JAVA аплети и сигурност
Сигурността на аплетите е важна тяхна черта. Никой потребител не би се съгласил да разглежда сайтове с аплети, ако те могат да пишат свободно по диска му, ако могат да откраднат негова лична информация, да изпращат email-и от негово име или да извършват някаква друга злонамерена дейност. Ето защо по идея аплетите работят с ограничени права. Сигурността в Java е част от самата платформа и се конфигурира от един специален файл с име java.policy. В зависимост от правата, които Web браузърът иска да даде на аплета, се подготвя съответен файл, който ги описва, и виртуалната машина се конфигурира по него. В някои браузъри правата могат да се настройват и се допуска възможност потребителят да дава пълно доверие на определени сайтове, с което аплетите се освобождават от ограниченията си. Ако потребителят не е посочил нещо друго, се използват стандартните настройки за правата на аплетите, които налагат следните ограничения: аплетите не могат да четат и пишат по диска на машината, на която се изпълняват. Не могат да осъществяват достъп до чужда памет дори в операционни системи, в които няма защита на паметта. Не могат да отварят сокет до произволен сървър в Internet. Могат да отварят сокет само до хоста, от който са заредени. Не могат да извикват директно native код. Не могат да предизвикат претоварване или забиване на машината, на която се изпълняват. Последното е възможно да се случи в някои специфични ситуации, но това се дължи на грешки и пропуски в сигурността на съответните браузъри и виртуалните машини, които те използват. Трябва да обърнем специално внимание на сокетите. Свидетели сме на много аплети, които извършват активна мрежова дейност, като например аплети за Chat, аплети за четене на email, аплети за изпращане на email, различни игри и т.н. Всички те използват сокет базирана комуникация и изглежда, че отварят сокет към Internet. Например при изпращането на поща аплетът комуникира със зададен от потребителя SMTP сървър. Това обаче не става директно както при обикновените програми на Java. Аплетите имат право да се свързват чрез сокет само до сървъра, от който са заредени, т.е. към хоста, върнат от метода getCodeBase().getHost(). Ето защо аплети, които не са заредени от някой Web сървър, а локално от файловата система, чрез отваряне на локален HTML файл, нямат право да отварят никакви сокети. Това защитава потребителите от атака чрез HTML документи, съдържащи аплети със злонамерено действие. Всички аплети, които изглежда, че отварят сокети към Internet, всъщност отварят сокети към сървъра, от който са заредени, и от там получават пренасочване към заявения хост, т.е. използват Web сървъра като прокси (междинен пренасочващ сървър). Когато се наложи да пишем аплет, който комуникира чрез сокети, е необходимо на Web съвръра, където се хоства този аплет, да пуснем някакъв допълнителен сървър, който осигурява комуникацията на аплета с услугата, до която той трябва да осъществява достъп. Разбира се, това трябва да става след успешна автентикация на потребителя в системата. За целта най-удобно е сървърът, който се грижи за комуникацията на аплета, да се интегрира в Web сървъра, за да може да използва информацията от сесията на потребителя, който е изпълнил аплета. Как точно може да стане това, ще изясним по-нататък в нашия курс в частта за Web приложения.