Introducere în XML-RPC. Concursuri de programare Ce este vizibil în jurnalele serverului
Postarea sa arată, de asemenea, cum să faci autentificarea browserului, după cum urmează:
$request = xmlrpc_encode_request ("methodName" , array ("methodParam" ));
$auth = cod_base64 ($nume utilizator . ":" . $parolă );
$header = (version_compare(phpversion(), "5.2.8"))
? array("Content-Type: text/xml" , "Autorizare: Basic $auth " )
: „Tip de conținut: text/xml\r\nAutorizare: de bază$auth" ; //
$context = stream_context_create (array("http" => array(
"method" => "POSTARE" ,
"header" => $header ,
„conținut” => $cerere
)));
$serviciu web = „http://www.example.com/rpc”;
$file = file_get_contents($webservice, false, $context);
$răspuns = xmlrpc_decode ($fișier);
dacă (xmlrpc_is_fault($răspuns)) (
returnează „xmlrpc: $răspuns [ faultString ] ($răspuns [ faultCode ] )” ;
) altfel (
returnează $răspuns ;
}
?>
1 - NOTA EDITORULUI: ACEASTA ESTE O REPARARE DE LA „SandersWang dt php at gmail dot com”
acum 16 ani
Șirurile binare (setate cu xmlrpc_set_type) intră în a
Oricât de prost ar fi, provoacă probleme reale pentru unele servere XML-RPC, cum ar fi http://jakarta.apache.org/xmlrpc/ (nee Helma). Eliminarea acestor entități cu ceva de genul
$req = preg_replace("/ /", "", xmlrpc_encode_request("my.method", $args));
lucrează în jurul problemei.
acum 11 ani
Trebuie remarcat faptul că codificarea nu pare să codifice nimic, trebuie doar să specificați ce intră în antetul XML.
Am avut probleme cu șirurile UTF dublu-codate care au fost salvate în baza de date când am folosit această funcție, trimițându-l la un servlet apache xml-rpc și stocându-l în baza de date mysql. S-a rezolvat setând „escape” doar „markup” și „encoding” la „UTF-8” (nu uitați să setați „utf-8” și în xmlrpc_decode).
Se pare că șirurile codificate UTF-8 sunt scăpate cu octeții lor ca entități în loc de caracterele lor ca entități.
acum 9 ani
Ați încercat vreodată să transmiteți o matrice ca următoarea cu xmlrpc?
$var1=array(7=>14,9=>18);
Matricea de ieșire arată destul de diferit! Va arata asa:
$var2=matrice(14,18);
Singura soluție pe care am găsit-o este să adau un spațiu înaintea indexului:
$var3=matrice(" 7"=>14," 9"=>18);
Folosind această metodă, veți obține rezultatul corect. ($var1)
acum 16 ani
Această funcție ar trebui utilizată de un client XML-RPC pentru a crea o sarcină utilă XML pentru o solicitare XML-RPC;
$params = "system.methodSignature" ;
$method = "system.methodHelp" ;
$cerere = xmlrpc_encode_request ($metoda, $params);
ecou ($cerere);
?>
Produce;
Al doilea argument recunoaște tipul de variabilă și generează structura corectă XML-RPC. Consultați xmlrpc_encode() pentru mai multe detalii.
acum 12 ani
Client OO simplu cu funcția Overload:
metoda php test_helloworld este tradusă în metoda xmlrpc test.helloworld.
clasa RpcClient(
private $_methods;
privat $_context;
$_url privat;
Funcția __construct ($url, $user, $passwd) (
$auth = base64_encode(sprintf("%s:%s", $user,$passwd));
$this->_context = stream_context_create(array(
"http" => matrice(
"method" => "POST",
"header" => "Tip de conținut: text/xml\r\n".
„Autorizare: $auth de bază” ,
)
));
$this->_url = $url;
$this->registerMethod("Test_HelloWorld");
Funcția __call($methodName, $params) (
dacă (array_key_exists($methodName,$this->_methods)) (
// on appelle la fonction RPC
$m = str_replace("_", ".", $methodName);
$r = xmlrpc_encode_request($m, $params,array("verbosity"=>"newlines_only"));
$c = $this->_context;
stream_context_set_option($c,"http","conținut",$r);
$f = file_get_contents($this->_url,false,$c);
$resp = xmlrpc_decode($f);
return $resp;
) altfel (
// on appelle la fonction de l"objet
call_user_method_array($methodName, $this,$params);
}
}
Funcție privată registerMethod ($method) (
$aceasta->_metode[$metoda] = adevărat;
}
Introducere în XML-RPC
Există multe resurse diferite pe Internet care oferă utilizatorilor anumite informații. Aceasta nu înseamnă pagini statice obișnuite, ci, de exemplu, date preluate dintr-o bază de date sau arhive. Aceasta ar putea fi o arhivă de date financiare (cursuri de schimb, cotații de valori mobiliare), date meteorologice sau informații mai extinse - știri, articole, mesaje de pe forumuri. Astfel de informații pot fi prezentate vizitatorului paginii, de exemplu, printr-un formular, ca răspuns la o solicitare, sau pot fi generate dinamic de fiecare dată. Dar dificultatea este că adesea astfel de informații sunt necesare nu atât de utilizatorul final - o persoană, cât de alte sisteme și programe care vor folosi aceste date pentru calculele lor sau pentru alte nevoi.
Exemplu real: o pagină a unui site bancar care afișează cotațiile valutare. Dacă accesezi pagina ca utilizator obișnuit, printr-un browser, vezi tot designul paginii, bannere, meniuri și alte informații care „încadrează” adevăratul scop al căutării - cotațiile valutare. Dacă trebuie să introduceți aceste cotații în magazinul dvs. online, atunci nu mai rămâne nimic de făcut decât să selectați manual datele necesare și să le transferați pe site-ul dvs. prin clipboard. Și va trebui să faci asta în fiecare zi. Chiar nu există nicio ieșire?
Dacă rezolvați problema frontal, atunci apare imediat o soluție: un program (script pe un site web) care are nevoie de date primește o pagină de la server ca „utilizator obișnuit”, analizează (parsează) codul html rezultat și extrage informațiile necesare din acesta. Acest lucru se poate face fie cu o expresie regulată regulată, fie folosind orice parser html. Dificultatea abordării constă în ineficacitatea acesteia. În primul rând, pentru a primi o mică parte de date (datele despre monede sunt literalmente o duzină sau două caractere), trebuie să primiți întreaga pagină, care este de cel puțin câteva zeci de kiloocteți. În al doilea rând, cu orice modificare a codului paginii, de exemplu, designul s-a schimbat sau altceva, algoritmul nostru de analizare va trebui refăcut. Și acest lucru va necesita o cantitate destul de mare de resurse.
Prin urmare, dezvoltatorii au ajuns la o decizie - este necesar să se dezvolte un fel de mecanism universal care să permită un schimb transparent (la nivel de protocol și mediu de transmisie) și ușor de schimb de date între programe care pot fi localizate oriunde, să fie scrise în orice limbă. și rulează sub orice sistem de operare.sisteme și pe orice platformă hardware. Un astfel de mecanism se numește acum termenii „servicii web”, „SOAP”, „arhitectură orientată spre servicii”. Pentru schimbul de date se folosesc standarde deschise și testate în timp - protocolul HTTP este folosit pentru transmiterea mesajelor (deși pot fi folosite și alte protocoale - SMTP, de exemplu). Datele în sine (în exemplul nostru, ratele de schimb) sunt transmise ambalate într-un format multiplatform - sub formă de documente XML. În acest scop, a fost inventat un standard special - SAPUN.
Da, acum serviciile web, SOAP și XML sunt pe buzele tuturor, încep să fie implementate activ, iar corporații mari precum IBM și Microsoft lansează noi produse concepute pentru a ajuta la implementarea totală a serviciilor web.
Dar! Pentru exemplul nostru cu cursuri de schimb care trebuie transmise de pe site-ul băncii către motorul magazinului online, o astfel de soluție va fi foarte dificilă. La urma urmei, doar descrierea standardului SOAP ocupă o mie și jumătate de pagini obscene și asta nu este tot. Pentru utilizare practică, va trebui, de asemenea, să înveți cum să lucrezi cu biblioteci și extensii terțe (numai începând cu PHP 5.0 include o bibliotecă pentru lucrul cu SOAP) și să scrii sute și mii de rânduri din propriul tău cod. Și toate acestea pentru a obține câteva litere și cifre sunt, evident, foarte greoaie și iraționale.
Prin urmare, există un alt standard alternativ, s-ar putea spune, pentru schimbul de informații - XML-RPC. A fost dezvoltat cu participarea Microsoft de către UserLand Software Inc și este conceput pentru transferul unificat de date între aplicații prin Internet. Poate înlocui SOAP atunci când construiesc servicii simple în care nu sunt necesare toate capacitățile „întreprinderii” ale serviciilor web reale.
Ce înseamnă abrevierea XML-RPC? RPC înseamnă Remote Procedure Call. Aceasta înseamnă că o aplicație (fie un script pe server sau o aplicație obișnuită pe computerul client) poate folosi în mod transparent o metodă care este implementată fizic și executată pe un alt computer. XML este folosit aici pentru a oferi un format universal pentru descrierea datelor transmise. Ca transport, protocolul HTTP este folosit pentru a transmite mesaje, ceea ce vă permite să faceți schimb de date fără probleme prin orice dispozitiv de rețea - routere, firewall-uri, servere proxy.
Și astfel, pentru a utiliza trebuie să aveți: un server XML-RPC care oferă una sau mai multe metode, un client XML-RPC care poate genera o cerere corectă și procesa răspunsul serverului și, de asemenea, să cunoască parametrii serverului necesari pentru o funcționare cu succes - adresa, numele metodei și parametrii trecuți.
Toate lucrările cu XML-RPC au loc în modul „cerere-răspuns”, aceasta este una dintre diferențele dintre tehnologie și standardul SOAP, unde există atât conceptele de tranzacții, cât și capacitatea de a efectua apeluri întârziate (când serverul salvează cererea și îi răspunde la un anumit moment în viitor). Aceste caracteristici suplimentare sunt mai utile pentru serviciile corporative puternice; ele complică semnificativ dezvoltarea și suportul serverelor și impun cerințe suplimentare dezvoltatorilor de soluții pentru clienți.
Procedura de lucru cu XML-RPC începe cu formarea unei cereri. O cerere tipică arată astfel:
POST /RPC2 HTTP/1.0
Agent utilizator: eshop-test/1.1.1 (FreeBSD)
Gazdă: server.localnet.com
Tip de conținut: text/xml
Lungimea conținutului: 172
Primele linii formează antetul standard de solicitare HTTP POST. Parametrii necesari includ gazdă, tipul de date (tip MIME), care trebuie să fie text/xml și lungimea mesajului. Standardul mai specifică că câmpul User-Agent trebuie completat, dar poate conține o valoare arbitrară.
Urmează antetul obișnuit al documentului XML. Elementul rădăcină al cererii este
Linia
Apoi, parametrii transmisi sunt setati. Această secțiune este folosită pentru aceasta.
Descrierea tuturor parametrilor este urmată de etichete de închidere. Cererea și răspunsul în XML-RPC sunt documente XML obișnuite, așa că toate etichetele trebuie închise. Dar nu există etichete unice în XML-RPC, deși sunt prezente în standardul XML.
Acum să ne uităm la răspunsul serverului. Antetul răspunsului HTTP este normal; dacă cererea este procesată cu succes, serverul returnează un răspuns HTTP/1.1 200 OK. La fel ca în cerere, trebuie să specificați corect tipul MIME, lungimea mesajului și data generării răspunsului.
Corpul de răspuns în sine este următorul:
Acum, în loc de eticheta rădăcină
Dacă a apărut o eroare în timpul procesării cererii dvs., în loc de Răspunsul va conține elementul
Acum să aruncăm o scurtă privire asupra tipurilor de date în XML-RPC. Există 9 tipuri de date în total - șapte tipuri simple și 2 complexe. Fiecare tip este descris de propria etichetă sau set de etichete (pentru tipuri complexe).
Tipuri simple:
Numere întregi- etichetă
tip boolean- etichetă
șir ASCII- descris prin etichetă
Numere în virgulă mobilă- etichetă
data si ora- descris prin etichetă
Ultimul tip simplu este șir codificat în bază64, care este descris de etichetă
Tipurile complexe sunt reprezentate prin structuri și matrice. Structura este determinată de elementul rădăcină
Matricele nu au nume și sunt descrise de etichetă
Desigur, cineva va spune că o astfel de listă de tipuri de date este foarte slabă și „nu vă permite să vă extindeți”. Da, dacă trebuie să transferați obiecte complexe sau cantități mari de date, atunci este mai bine să utilizați SOAP. Și pentru aplicațiile mici, nepretențioase, XML-RPC este destul de potrivit; în plus, de foarte multe ori chiar și capabilitățile sale se dovedesc a fi prea multe! Având în vedere ușurința de implementare, un număr foarte mare de biblioteci pentru aproape orice limbă și platformă și suport larg în PHP, atunci XML-RPC de multe ori pur și simplu nu are concurenți. Deși nu poate fi recomandat imediat ca soluție universală - în fiecare caz specific trebuie decis în funcție de circumstanțe.
Tehnologia XML-RPC este utilizată în sistemul WordPress pentru diverse caracteristici frumoase, cum ar fi pingback-uri, trackback-uri, gestionarea de la distanță a site-ului fără a vă conecta la panoul de administrare etc. Din păcate, atacatorii îl pot folosi pentru a efectua atacuri DDoS pe site-uri web. Adică creezi proiecte WP frumoase, interesante pentru tine sau la comandă și, în același timp, fără să bănuiești nimic, poți face parte dintr-un botnet DDoS. Conectând zeci și sute de mii de site-uri împreună, oamenii răi creează un atac puternic asupra victimei lor. Deși în același timp și site-ul tău are de suferit, pentru că... sarcina merge la gazduirea unde se afla.
Dovezile unei astfel de activități proaste pot fi în jurnalele serverului (access.log în nginx), care conțin următoarele rânduri:
103.238.80.27 - - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"
Dar să revenim la vulnerabilitatea XML-RPC. Vizual, se manifestă prin deschiderea lentă a site-urilor de pe serverul dvs. sau imposibilitatea de a le încărca deloc (eroare 502 Bad Gateway). Suportul tehnic al gazdei mele FASTVPS mi-a confirmat presupunerile și mi-a sfătuit:
- Actualizați WordPress la cea mai recentă versiune împreună cu pluginuri. În general, dacă urmați, este posibil să fi citit despre necesitatea de a instala cel mai recent 4.2.3. din cauza criticilor de securitate (la fel ca versiunile anterioare). Pe scurt, e bine să actualizezi.
- Instalați pluginul Dezactivați XML-RPC Pingback.
Dezactivarea XML-RPC în WordPress
Anterior, mi se pare că opțiunea de a activa/dezactiva XML-RPC era undeva în setările sistemului, dar acum nu o găsesc acolo. Prin urmare, cel mai simplu mod de a scăpa de el este să utilizați pluginul corespunzător.
Găsiți și descărcați Dezactivați XML-RPC Pingback sau instalați-l direct din panoul de administrare a sistemului. Nu trebuie să configurați nimic suplimentar, modulul începe să funcționeze imediat. Îndepărtează metodele pingback.ping și pingback.extensions.getPingbacks din interfața XML-RPC. În plus, elimină X-Pingback din anteturile HTTP.
Într-unul dintre bloguri am găsit încă câteva opțiuni pentru a elimina dezactivarea XML-RPC.
1. Dezactivați XML-RPC în șablon.
Pentru a face acest lucru, adăugați următoarea linie în fișierul functions.php al temei:
Eu personal nu am folosit ultimele două metode, pentru că... Am conectat pluginul Disable XML-RPC Pingback - cred că va fi suficient. Doar pentru cei cărora nu le plac instalările inutile, le-am sugerat opțiuni alternative.
Începând de sâmbătă la prânz, serverul meu, unde sunt găzduite aproximativ 25 de site-uri Wordpress, a început să se confrunte cu încetiniri severe. Din moment ce am reușit să supraviețuiesc atacurilor anterioare ( , ) fără să fiu observat, nu am înțeles imediat ce se întâmplă.
Când mi-am dat seama, s-a dovedit că parolele erau forțate brutal + multe solicitări către XMLRPC.
Drept urmare, am reușit să tăiem totul, deși nu imediat. Iată trei trucuri simple pentru a evita acest lucru.
Aceste tehnici sunt cel mai probabil cunoscute de toată lumea, dar am călcat pe câteva greșeli pe care nu le-am găsit în descrieri - poate că acest lucru va economisi timp cuiva.
1. Opriți căutarea, instalați pluginul Limit Login Attempts - instalați-l, deoarece alte protecții încetinesc foarte mult serverul, de exemplu, când utilizați pluginul Login Security Solution, serverul a murit după o jumătate de oră, pluginul încarcă puternic baza de date .
În setări, asigurați-vă că activați caseta de selectare „Pentru proxy” - altfel va determina IP-ul serverului dvs. pentru toată lumea și va bloca automat pe toată lumea.
UPDATE, mulțumesc, detaliile sunt mai jos în comentarii - activați caseta de selectare „Pentru proxy” numai dacă definiția nu funcționează când „Conexiune directă” este activată
2. Dezactivați XML-RPC - pluginul Disable XML-RPC (este ușor de activat și atât).
3. Închideți wp-login.php - dacă accesați site-ul prin IP, pluginul nu funcționează și pickerii continuă să blocheze site-ul. Pentru a evita acest lucru, adăugați la .htaccess:
Copiem fișierul wp-login, îl redenumim cu orice nume ciudat, de exemplu poletnormalny.php, iar în interiorul fișierului, folosim autocorrecția pentru a schimba toate inscripțiile wp-login.php în poletnormalny.php.
Asta e, acum poți accesa panoul de administrare doar folosind fișierul tău.
După acești 3 pași simpli, site-urile au început să zboare din nou și a venit liniștea.
Ei bine, dintr-o dată este interesant
Una dintre opțiuni este să vezi dacă ești atacat. Acest lucru poate fi văzut în jurnalele nginx (de exemplu, aici este calea pentru fișierul Debian /var/log/nginx access.log).WordPress a avut întotdeauna un instrument încorporat pentru accesarea de la distanță a site-ului dvs. Într-adevăr, uneori trebuie să ajungi pe site-ul tău, dar computerul tău este departe de tine. Multă vreme, soluția a fost un fișier numit xmlrpc.php. Cu toate acestea, în ultimii ani acest fișier a devenit mai mult o problemă decât o soluție.
Mai jos vom arunca o privire mai atentă la xmlrpc.php și de ce a fost creat. Ne vom uita, de asemenea, la problemele comune de securitate pe care le poate cauza și la cum să le remediam pentru site-ul dvs. WordPress.
XML-RPC este o caracteristică WordPress care permite transferul de date, HTTP servind ca transport și XML pentru codare. Deoarece WordPress nu este un sistem închis și comunică adesea cu alte sisteme, s-au găsit soluții pentru această problemă.
De exemplu, să presupunem că doriți să postați pe site-ul dvs. web de pe telefonul mobil. Trebuie să utilizați accesul de la distanță oferit de xmlrpc.php.
Funcționalitatea principală a xmlrpc.php este abilitatea de a se conecta la site de pe un smartphone, implementarea de trackback-uri și linkback-uri de pe alte site-uri și unele funcții legate de plugin-ul Jetpack.
De ce a fost creat Xmlrpc.php și cum a fost folosit?
Implementarea XML-RPC merge cu mult înapoi la primele zile ale WordPress și chiar înainte ca WordPress să devină WordPress.
În primele zile ale internetului, conexiunile erau foarte lente, iar procesul de înregistrare și publicare pe web era mult mai dificil și consuma mult timp. În loc să facă modificări direct prin browser, majoritatea le-au făcut offline și apoi și-au copiat și lipit conținutul online. Și acest proces a fost departe de a fi ideal.
Soluția (la acea vreme) era să creezi un client de blogging offline în care să-ți compui conținutul, apoi să te conectezi la blogul tău și să-l publici. Această conexiune a fost realizată prin XML-RPC. Cu funcționalitatea de bază XML-RPC, aplicațiile timpurii care foloseau aceste conexiuni au oferit oamenilor posibilitatea de a-și accesa site-urile WordPress de pe alte dispozitive.
XML-RPC astăzi
În 2008, cu versiunea 2.6 a WordPress, a fost introdusă o opțiune pentru a activa sau dezactiva XML-RPC. Cu toate acestea, odată cu lansarea aplicației WordPress pentru iPhone, suportul XML-RPC a fost activat în mod implicit și nu a existat nicio opțiune pentru a-l dezactiva. Așa rămâne și astăzi.
Desigur, funcționalitatea oferită de acest fișier a scăzut semnificativ de-a lungul timpului, iar dimensiunea fișierului a scăzut de la 83 kb la 3 kb, nu mai joacă un asemenea rol ca înainte.
Proprietăți XML-RPC
Cu noua interfață de programare a aplicațiilor WordPress (API), ne putem aștepta ca XML-RPC să fie complet dezactivat. Astăzi, acest nou API este încă în testare și poate fi activat doar printr-un plugin special.
Deși vă puteți aștepta ca API-ul să fie inclus direct în nucleul WordPress în viitor, eliminând complet necesitatea xmlrpc.php.
Noul API nu este perfect, dar oferă o securitate bună, de încredere, spre deosebire de xmlrpc.php.
De ce dezactivați Xmlrpc.php
Cea mai mare problemă cu XML-RPC este securitatea. Problema nu este direct legată de XML-RPC, dar poate fi folosită pentru a activa un atac asupra site-ului dvs.
Desigur, vă puteți proteja cu o parolă foarte puternică și pluginuri de securitate WordPress. Dar cel mai bun mod de protecție este pur și simplu să îl dezactivați.
Există două puncte slabe principale ale XML-RPC care au fost exploatate în trecut.
Primul folosește atacuri de forță brută pentru a obține acces la site-ul tău. Atacatorul va încerca să obțină acces la site-ul dvs. folosind xmlrpc.php încercând diferite combinații de nume de utilizator și parole. Ei pot folosi eficient o singură comandă pentru a testa sute de parole diferite. Acest lucru le permite să ocolească instrumentele de securitate care ar detecta și bloca în mod normal atacurile cu forță brută.
Al doilea este de a scoate site-ul offline printr-un atac DDoS. Hackerii vor folosi notificarea inversă în WordPress pentru a o trimite la mii de site-uri în același timp. Această funcționalitate xmlrpc.php oferă hackerilor un număr aproape infinit de adrese IP pentru a propaga un atac DDoS.
Pentru a verifica dacă XML-RPC funcționează pe site-ul dvs., îl puteți rula folosind un instrument numit XML-RPC Validator. Rulați site-ul cu instrumentul și dacă primiți o eroare, înseamnă că nu aveți suport XML-RPC.
Dacă primiți un mesaj de succes, puteți opri xmlrpc.php folosind una dintre cele două abordări de mai jos.
Metoda 1: Dezactivați Xmlrpc.php folosind un plugin
Dezactivarea XML-RPC pe site-ul dvs. WordPress este incredibil de ușoară.
Accesați secțiunea Pluginuri › Adăugați noiîn consola dvs. de administrare WordPress. Găsiți un plugin Dezactivați XML-RPCși instalează-l, arată ca în imaginea de mai jos:
Activați pluginul și ați terminat. Acest plugin va introduce automat codul necesar pentru a dezactiva XML-RPC.
Cu toate acestea, rețineți că pluginurile instalate pot folosi părți ale XML-RPC, iar apoi dezactivarea acestuia poate cauza un conflict între pluginuri sau părțile lor individuale și le poate scoate din modul de lucru.
Dacă doriți doar să dezactivați elemente XML-RPC individuale, dar să permiteți ca alte pluginuri și funcții să funcționeze, atunci căutați pluginuri ca acestea:
- Opriți atacul XML-RPC. Acest plugin va opri toate atacurile XML-RPC, dar va permite pluginurilor precum Jetpack și altor instrumente automate și plugin-uri să continue să ruleze, oferindu-le acces la fișierele xmlrpc.php.
- Controlează publicarea XML-RPC. Acest lucru vă permite să mențineți controlul și să publicați de la distanță.
Metoda 2: Dezactivați manual Xmlrpc.php
Dacă nu doriți să utilizați un plugin și preferați să o faceți manual, urmați această abordare. Acesta va opri toate solicitările xmlrpc.php primite înainte de a fi transmise la WordPress.
Deschideți fișierul .htaccess. Poate fi necesar să activați „afișați fișierele ascunse” în managerul de fișiere sau în clientul FTP pentru a găsi acest fișier.
Lipiți acest cod în fișier .htaccess:
# Blocați cererile WordPress xmlrpc.php
Gânduri finale
În general, XML-RPC a fost o soluție solidă la unele dintre problemele apărute cu publicarea de la distanță pe site-ul dvs. WordPress. Totuși, în același timp, au apărut niște găuri de securitate care s-au dovedit a fi destul de periculoase pentru unii proprietari de site-uri WordPress.
Pentru a vă menține site-ul în siguranță, este recomandat să dezactivați complet xmlrpc.php, cu excepția cazului în care aveți nevoie de unele dintre funcțiile cerute de publicarea de la distanță și de pluginul Jetpack. Apoi puteți utiliza pluginuri de soluție care vă permit să utilizați aceste funcții în timp ce corectați găurile de securitate.
De-a lungul timpului, ne putem aștepta ca funcționalitatea XML-RPC să devină integrată într-un nou API WordPress care va sprijini accesul de la distanță fără a sacrifica securitatea.
Ați blocat accesul la XML-RPC printr-un plugin sau manual? Sau au existat probleme de securitate deoarece era activ anterior? Împărtășește-ți experiența în comentariile de mai jos.
