Java Applet
Джава аплет (Шаблон:Lang-en) е малък приложен софтуер написана на Джава или друг eзик за програмиране който може да се компилира до специфичен за езика код, наречен байт код, подаващ команда към виртуалната машина на програмния език Java. Програмата се компилирана във вид на .class файл или съвкупност от компилирани Java класове, записани в .jar файл.
Той се изпълняват от Java виртуална машина JVM и затова браузърите, които поддържат аплети имат вградена в себе си или допълнително инсталирана виртуална машина. Програмата като междуплатформен софтуер се вгражда като обект в Уебстраница и се изпълнява от Уеббраузърa или приставки на други клиенти по време на разглеждането на тази страница. Потребителят може да влияе на програмата без да изпраща информация към сървъра.
Аплета използва правоъгълната област, която браузърът и е дал, за графичния си потребителски интерфейс , нов приложен прозорец, самостоятелен интерфейс с команден ред от Sun (на английски език: Sun's AppletViewer) или самостоятелен инструмент за тестване на аплети.
Джава аплетите притежават почти цялата мощ която дава Java платформата, но с известни ограничения, предизвикани главно от съображения за сигурност. За да се осигури безопасността на потребителя, на аплетите е позволено да извършват само операции, които не могат да осъществят достъп до потребителската информацията на машината, на която се изпълняват.
Освен Джава аплет има и програма Джава сървлет която роботи върху уеб сървър.
Преглед
Джава аплетите се използват за предоставяне на интерактивни функции на уеб приложенията, които не могат да бъдат предоставени само от HTML. Те могат да улавят движенията на мишката, като също така получават входни данни от бутони, полета или квадратчета с отметки. В отговор на действията на потребителя, аплетът може да промени своето графично съдържание. Това прави аплетите, много подходящи за демонстрации, визуализации и обучения. Има онлайн колекции от аплети, за изучаване на различни теми, от физика до сърдечна физиология.
Аплетът също така може да представлява само текстови прозорец, осигуряващ например междуплатформена връзка с отдалечена система, посредством интерфейс с команден ред(CLI). Ако е нужно, аплетът може да напусне определената си зона от страницата, и да работи като отделен прозорец. Въпреки това, аплетите имат много малък контрол върху съдържанието на уеб страницата, което е извън неговата зона, затова те не са много полезни за подобряване на външния вид на сайта, за разлика от други типове разширения на браузъра. Аплетите могат също да стартират медийни файлове във формати, които по подразбиране не се поддържат от самият браузър.
В страниците, написани на HTML, могат да се вграждат различни параметри, които се подават към аплета. Поради тази причина един и същи аплет може да изглежда различно в зависимост от подадените му параметри. Аплетите са били на разположение още преди CSS и DHTML да бъдат стандартизирани. Съшо така са били използвани и за тривиални ефекти като бутони за временна визуализация (т.н. rollover buttons). Силно критикувани, днес използването им все повече намалява.
Сигурност
Моделът за сигурност на Джава аплет е създаден с цел защита потребителя от злонамерени аплети [2]. От създаването му до момента са откривали и поправяли много проблеми по сигурността.
Аплетите биват SANDBOX(пясъчник) или PRIVILEGED(поверителни). Поверителните аплети могат да работят извън пясъчника и имат достъп до клиента.
Относно тяхната сигурност могат да се разделят на неподписани, подписани и самоподписани[3].
Неподписани
Аплети които не са подписани се изпълняват на безопасен пясъчник, който им позволява ограничени операции и работят след приемане от страна на потребителя. Те имат достъп само до сайт откъдето са качени, ограничени са откъм достъп до локалната файлова система. Въпреки, че се рамкират самостоятелно, те носят информация, че са ненадеждни аплети. Сигурността осигурява цялостна проверка на инициализирания стек, за да се увери, че не идва от неподходящо място.
Непотвърдените аплети могат да бъдат много опасни, ако работят директно в сървъра, защото те могат да изпращат кодове към сървъра, но докато работят в него те могат да заобиколят защитата. Някой аплети могат да пробват aтака за отказ на услуга към сървъра където работят, но в повечето случаи хората поддържащи страницата поддържат и аплета и това става нелогично.
Непотвърдените аплети могат да опитат да свалят злонамерен софтуер хостван на началния сървър. Той може да съхранява информация само във временни папки (тъй като данните са временни) и няма способността да завърши атаката след като я изпълни.
Подписани
Тези които са потвърдени със сертификат от разпознаваем източник могат, или да работят в пясъчника, или извън него. Във всеки един от случаите потребителят трябва да приеме сертификата за сигурност на аплетa, иначе аплетa ще блокира работата си.
Потвърдените аплети притежават математична схема (подпис) доказваща автентичността на цифровото съобщение. Този подпис предизвиква различни способи за взаимодействие с поддръжката и сигурността на сървъра. След като бъде проверен, потребителят също трябва да приеме аплета, тогава той става с повече права и става равностоен на самостоятелна програма.
Този подход позволява на подписаните аплети да изпълняват много задачи, които не биха били възможни за клиент ползващ скриптов език. Този подход, обаче изисква повече отговорности от потребителя относно това, че той сам трябва да реши дали да се довери.
Самоподписани
Самоподписващите аплети, които са аплети доказали идентичността си от самия разработчик могат да бъдат потенциална заплаха за сигурността. Джава приставките представят предупредителен сигнал при изискването на одобрение за самоподписващ аплет, тъй като функционалността и сигурността му са гарантирана от разработчика му и не се потвърждава с проверка.
Такива самоподписани сертификати се използват най-често по време на разработването преди пускането, когато допълнително потвърждаване на сигурността е маловажно, но повече разработчици ще търсят допълнително потвърждаване на сигурността, за да се гарантира, че потребителя се доверява на безопасността на аплета.
От 2014 насам самоподписващите и не подписаните аплети не се признават от разпространените Джава приставки или DjavaWS, следователно разработчиците нямат друг избор, освен да изискат одобрен сертификат от търговските източници.