NPAPI

Netscape Plugin Application Programming Interface ( NPAPI ) este o arhitectură multi-platformă pentru pluginuri utilizate de multe browsere web . Dezvoltat inițial pentru familia de browsere Netscape , începând cu Netscape Navigator 2.0, a fost ulterior implementat în alte browsere, inclusiv Mozilla Application Suite , Mozilla Firefox , Chrome , Safari , Opera , Konqueror și unele versiuni ale Microsoft Internet Explorer . Arhitectura devine învechită și cele mai comune browsere au încetat să o accepte.

Istorie

Originea funcționalității pluginurilor Netscape nu se găsește în Netscape , ci în Adobe . John Warnock , CEO Adobe, și Allan Padget , unul dintre principalii autori ai Acrobat Reader , au sperat că formatul de fișier emblematic Adobe, PDF , își poate extinde sfera de utilizare mult dincolo de domeniul desktop.

Așadar, la scurt timp după ce Netscape a lansat prima versiune de Navigator, Padgett, împreună cu inginerul Eshwar Priyadrshan, au încercat să găsească o modalitate de a face din PDF o parte integrantă a experienței web. Rezultatul a fost o aplicație demonstrativă prezentată Warnock și Jim Clark , CEO Netscape. Înainte de această demonstrație, singurele formate native de pe web erau paginile HTML și imaginile afișate în ele. Legăturile către orice alt tip de fișier l-au determinat pe utilizator să descarce fișierul: după aceea, utilizatorul ar putea deschide fișierul cu cea mai potrivită aplicație. Cu toate acestea, în această demonstrație, când un utilizator a dat clic pe un link către un fișier PDF, fișierul a fost deschis imediat în fereastra browserului, amestecând indiferent utilizarea paginilor HTML și a documentelor PDF. Clark a întrebat cu entuziasm cine de la Netscape a oferit asistență tehnică pentru a face posibilă integrarea, dar a constatat că aceasta a fost realizată fără implicarea Netscape, dar cu o inginerie inversă a browserului.

Companiile au fost de acord să se întâlnească săptămâna următoare pentru a găsi modalități de a face ceea ce era cunoscut sub numele de „hack-ul lui Allan” atractiv pentru piață. Deși Netscape era gata să încorporeze PDF-uri direct în browser și Adobe ar fi câștigat cu siguranță din acesta, Padgett a propus o abordare diferită: o arhitectură bazată pe pluginuri. Inginerii Adobe Gordon Dow și Nabeel Al-Shamma au adăugat recent o arhitectură plugin la Acrobat Reader, pentru a reduce eforturile dezvoltatorilor terți. Padgett a participat la dezvoltare și a crezut că, dacă i se va oferi oportunitatea, alte companii (și poate alte echipe din cadrul Adobe) ar alege să extindă capacitățile Web. Clark și echipa s-au convins în cele din urmă și au început să proiecteze API care trebuia să sprijine noul model de dezvoltare. Deși PDF a fost pionierul, s-ar putea argumenta că pluginurile ulterioare, precum Macromedia Flash și Java , au avut un impact mult mai mare asupra peisajului web.

Caracteristici

Popularitatea sa poate fi atribuită parțial simplității sale. Un plugin pretinde că gestionează unele tipuri MIME (de exemplu „audio / mp3”) prin intermediul informațiilor despre fișierele prezentate. Când browserul întâlnește acest tip de conținut, acesta încarcă pluginul asociat, delimitează spațiul din zona de afișare pentru a fi atribuit pluginului și, în cele din urmă, îi transferă date. Pluginului i se atribuie apoi sarcina de a gestiona datele în modul cel mai potrivit, fie că este vizual, audio sau orice altceva. În acest fel, un plugin rulează în propria parte a paginii, spre deosebire de browserele anterioare, care trebuiau să lanseze o aplicație externă pentru a gestiona tipuri de conținut pe care nu le cunoșteau.

API-ul necesită ca fiecare plugin să implementeze și să publice un număr destul de mic de funcții. Aceasta reprezintă aproximativ 15 funcții în total pentru inițializarea, crearea, distrugerea și plasarea pluginurilor. NPAPI acceptă, de asemenea, scriptarea, imprimarea, vizualizarea pe ecran complet, pluginurile fără ferestre și transmiterea de conținut.

Capacitatea de a adăuga scripturi la pluginuri este o caracteristică care permite codului JavaScript de pe o pagină să interacționeze cu un plugin. Mai multe versiuni ale Netscape și ulterior Mozilla au acceptat această caracteristică folosind diferite tehnologii: LiveConnect, XPConnect și npruntime.

LiveConnect

Cu Netscape 4, NPAPI a fost extins pentru a permite exploatarea pluginurilor prin scripturi. Această caracteristică s-a numit LiveConnect . Un plugin ar putea implementa și returna o instanță a unei clase Java . Metodele publice expuse de această clasă au reprezentat interfața la care scripturile ar putea fi aplicate. Clasa ar putea fi apelată prin cod JavaScript , precum și din alte applet-uri Java care rulează în interiorul paginii, în timp ce browserul monitoriza apelurile între diferitele contexte de execuție.

Dezavantajul LiveConnect era că era strâns legat de versiunea Java integrată în browserul Netscape. Acest lucru a împiedicat browserul să utilizeze alte runtime și a împovărat semnificativ descărcarea browserului, deoarece Java a fost o componentă critică pentru scriptarea pluginurilor.

De asemenea, programarea LiveConnect nu a fost deloc simplă. Dezvoltatorul a trebuit să definească o clasă Java pentru plugin, să o ruleze printr-un compilator de antet Java specializat și să implementeze metodele native. Gestionarea șirurilor, a excepțiilor și a altor obiecte Java de la C ++ a fost frustrantă și cu siguranță nu a fost evidentă. Pentru a înrăutăți lucrurile a fost faptul că LiveConnect a folosit un API acum depășit pentru a invoca metode native C ++ din Java, numite JRI. Tehnologia JRI a fost înlocuită de mult cu JNI .

XPConnect

LiveConnect s-a dovedit extrem de problematic pentru Mozilla. Dependența de un timp de execuție Java învechit și de API-ul JRI a însemnat că LiveConnect nu a putut funcționa.

Mozilla folosea deja XPCOM pentru a defini interfețe cu multe obiecte implementate în C ++. Fiecare interfață a fost definită printr-un fișier Interface Definition Language ( IDL ) și a fost transmisă unui compilator IDL care a produs fișiere antet și o bibliotecă independentă de limbaj de programare care a constituit reprezentarea binară a interfeței: acesta din urmă a descris interfața., Metodele, parametrii , structuri de date și enumerări.

XPCOM folosește informații de tip bibliotecă pentru a regla apelurile între diferite contexte thread și între codul C ++ compilat nativ JavaScript. Deoarece XPConnect este utilizat intens de Mozilla, este foarte robust, suportat și documentat. Începând cu Netscape 6.1 și Mozilla 0.9.2, NPAPI a fost extins în așa fel încât un plugin să poată returna o interfață scriptabilă, în timp ce XPConnect se ocupă de gestionarea apelurilor către pluginul respectiv din JavaScript și cod C ++.

Acest lucru a făcut ca dependența de Java să nu mai fie necesară, dar a provocat unele probleme. În special, deoarece implementarea se face folosind componente XPCOM, o tehnologie similară cu Microsoft COM , dezvoltatorul de pluginuri trebuie să știe cum să gestioneze numărarea referințelor, interfețele, IDL și așa mai departe pentru a implementa scriptarea. În plus, dependența de XPCOM a dus la unele probleme în legarea dinamică a bibliotecilor (de exemplu, problema fragilă a clasei de bază ) care trebuiau rezolvate pentru a permite pluginului să funcționeze corect cu diferite browsere. XPCOM a fost modificat ulterior pentru a oferi o versiune legată static pentru a rezolva aceste probleme. Această abordare necesită, de asemenea, instalarea unui fișier. xpt în aceeași locație aleasă pentru DLL, în caz contrar pluginul va părea să funcționeze, în timp ce funcționalitatea de scriptare nu va fi disponibilă.

Npruntime

La sfârșitul anului 2004, toți dezvoltatorii principali de browser (cu excepția Microsoft ) au ales împreună npruntime ca o extensie la NPAPI original pentru a oferi funcționalitate de scriptare, printr-un API similar cu vechiul API în stil C și independent de alte tehnologii, cum ar fi Java sau XPCOM.

npruntime este acceptat de ultima generație de browsere Mozilla (1.7.5+) / Firefox, Safari și Opera. Toate pluginurile noi ar trebui să utilizeze acest API.

Comparație între controalele NPAPI și ActiveX

Microsoft a dezvoltat legarea și încorporarea obiectelor (OLE2) pentru a face posibilă crearea de documente compuse în aplicații precum Microsoft Word . De exemplu, un document scris într-un procesor de text poate conține o foaie de calcul încorporată care ar putea fi lansată în fereastra procesorului de text.

OLE2 a fost proiectat pe baza COM și a definit interfețe pentru diferitele sarcini pe care containerul și obiectul trebuiau să le îndeplinească. Un control OLE2 (cunoscut și sub numele de OCX) a fost un obiect ușor OLE2 care putea fi integrat într-un container, dar nu a salvat cantități mari de date și nici nu a necesitat meniuri sau bare de instrumente pentru a funcționa.

Un control a fost implementat de un DLL și încărcat în spațiul de adresă al containerului gazdă, cum ar fi Visual Basic . Primele versiuni ale Visual Basic au folosit o tehnologie similară numită Extensie Visual Basic , dar controalele OCX au fost considerate mai bune. Fiecare OCX a implementat un subset bine definit de interfețe OLE2 pe care containerul le-ar putea folosi pentru a manipula controlul, de exemplu pentru a-l muta sau pentru a furniza informații despre container. OCX a implementat, de asemenea, un mecanism de automatizare care permitea publicarea metodelor și proprietăților care puteau fi modificate și a folosit o metodă complementară pentru a returna evenimentele în container.

OLE2 a fost foarte complicat, iar suportul său în MFC-uri a fost minim, astfel încât Microsoft a simplificat specificațiile pentru ao simplifica și a redenumit tehnologia în ActiveX . Chiar și după simplificare, controalele impuneau neapărat implementarea a aproximativ 6 interfețe fundamentale. Microsoft, pentru a atenua această complexitate, a produs vrăjitori, clase de bază ATL, macro-uri și extensii la limbajul C ++ pentru a simplifica controalele de scriere.

Începând cu Internet Explorer 3.0, a fost adăugată capacitatea de a găzdui controale ActiveX în cadrul conținutului HTML. Dacă browserul a procesat o pagină care a specificat un control ActiveX printr-o etichetă OBJECT (și o sintaxă neacceptată de W3C ), acesta va descărca și instala automat controlul, cu o intervenție redusă, dacă există, a unui utilizator. Acest lucru a făcut ca utilizarea internetului să fie „mai bogată”, dar a fost percepută ca limitativă (deoarece controalele funcționau doar pe Windows) și ca un risc de securitate, din cauza lipsei intervenției utilizatorului. Microsoft a fost nevoită să introducă măsuri de securitate pentru a remedia neajunsurile sale. De exemplu:

• Pachetele de instalare de control (fișiere de tip cabinet și fișiere executabile) trebuie semnate digital .
• Controalele trebuie să se declare în mod explicit sigure pentru scriptare.
• Setările implicite de securitate au devenit din ce în ce mai restrictive.
• Internet Explorer menține o „listă neagră” de controale nesigure.

Internet Explorer, până la un moment dat, a acceptat pluginuri NPAPI. Pluginurile care au funcționat în browserul Netscape au funcționat și pe Internet Explorer, datorită unui mic control ActiveX implementat într-un fișier „plugin.ocx” care a acționat ca intermediar între browser și plugin. Browserul a încărcat controlul și l-a folosit pentru a găzdui pluginurile apelate pe acea pagină. Cu toate acestea, Microsoft a susținut, la un moment dat, că pluginurile NPAPI (sau implementarea API-ului Internet Explorer) cauzează probleme de securitate și a eliminat suportul în Internet Explorer versiunea 5.5 SP2. ^[1]

Versiunile ulterioare ale Internet Explorer vor introduce cel mai probabil un model bazat pe .NET printr-un sandbox și profiluri de securitate special concepute pentru a controla drepturile atribuite fiecărui control.

Siguranță

Există o credință larg răspândită despre tehnologia NPAPI că un plugin este inerent mai sigur decât un control ActiveX. Ambele execută instrucțiuni native pentru mașină cu aceleași privilegii ca și procesul gazdă. Prin urmare, un plugin rău intenționat poate deteriora un sistem la fel de mult ca un control ActiveX nesigur.

O diferență semnificativă între NPAPI și ActiveX este că NPAPI este doar pentru pluginurile de Internet, în timp ce ActiveX este utilizat pentru un număr mare de scopuri, inclusiv crearea de aplicații în Visual Basic. Utilizatorul mediu Windows are instalat un număr mare de controale ActiveX, dintre care unele sunt probabil declarate „sigure pentru scriptare”, deși nu sunt de fapt. Oricare dintre ele poate fi folosită ca cap de pod pentru a prelua controlul computerului utilizatorului.

O altă diferență pentru NPAPI este că software-ul care îl implementează (înainte de Mozilla Firefox , vezi mai jos) nu descarcă sau instalează automat pluginurile lipsă. Un plugin lipsă a dus la o imagine constând din linii zimțate în browser în loc de plugin. Dacă utilizatorul făcea clic pe el, era direcționat către pagina serviciului de căutare plugin, de unde putea descărca și instala manual pluginul în deplină autonomie. Deși acest lucru este un inconvenient pentru utilizator, este o măsură importantă de securitate, deoarece a împiedicat conținutul afișat să utilizeze browserul ca vector pentru malware .

În Internet Explorer, conținutul HTML specifică unde ar trebui să se afle controlul ActiveX. Dacă controlul nu este deja instalat, IE va descărca și instala automat controlul de la sursa specificată, oprindu-se doar pentru a afișa semnătura digitală utilizatorului și va obține consimțământul la începutul instalării. Pentru controale sigure, această abordare oferă un mecanism de instalare mai simplu și minimizează necesitatea intervenției utilizatorului. Cu toate acestea, conținutul rău intenționat vă poate convinge, prin tehnici viclene de inginerie socială , să ignorați avertismentele (sau bunul lor simț) și să instalați ceva care vă poate afecta intimitatea sau sistemul. Un număr mare de site-uri spyware , adware și malware utilizează aceste mecanisme pentru a furniza conținut executabil sistemelor. Microsoft a trebuit să mărească nivelul de securitate implicit pentru ActiveX și trebuie să mențină liste negre de controale rău intenționate, în încercarea de a atenua riscurile.

Mozilla Firefox încearcă să aleagă o cale de mijloc. Dacă un plugin nu este prezent, acesta va notifica utilizatorul despre situație și va stabili o conexiune sigură la un serviciu de căutare a pluginurilor găzduit pe mozilla.org. Utilizatorul poate permite Firefox să descarce și să instaleze pluginul. Acest șablon împiedică specificarea conținutului afișat de unde trebuie descărcat pluginul - serviciul de căutare se va ocupa de asta. Acest lucru permite Firefox să prezinte un mecanism de instalare aproape simplu, dar limitează capacitatea pluginurilor certificate și compatibile furnizate de surse de încredere. Evident, acest model consideră că rezultatul returnat de serviciul de căutare a pluginurilor este implicit sigur, ceea ce necesită un nivel mai ridicat de securitate pe site-ul care găzduiește serviciul în sine.

PPAPI

În august 2009 Google a lansat un nou proiect Pepper numit Pepper Plugin API (PPAPI) ^[2] , „o serie de modificări ale structurii NPAPI pentru a face pluginul mai sigur” ^[3] . Această extensie a fost concepută pentru a facilita implementarea diferitelor procese în timpul rulării pluginului . Mai mult, obiectivele proiectului sunt de a oferi un cadru util de plugin - uri pe mai multe platforme . Subiectele luate în considerare includ:

• Uniformitate semantică NPAPI pentru toate browserele.
• Rularea într-un proces separat de renderer / browser în sine.
• Standardizați redarea utilizând un proces de compunere a browserului.
• Definirea evenimentelor standardizate și a funcțiilor de rasterizare 2D.
• Prima încercare de a oferi acces grafic 3D.
• Plugin de registru.

Începând din mai 2010 , browserul open source Google , Chromium , este singurul browser care acceptă noul model de plugin PPAPI ^[4] , Mozilla a anunțat că „nu este interesat să implementeze tehnologia PPAPI în acest moment” ^[5] .

În februarie 2012, Adobe a anunțat că viitoarele versiuni ale Flash Player de pe platforma Linux vor fi livrate numai prin intermediul acestui API, deși Flash Player 11.2, cu suport NPAPI, va primi actualizări de securitate timp de cinci ani ^[6] . Ulterior, dezvoltatorii Google au dezvăluit că începând cu versiunea 42 a Chrome pluginurile NPAPI nu vor fi activate în mod implicit (deși va fi totuși posibilă forțarea utilizării acestora din pagina de setări chrome: // flags ), în timp ce din versiunea 45 vor fi activate să nu fie cel mai susținut ^{[7] [8]} .

Cele mai utilizate pluginuri

• Adobe Acrobat
• Adobe Shockwave
• Adobe Flash Player
• Java Runtime Environment
• Jucător adevărat
• Timp rapid
• VLC media player
• Windows Media Player

Notă

linkuri externe

• ( RO ) Documentație pentru dezvoltarea pluginurilor în Centrul pentru dezvoltatori Mozilla
• (EN) cel mai vechi din documentația de pe pagina de pornire a dezvoltării pluginurilor , la mozilla.org.
• ( EN ) Scrierea pluginurilor folosind Mozilla , la mozilla.org .
• ( RO ) Un control ActiveX care oferă suport pentru plugin - Componentă de înlocuire pentru plugin.ocx, care a fost eliminată din Internet Explorer.
• ( RO ) IE Rivals Claim ActiveX Alternative - CNET , pe news.com.com (arhivat din original la 8 martie 2013) .

Portal internet

Portal telematic