XML-RPC-ի ներածություն: Ծրագրավորման մրցույթներ Ինչ է տեսանելի սերվերի տեղեկամատյաններում

Նրա գրառումը նաև ցույց է տալիս, թե ինչպես կատարել բրաուզերի նույնականացում, ինչպես ստորև.
$request = xmlrpc_encode_request ("methodName" , array("methodParam"));
$auth = base64_encode ($username . ":" . $password );
$header = (version_compare(phpversion(), «5.2.8»))
? array("Content-Type. text/xml" , "Authorization: Basic $auth" )
: «Content-Type. text/xml\r\nԹույլտվություն՝ Հիմնական$auth "; //
$context = stream_context_create (զանգված ("http" => զանգված(
"method" => "POST" ,
"header" => $header ,
"content" => $խնդրանք
)));
$վեբ ծառայություն = «http://www.example.com/rpc»;
$file = file_get_contents ($webservice, false, $context);
$response = xmlrpc_decode ($ file);
եթե (xmlrpc_is_fault ($response)) (
վերադարձնել "xmlrpc: $response [faultString] ($response [faultCode])" ;
) ուրիշ (
վերադարձ $response ;
}
?>
1 - ԽՄԲԱԳՐԻ ԾԱՆՈՒՑՈՒՄ. ՍԱ «SandersWang dt php at gmail dot com»-ի շտկում է:

16 տարի առաջ

Երկուական տողերը (սահմանված են xmlrpc_set_type-ով) մտնում են a ...արգելափակել այնպես, ինչպես դուք սպասում էիք: Բայց յուրաքանչյուր 80-րդ նիշից հետո այս ֆունկցիան տեղադրում է XML էությունը « », որը Unicode-ի նոր տող է, կարծես տողերի փաթաթում առաջացնելով, ինչը, անշուշտ, հիմար է:

Թեև հիմար է, այն իրական խնդիրներ է առաջացնում որոշ XML-RPC սերվերների համար, ինչպիսիք են http://jakarta.apache.org/xmlrpc/ (ծնվ. Helma): Հեռացնելով այդ սուբյեկտները նման բանով

$req = preg_replace ("/ /", "", xmlrpc_encode_request ("my.method", $args));

աշխատում է խնդրի շուրջ:

11 տարի առաջ

Պետք է նշել, որ կոդավորումը կարծես ոչինչ չի կոդավորում, պարզապես նշեք, թե ինչ է մտնում XML վերնագրի մեջ:

Մենք խնդիրներ ունեցանք կրկնակի կոդավորված UTF տողերի հետ, որոնք պահվում էին տվյալների բազայում այս ֆունկցիան օգտագործելիս, այն ուղարկելով apache xml-rpc սերվերլետին և այն պահելու mysql տվյալների բազայում: Այն լուծվեց՝ «փախչելը» դնելով պարզապես «նշման», իսկ «կոդավորումը»՝ «UTF-8» (մի մոռացեք սահմանել «utf-8»-ը նաև xmlrpc_decode-ում):

Թվում է, թե UTF-8 կոդավորված տողերը դուրս են գալիս իրենց բայթերով որպես սուբյեկտներ՝ իրենց նիշերի փոխարեն:

9 տարի առաջ

Երբևէ փորձել եք փոխանցել հետևյալ զանգվածը xmlrpc-ով:
$var1=զանգված (7=>14,9=>18);

Ելքային զանգվածը միանգամայն տարբեր տեսք ունի: Այն նման տեսք կունենա.
$var2=զանգված (14,18);

Միակ լուծումը, որը ես գտա, ինդեքսի վրա բացատ տեղադրելն է.
$var3=array(" 7"=>14," 9"=>18);

Օգտագործելով այդ մեթոդը, դուք կստանաք ճիշտ արդյունք: ($var1)

16 տարի առաջ

Այս ֆունկցիան պետք է օգտագործվի XML-RPC հաճախորդի կողմից՝ XML-RPC հարցման համար XML օգտակար բեռ ստեղծելու համար.

$params = "system.methodSignature" ;
$method = "system.methodHelp" ;
$խնդրանք = xmlrpc_encode_request ($method, $params);
արձագանք ($խնդրանք);
?>

Արտադրում է;

system.methodHelp

system.methodՍտորագրություն

Երկրորդ արգումենտը ճանաչում է փոփոխականի տեսակը և ստեղծում է ճիշտ XML-RPC կառուցվածքը: Լրացուցիչ մանրամասների համար տես xmlrpc_encode().

12 տարի առաջ

Պարզ OO հաճախորդ գերբեռնված գործառույթով.

php մեթոդը test_helloworld թարգմանվում է xmlrpc մեթոդի test.helloworld:

դասի RpcClient (

մասնավոր $_methods;
մասնավոր $_context;
անձնական $_url;

Գործառույթ __construct ($url, $user, $passwd) (
$auth = base64_encode(sprintf("%s:%s", $user,$passwd));
$this->_context = stream_context_create(զանգված(
"http" => զանգված (
"method" => "POST",
"header" => "Content-Type. text/xml\r\n".
«Թույլտվություն. Հիմնական $auth» ,

)
));
$this->_url = $url;

$this->registerMethod("Test_HelloWorld");

Գործառույթ __call ($methodName, $params) (
if (array_key_exists ($methodName,$this->_methods)) (
// appelle la fonction RPC-ում
$m = str_replace ("_", ".", $methodName);
$r = xmlrpc_encode_request ($m, $params,array("verbosity"=>"newlines_nly"));
$c = $this->_context;
stream_context_set_option ($c,"http","բովանդակություն",$r);
$f = file_get_contents ($this->_url,false,$c);
$resp = xmlrpc_decode ($f);
վերադարձ $resp;
) ուրիշ (
// appelle la fonction de l"objet
call_user_method_array ($methodName, $this,$params);
}
}

Մասնավոր ֆունկցիա registerMethod ($method) (
$this->_methods[$method] = ճշմարիտ;
}

XML-RPC-ի ներածություն

Ինտերնետում կան բազմաթիվ տարբեր ռեսուրսներ, որոնք օգտվողներին տրամադրում են որոշակի տեղեկատվություն: Սա չի նշանակում սովորական ստատիկ էջեր, այլ, օրինակ, տվյալների բազայից կամ արխիվներից վերցված տվյալներ։ Սա կարող է լինել ֆինանսական տվյալների արխիվ (փոխարժեքներ, արժեթղթերի գնանշման տվյալներ), եղանակային տվյալներ կամ ավելի ծավալուն տեղեկատվություն՝ նորություններ, հոդվածներ, հաղորդագրություններ ֆորումներից: Նման տեղեկատվությունը կարող է ներկայացվել էջի այցելուին, օրինակ՝ ձևաթղթի միջոցով, որպես հարցման պատասխան կամ ամեն անգամ այն ​​կարող է գեներացվել դինամիկ կերպով։ Բայց դժվարությունն այն է, որ հաճախ նման տեղեկատվությունն անհրաժեշտ է ոչ այնքան վերջնական օգտագործողին` անձին, որքան այլ համակարգերին և ծրագրերին, որոնք կօգտագործեն այդ տվյալները իրենց հաշվարկների կամ այլ կարիքների համար:

Իրական օրինակ՝ բանկային կայքի էջ, որը ցուցադրում է արժույթի գնանշումներ: Եթե ​​դուք մուտք եք գործում էջ որպես սովորական օգտատեր, բրաուզերի միջոցով դուք տեսնում եք էջի ամբողջ դիզայնը, բաններները, մենյուները և այլ տեղեկություններ, որոնք «շրջանակում են» որոնման իրական նպատակը՝ արժույթի գնանշումները: Եթե ​​Ձեզ անհրաժեշտ է մուտքագրել այս գնանշումները ձեր առցանց խանութում, ապա այլ բան չի մնում անել, քան ձեռքով ընտրել անհրաժեշտ տվյալները և փոխանցել դրանք ձեր կայք՝ սեղմատախտակի միջոցով: Եվ դուք ստիպված կլինեք դա անել ամեն օր: Իսկապես ելք չկա՞։

Եթե ​​դուք խնդիրը լուծեք առհասարակ, ապա անմիջապես լուծում է ծագում. ծրագիր (սկրիպտը կայքում), որը տվյալների կարիք ունի, սերվերից էջ է ստանում որպես «սովորական օգտվող», վերլուծում (վերլուծում) ստացված html կոդը և հանում անհրաժեշտ տեղեկատվություն դրանից։ Դա կարելի է անել կամ սովորական կանոնավոր արտահայտությամբ, կամ օգտագործելով ցանկացած html վերլուծիչ: Մոտեցման դժվարությունը կայանում է նրա անարդյունավետության մեջ: Նախ, տվյալների փոքր մասը ստանալու համար (արժույթի տվյալները բառացիորեն մեկ տասնյակ կամ երկու նիշ են), դուք պետք է ստանաք ամբողջ էջը, որը առնվազն մի քանի տասնյակ կիլոբայթ է: Երկրորդ, էջի կոդի ցանկացած փոփոխության դեպքում, օրինակ, դիզայնը փոխվել է կամ այլ բան, մեր վերլուծության ալգորիթմը պետք է վերանայվի: Եվ սա կպահանջի բավականաչափ ռեսուրսներ:

Հետևաբար, մշակողները եկան որոշման. անհրաժեշտ է մշակել մի տեսակ ունիվերսալ մեխանիզմ, որը թույլ կտա թափանցիկ (արձանագրության և փոխանցման միջին մակարդակում) և տվյալների հեշտ փոխանակում ծրագրերի միջև, որոնք կարող են տեղակայվել ցանկացած վայրում, գրվել ցանկացած լեզվով: և գործարկվում է ցանկացած օպերացիոն համակարգի, համակարգերի և ցանկացած ապարատային հարթակի վրա: Նման մեխանիզմն այժմ կոչվում է բարձրաձայն «Վեբ ծառայություններ», «SOAP», «ծառայության վրա հիմնված ճարտարապետություն»: Տվյալների փոխանակման համար օգտագործվում են բաց և ժամանակի փորձարկված ստանդարտներ - HTTP արձանագրությունն օգտագործվում է հաղորդագրություններ փոխանցելու համար (թեև կարող են օգտագործվել այլ արձանագրություններ, օրինակ՝ SMTP): Տվյալներն ինքնին (մեր օրինակում՝ փոխարժեքները) փոխանցվում են փաթեթավորված միջպլատֆորմային ձևաչափով՝ XML փաստաթղթերի տեսքով: Այդ նպատակով հորինվել է հատուկ ստանդարտ՝ SOAP:

Այո, այժմ վեբ ծառայությունները, SOAP-ը և XML-ը բոլորի շուրթերին են, դրանք սկսում են ակտիվորեն ներդրվել, և խոշոր կորպորացիաները, ինչպիսիք են IBM-ը և Microsoft-ը, թողարկում են նոր ապրանքներ, որոնք նախատեսված են վեբ ծառայությունների ամբողջական իրականացման համար:

Բայց! Փոխարժեքների մեր օրինակի համար, որը պետք է փոխանցվի բանկի կայքից առցանց խանութի շարժիչին, նման լուծումը շատ դժվար կլինի: Ի վերջո, միայն SOAP ստանդարտի նկարագրությունը անպարկեշտ է մեկուկես հազար էջ, և դա դեռ ամենը չէ: Գործնական օգտագործման համար դուք նաև պետք է սովորեք, թե ինչպես աշխատել երրորդ կողմի գրադարանների և ընդլայնումների հետ (սկսած PHP 5.0-ից այն ներառում է գրադարան SOAP-ի հետ աշխատելու համար) և գրել ձեր սեփական կոդերի հարյուրավոր և հազարավոր տողեր: Եվ այս ամենը մի քանի տառ ու թվեր ստանալու համար ակնհայտորեն շատ ծանր ու իռացիոնալ է։

Ուստի տեղեկատվության փոխանակման մեկ այլ, կարելի է ասել, այլընտրանքային ստանդարտ կա՝ XML-RPC: Այն մշակվել է Microsoft-ի մասնակցությամբ UserLand Software Inc-ի կողմից և նախատեսված է ինտերնետի միջոցով հավելվածների միջև տվյալների միասնական փոխանցման համար: Այն կարող է փոխարինել SOAP-ին պարզ ծառայություններ կառուցելիս, որտեղ իրական վեբ ծառայությունների բոլոր «ձեռնարկությունների» հնարավորություններն անհրաժեշտ չեն:

Ի՞նչ է նշանակում XML-RPC հապավումը: RPC-ն նշանակում է Remote Procedure Call: Սա նշանակում է, որ հավելվածը (լինի սկրիպտը սերվերի վրա, թե սովորական հավելված հաճախորդի համակարգչի վրա) կարող է թափանցիկ կերպով օգտագործել մեթոդ, որը ֆիզիկապես ներդրված և գործարկված է մեկ այլ համակարգչի վրա: XML-ն այստեղ օգտագործվում է փոխանցված տվյալների նկարագրության ունիվերսալ ձևաչափ տրամադրելու համար: Որպես փոխադրամիջոց՝ HTTP արձանագրությունն օգտագործվում է հաղորդագրություններ փոխանցելու համար, որը թույլ է տալիս անխափան կերպով տվյալներ փոխանակել ցանկացած ցանցային սարքերի միջոցով՝ երթուղիչներ, firewalls, պրոքսի սերվերներ:

Եվ այսպես, օգտագործելու համար դուք պետք է ունենաք՝ XML-RPC սերվեր, որն ապահովում է մեկ կամ մի քանի մեթոդ, XML-RPC հաճախորդ, որը կարող է ճիշտ հարցում առաջացնել և մշակել սերվերի պատասխանը, ինչպես նաև իմանալ հաջող աշխատանքի համար անհրաժեշտ սերվերի պարամետրերը. հասցեն, մեթոդի անվանումը և անցած պարամետրերը:

XML-RPC-ի հետ ամբողջ աշխատանքը տեղի է ունենում «հարցում-պատասխան» ռեժիմում, սա տեխնոլոգիայի և SOAP ստանդարտի տարբերություններից մեկն է, որտեղ կան և՛ գործարքների հասկացությունները, և՛ հետաձգված զանգեր կատարելու հնարավորությունը (երբ սերվերը պահպանում է: հարցումը և պատասխանում է դրան ապագայում որոշակի ժամանակ): Այս լրացուցիչ հնարավորություններն ավելի օգտակար են հզոր կորպորատիվ ծառայությունների համար, դրանք զգալիորեն բարդացնում են սերվերների մշակումն ու աջակցությունը և լրացուցիչ պահանջներ են դնում հաճախորդների լուծումներ մշակողների վրա:

XML-RPC-ի հետ աշխատելու ընթացակարգը սկսվում է հարցում ձևավորելուց: Տիպիկ հարցումն այսպիսի տեսք ունի.

POST / RPC2 HTTP / 1.0
Օգտագործող-գործակալ՝ eshop-test/1.1.1 (FreeBSD)
Հյուրընկալող՝ server.localnet.com
Բովանդակություն-Տեսակ՝ տեքստ/xml
Բովանդակություն՝ 172

Փորձարկման մեթոդ
Բարև XML-RPC:

Առաջին տողերը կազմում են ստանդարտ HTTP POST հարցման վերնագիրը: Պահանջվող պարամետրերը ներառում են հոսթ, տվյալների տեսակը (MIME տեսակ), որը պետք է լինի տեքստ/xml և հաղորդագրության երկարությունը: Ստանդարտը նաև սահմանում է, որ User-Agent դաշտը պետք է լրացվի, բայց կարող է պարունակել կամայական արժեք:

Հաջորդը գալիս է XML փաստաթղթի սովորական վերնագիրը: Հարցման արմատային տարրն է , կարող է լինել միայն մեկը, և չի կարող պարունակել այնպիսի հանգույցներ, ինչպիսիք են երեխաները: Սա նշանակում է, որ մեկ հարցումը կարող է զանգահարել միայն մեկ մեթոդ սերվերի վրա:

Գիծ Փորձարկման մեթոդցույց է տալիս, որ մենք կանչում ենք TestMetod անունով մեթոդ: Անհրաժեշտության դեպքում այստեղ կարող եք նշել մեթոդը պարունակող ծրագրի կամ մոդուլի անվանումը, ինչպես նաև դրան տանող ուղին։ XML-RPC հստակեցումը, թեև այն սահմանում է որոշ սահմանափակումներ նիշերի հավաքածուի վրա, որոնք կարող են օգտագործվել մեթոդը նշելու համար, սակայն, թե ինչպես դրանք մեկնաբանել, ամբողջովին կախված է սերվերի իրականացումից:

Հաջորդը, փոխանցված պարամետրերը սահմանվում են: Այս բաժինը օգտագործվում է դրա համար: Որը կարող է պարունակել կամայական թվով ենթատարրեր Որոնք պարունակում են պիտակի նկարագրած պարամետրը . Մենք մի փոքր ավելի ուշ կանդրադառնանք պարամետրերին և տվյալների տեսակներին: Մեր տարբերակում մեթոդին փոխանցվում է պիտակի մեջ փակցված մեկ տողային պարամետր .

Բոլոր պարամետրերի նկարագրությանը հաջորդում են փակման պիտակները: XML-RPC-ում հարցումն ու պատասխանը սովորական XML փաստաթղթեր են, ուստի բոլոր պիտակները պետք է փակվեն: Բայց XML-RPC-ում առանձին պիտակներ չկան, թեև դրանք առկա են XML ստանդարտում:

Հիմա եկեք նայենք սերվերի պատասխանին: HTTP պատասխանի վերնագիրը նորմալ է, եթե հարցումը հաջողությամբ մշակվի, սերվերը վերադարձնում է HTTP/1.1 200 OK պատասխան: Ինչպես հարցումում, դուք պետք է ճիշտ նշեք MIME-ի տեսակը, հաղորդագրության տևողությունը և պատասխանի ստեղծման ամսաթիվը:

Ինքն արձագանքման մարմինը հետևյալն է.

ճիշտ

Հիմա արմատային պիտակի փոխարեն պիտակը նշված է , որն անմիջապես պարունակում է հարցումների մշակման արդյունքները։ Ցավոք, պատասխանը չի փոխանցում մեթոդի անունը, այնպես որ դուք պետք է այն պահեք հաճախորդի կողմից՝ խառնաշփոթությունից խուսափելու համար, եթե միաժամանակ տարբեր մեթոդներ կանչվեն:

Եթե ​​ձեր հարցումը մշակելիս սխալ է տեղի ունեցել, փոխարենը Պատասխանը կպարունակի տարրը , որի մեջ կտեղադրվի սխալը նկարագրող կառույց։ Սխալի նկարագրությունը պարունակում է թվային սխալի կոդ և տեքստային նկարագրություն:

Այժմ եկեք համառոտ նայենք XML-RPC-ում տվյալների տեսակներին: Ընդհանուր առմամբ կա տվյալների 9 տեսակ՝ յոթ պարզ և 2 բարդ: Յուրաքանչյուր տեսակ նկարագրվում է իր սեփական պիտակով կամ պիտակների հավաքածուով (բարդ տեսակների համար):

Պարզ տեսակներ.

Ամբողջ թվեր- պիտակ կամ ;

Բուլյան տեսակ- պիտակ , կարող է վերցնել և՛ 0/1, և՛ true/false արժեքները;

ASCII տող- նկարագրված է պիտակով և կարող է պարունակել նիշերի կամայական տող;

Լողացող կետով թվեր- պիտակ , կարող է պարունակել նաև թվային նշան, կոտորակային մասը բաժանված է կետով;

ամսաթիվը և ժամը- նկարագրված է պիտակով և պետք է համապատասխանի iso8601 ձևաչափին: Սկրիպտներում հետագա մշակման համար այս ձևաչափը մի փոքր անհարմար է, ուստի այն միշտ փոխակերպվում է հարցում ուղարկելու/ստանալու ժամանակ։ Դա կարելի է անել գրադարանի ներսում գտնվող հատուկ գործառույթի միջոցով, կամ, եթե չկա, մշակողը պետք է ձեռքով փոխակերպի ամսաթիվը:

Վերջին պարզ տեսակն է base64 կոդավորված տող, որը նկարագրված է պիտակով . Այս տեսակը ունիվերսալ է, այն կարող է օգտագործվել հաճախորդի և սերվերի միջև ցանկացած տվյալ փոխանցելու համար, թեև փոխանցված տվյալների ծավալը մեծանում է նման կոդավորման պատճառով: Բայց սա արձանագրության և մասնավորապես XML ձևաչափի տեքստային բնույթի հետևանք է։

Կոմպլեքս տեսակները ներկայացված են կառուցվածքներով և զանգվածներով։ Կառուցվածքը որոշվում է արմատային տարրով , որը կարող է պարունակել կամայական թվով տարրեր , սահմանելով կառույցի յուրաքանչյուր անդամ։ Կառույցի անդամը նկարագրվում է երկու պիտակներով. , նկարագրում է անդամի անունը, երկրորդ, , պարունակում է անդամի արժեքը (տվյալների տեսակը նկարագրող պիտակի հետ միասին)։

Զանգվածները անուններ չունեն և նկարագրվում են պիտակով որը պարունակում է մեկ տարր , և մեկ կամ մի քանի երեխա տարրեր , որտեղ նշված են կոնկրետ տվյալներ։ Զանգվածը կարող է պարունակել ցանկացած այլ տիպ՝ ցանկացած հերթականությամբ, ինչպես նաև այլ զանգվածներ, ինչը թույլ է տալիս նկարագրել բազմաչափ զանգվածներ։ Կարող եք նաև նկարագրել կառուցվածքների մի շարք: Բայց այն փաստը, որ զանգվածը անուն չունի, որոշ դեպքերում բարդացնում է դրա օգտագործումը. բարդ տվյալներ փոխանցելու համար դրանք պետք է բազմիցս փաթեթավորվեն այլ տեսակների մեջ (օրինակ, մի քանի զանգված փոխանցելու համար կարող եք յուրաքանչյուր զանգված առանձին փաթեթավորել կառուցվածքի մեջ։ , և այնուհետև ստեղծեք մեկ զանգված այս կառույցներից):

Իհարկե, ինչ-որ մեկը կասի, որ տվյալների տեսակների նման ցանկը շատ վատ է և «թույլ չի տալիս ընդլայնել»: Այո, եթե Ձեզ անհրաժեշտ է բարդ օբյեկտներ կամ մեծ քանակությամբ տվյալներ փոխանցել, ապա ավելի լավ է օգտագործել SOAP-ը: Իսկ փոքր, ոչ պահանջկոտ հավելվածների համար XML-RPC-ն բավականին հարմար է, ավելին, շատ հաճախ նույնիսկ նրա հնարավորությունները չափազանց շատ են ստացվում: Հաշվի առնելով տեղակայման հեշտությունը, գրադարանների շատ մեծ քանակությունը գրեթե ցանկացած լեզվի և հարթակի համար, ինչպես նաև PHP-ի լայն աջակցությունը, ապա XML-RPC-ն հաճախ պարզապես մրցակիցներ չունի: Չնայած այն չի կարող անմիջապես առաջարկվել որպես ունիվերսալ լուծում, յուրաքանչյուր կոնկրետ դեպքում այն ​​պետք է որոշվի ըստ հանգամանքների:

XML-RPC տեխնոլոգիան օգտագործվում է WordPress համակարգում տարբեր գեղեցիկ հնարավորությունների համար, ինչպիսիք են pingbacks-ը, trackbacks-ը, կայքի հեռակառավարումը առանց ադմինիստրատորի վահանակ մուտք գործելու և այլն: Ցավոք, հարձակվողները կարող են օգտագործել այն կայքերի վրա DDoS հարձակումներ իրականացնելու համար: Այսինքն՝ դուք ստեղծում եք գեղեցիկ, հետաքրքիր WP նախագծեր ձեզ համար կամ պատվիրելու համար, և միևնույն ժամանակ, առանց որևէ բան կասկածելու, կարող եք լինել DDoS բոտնետի մաս։ Միացնելով տասնյակ և հարյուր հազարավոր կայքեր՝ վատ մարդիկ հզոր հարձակում են ստեղծում իրենց զոհի վրա: Թեև միաժամանակ տուժում է նաև ձեր կայքը, քանի որ... բեռը գնում է հոսթինգ, որտեղ այն գտնվում է:

Նման վատ գործունեության ապացույցը կարող է լինել սերվերի տեղեկամատյաններում (access.log in nginx), որը պարունակում է հետևյալ տողերը.

103.238.80.27 - - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"

Բայց եկեք վերադառնանք XML-RPC խոցելիությանը: Տեսողականորեն դա արտահայտվում է ձեր սերվերի վրա կայքերի դանդաղ բացմամբ կամ դրանք ընդհանրապես բեռնելու անկարողությամբ (502 Bad Gateway-ի սխալ): Իմ FASTVPS հաղորդավարի տեխնիկական աջակցությունը հաստատեց իմ ենթադրությունները և խորհուրդ տվեց.

1. Թարմացրեք WordPress-ը վերջին տարբերակին՝ հավելումների հետ միասին: Ընդհանուր առմամբ, եթե հետևեք, գուցե կարդացած լինեք վերջին 4.2.3-ը տեղադրելու անհրաժեշտության մասին: անվտանգության քննադատությունների պատճառով (ինչպես նախորդ տարբերակները): Մի խոսքով, լավ է թարմացնել:

1. Տեղադրեք Disable XML-RPC Pingback plugin-ը:

WordPress-ում XML-RPC-ի անջատում

Նախկինում ինձ թվում է, որ XML-RPC-ն միացնելու/անջատելու տարբերակը ինչ-որ տեղ կար համակարգի կարգավորումներում, բայց հիմա այնտեղ չեմ գտնում: Հետեւաբար, դրանից ազատվելու ամենահեշտ ձեւը համապատասխան պլագին օգտագործելն է։

Գտեք և ներբեռնեք Անջատել XML-RPC Pingback-ը կամ տեղադրել այն անմիջապես համակարգի ադմինիստրատորի վահանակից: Ձեզ հարկավոր չէ լրացուցիչ որևէ բան կարգավորել, մոդուլը անմիջապես սկսում է աշխատել: Այն հեռացնում է pingback.ping և pingback.extensions.getPingbacks մեթոդները XML-RPC ինտերֆեյսից: Բացի այդ, այն հեռացնում է X-Pingback-ը HTTP վերնագրերից:

Բլոգներից մեկում ես գտա ևս մի քանի տարբերակ XML-RPC անջատումը հեռացնելու համար:

1. Կաղապարում անջատեք XML-RPC-ն:

Դա անելու համար թեմայի functions.php ֆայլին ավելացրեք հետևյալ տողը.

Պատվիրեք մերժել, թույլ տվեք մերժել բոլորին

Անձամբ ես չեմ օգտագործել վերջին երկու մեթոդները, քանի որ... Ես միացրեցի Disable XML-RPC Pingback plugin-ը, կարծում եմ, դա բավարար կլինի: Պարզապես նրանց համար, ովքեր չեն սիրում ավելորդ տեղադրումներ, ես առաջարկեցի այլընտրանքային տարբերակներ:

Շաբաթ օրը կեսօրից սկսած, իմ սերվերը, որտեղ տեղակայված են Wordpress-ի մոտ 25 կայք, սկսեց զգալ կտրուկ դանդաղում: Քանի որ ես կարողացա գոյատևել նախորդ հարձակումներից ( , ) առանց նկատելու, ես անմիջապես չհասկացա, թե ինչ է կատարվում։

Երբ ես դա պարզեցի, պարզվեց, որ գաղտնաբառերը կոպիտ կերպով պարտադրվում էին + բազմաթիվ հարցումներ XMLRPC-ին:

Արդյունքում մեզ հաջողվեց կտրել այդ ամենը, թեև ոչ անմիջապես։ Ահա երեք պարզ հնարք, թե ինչպես խուսափել դրանից:

Այս տեխնիկան, ամենայն հավանականությամբ, հայտնի է բոլորին, բայց ես քայլ արեցի մի քանի սխալների վրա, որոնք ես չգտա նկարագրություններում, միգուցե դա ինչ-որ մեկին ժամանակ կխնայի:

1. Դադարեցրեք որոնումը, տեղադրեք Limit Login Attempts plugin-ը, տեղադրեք այն, քանի որ մյուս պաշտպանությունները մեծապես դանդաղեցնում են սերվերը, օրինակ՝ Login Security Solution plugin-ն օգտագործելիս սերվերը մահացել է կես ժամ հետո, plugin-ը մեծապես բեռնում է տվյալների բազան։ .

Կարգավորումներում համոզվեք, որ միացրեք «For proxy» վանդակը, հակառակ դեպքում այն ​​կորոշի ձեր սերվերի IP-ն բոլորի համար և ավտոմատ կերպով կարգելափակի բոլորին:
ԹԱՐՄԱՑՆԵԼ, շնորհակալություն, մանրամասները ներքևում են մեկնաբանություններում. միացրեք «Վստահված անձի համար» վանդակը միայն այն դեպքում, եթե սահմանումը չի գործում, երբ «Ուղիղ կապը» միացված է:

2. Անջատել XML-RPC - Անջատել XML-RPC հավելվածը (հեշտ է ակտիվացնել և վերջ):

3. Փակեք wp-login.php - եթե դուք մուտք եք գործում կայք IP-ի միջոցով, ապա plugin-ը չի աշխատում, և ընտրողները շարունակում են խափանել կայքը: Դրանից խուսափելու համար ավելացրեք .htaccess-ին.

Պատվիրեք մերժել, թույլ տվեք մերժել բոլորին

Մենք պատճենում ենք wp-login ֆայլը, այն վերանվանում ենք որևէ տարօրինակ անունով, օրինակ՝ poletnormalny.php, և ֆայլի ներսում օգտագործում ենք autocorrect՝ բոլոր wp-login.php մակագրությունները փոխելու poletnormalny.php:
Վերջ, այժմ դուք կարող եք մուտք գործել ադմինիստրատորի վահանակ միայն ձեր ֆայլի միջոցով:

Այս 3 պարզ քայլերից հետո կայքերը նորից սկսեցին թռչել, և խաղաղություն եկավ:

Դե, հանկարծ հետաքրքիր է

Տարբերակներից մեկն այն է, որ տեսնեք, թե արդյոք ձեր վրա հարձակվում են: Սա կարելի է տեսնել nginx տեղեկամատյաններում (օրինակ, ահա Debian /var/log/nginx access.log ֆայլի ուղին):

WordPress-ը միշտ ունեցել է ներկառուցված գործիք՝ ձեր կայք հեռակա մուտք գործելու համար: Իրոք, երբեմն ձեզ անհրաժեշտ է հասնել ձեր կայք, բայց ձեր համակարգիչը հեռու է ձեզանից: Երկար ժամանակ լուծումը xmlrpc.php կոչվող ֆայլն էր։ Այնուամենայնիվ, վերջին տարիներին այս ֆայլը դարձել է ավելի շատ խնդիր, քան լուծում:

Ստորև մենք ավելի մանրամասն կանդրադառնանք xmlrpc.php-ին և ինչու է այն ստեղծվել: Մենք նաև կանդրադառնանք անվտանգության ընդհանուր խնդիրներին, որոնք դա կարող է առաջացնել և ինչպես դրանք շտկել ձեր WordPress կայքի համար:

XML-RPC-ն WordPress-ի հատկություն է, որը թույլ է տալիս տվյալների փոխանցում՝ HTTP-ով ծառայում է որպես փոխադրամիջոց, իսկ XML՝ կոդավորման համար: Քանի որ WordPress-ը փակ համակարգ չէ և հաճախ շփվում է այլ համակարգերի հետ, այս խնդրի համար լուծումներ են գտնվել։

Օրինակ, ենթադրենք, որ ցանկանում եք տեղադրել ձեր կայքում ձեր բջջային հեռախոսից: Դուք պետք է օգտագործեք xmlrpc.php-ի կողմից տրամադրված հեռավոր մուտքը:

Xmlrpc.php-ի հիմնական ֆունկցիոնալությունը սմարթֆոնից կայքին միանալու հնարավորությունն է, այլ կայքերից հետքեր և հղումների իրականացում և Jetpack plugin-ի հետ կապված որոշ գործառույթներ:

Ինչու՞ է ստեղծվել Xmlrpc.php-ը և ինչպես է այն օգտագործվել:

XML-RPC-ի իրականացումը հետ է մղվում WordPress-ի վաղ օրերից և նույնիսկ մինչ WordPress-ը դարձել է WordPress:

Դեռևս ինտերնետի սկզբնական շրջանում կապերը շատ դանդաղ էին, և համացանցում ձայնագրման և հրապարակման գործընթացը շատ ավելի դժվար և ժամանակատար էր: Անմիջապես բրաուզերի միջոցով փոփոխություններ անելու փոխարեն, մեծամասնությունը դրանք դարձրեց անցանց, այնուհետև պատճենեց և տեղադրեց դրանց բովանդակությունը առցանց: Եվ այս գործընթացը հեռու էր իդեալական լինելուց։

Լուծումը (այն ժամանակ) եղել է օֆլայն բլոգերի հաճախորդ ստեղծելը, որտեղ դուք կարող եք կազմել ձեր բովանդակությունը, այնուհետև միանալ ձեր բլոգին և հրապարակել այն: Այս կապը կատարվել է XML-RPC-ի միջոցով: Հիմնական XML-RPC ֆունկցիոնալությամբ, այս կապերն օգտագործող վաղ հավելվածները մարդկանց հնարավորություն տվեցին մուտք գործել իրենց WordPress կայքեր այլ սարքերից:

XML-RPC այսօր

2008 թվականին WordPress-ի 2.6 տարբերակով ներկայացվեց XML-RPC-ն միացնելու կամ անջատելու տարբերակ։ Այնուամենայնիվ, WordPress iPhone հավելվածի թողարկմամբ XML-RPC աջակցությունը լռելյայն միացված էր, և այն անջատելու տարբերակ չկար: Այդպես է մնում այսօր։

Իհարկե, այս ֆայլի տրամադրած ֆունկցիոնալությունը ժամանակի ընթացքում զգալիորեն նվազել է, իսկ ֆայլի չափը 83կբ-ից նվազել է մինչև 3կբ, այն այլևս նախկինի նման դեր չի խաղում։

XML-RPC հատկություններ

Նոր WordPress հավելվածի ծրագրավորման ինտերֆեյսի (API) միջոցով մենք կարող ենք ակնկալել, որ XML-RPC-ն ամբողջությամբ անջատված կլինի: Այսօր այս նոր API-ն դեռ փորձարկման փուլում է և կարող է միացվել միայն հատուկ փլագինի միջոցով:

Թեև դուք կարող եք ակնկալել, որ API-ն ապագայում կներառվի անմիջապես WordPress-ի առանցքում՝ ամբողջությամբ վերացնելով xmlrpc.php-ի անհրաժեշտությունը:

Նոր API-ն կատարյալ չէ, բայց այն ապահովում է լավ, հուսալի անվտանգություն՝ ի տարբերություն xmlrpc.php-ի:

Ինչու անջատել Xmlrpc.php-ը

XML-RPC-ի ամենամեծ խնդիրը անվտանգությունն է: Խնդիրն ուղղակիորեն կապված չէ XML-RPC-ի հետ, բայց այն կարող է օգտագործվել ձեր կայքի վրա հարձակումը միացնելու համար:

Իհարկե, դուք կարող եք պաշտպանվել ձեզ շատ ուժեղ գաղտնաբառով և WordPress-ի անվտանգության պլագիններով: Սակայն պաշտպանության լավագույն ռեժիմը պարզապես անջատելն է:

XML-RPC-ի երկու հիմնական թույլ կողմեր ​​կան, որոնք նախկինում օգտագործվել են:

Առաջինն օգտագործում է կոպիտ ուժային հարձակումներ՝ ձեր կայք մուտք գործելու համար: Հարձակվողը կփորձի մուտք գործել ձեր կայք xmlrpc.php-ի միջոցով՝ փորձելով օգտանունների և գաղտնաբառերի տարբեր համակցություններ: Նրանք կարող են արդյունավետորեն օգտագործել մեկ հրաման՝ հարյուրավոր տարբեր գաղտնաբառեր փորձարկելու համար: Սա նրանց թույլ է տալիս շրջանցել անվտանգության գործիքները, որոնք սովորաբար հայտնաբերում և արգելափակում են դաժան ուժի հարձակումները:

Երկրորդը՝ DDoS հարձակման միջոցով կայքը դուրս հանելն է: Հաքերները կօգտագործեն հակադարձ ծանուցումը WordPress-ում՝ այն միաժամանակ հազարավոր կայքեր ուղարկելու համար: Այս xmlrpc.php ֆունկցիոնալությունը հաքերներին տալիս է գրեթե անսահման թվով IP հասցեներ՝ DDoS հարձակումը տարածելու համար:

Ստուգելու համար, թե արդյոք XML-RPC-ն աշխատում է ձեր կայքում, կարող եք այն գործարկել՝ օգտագործելով XML-RPC Validator կոչվող գործիքը: Գործարկեք ձեր կայքը գործիքի միջոցով, և եթե սխալ եք ստանում, դա նշանակում է, որ դուք չունեք XML-RPC աջակցություն:

Եթե ​​հաջողության հաղորդագրություն եք ստանում, կարող եք դադարեցնել xmlrpc.php-ը՝ օգտագործելով ստորև նշված երկու մոտեցումներից մեկը:

Մեթոդ 1. Անջատել Xmlrpc.php-ը՝ օգտագործելով plugin

Ձեր WordPress կայքում XML-RPC-ն անջատելը աներևակայելի հեշտ է:

Գնացեք բաժին Փլագիններ › Ավելացնել նորձեր WordPress ադմինիստրատորի վահանակում: Գտեք հավելված Անջատել XML-RPC-նև տեղադրեք այն, կարծես ստորև ներկայացված նկարը.

Ակտիվացրեք plugin-ը և վերջ: Այս փլագինը ավտոմատ կերպով կտեղադրի անհրաժեշտ կոդը՝ XML-RPC-ն անջատելու համար:

Այնուամենայնիվ, հիշեք, որ տեղադրված փլագինները կարող են օգտագործել XML-RPC-ի մասեր, և այն անջատելը կարող է կոնֆլիկտ առաջացնել փլագինների կամ դրանց առանձին մասերի միջև և դրանք դուրս բերել աշխատանքային ռեժիմից:

Եթե ​​ցանկանում եք անջատել միայն առանձին XML-RPC տարրերը, բայց թույլ տալ, որ այլ պլագիններ և գործառույթներ աշխատեն, ապա նայեք հետևյալ փլագիններին.

• Դադարեցրեք XML-RPC հարձակումը: Այս փլագինը կդադարեցնի բոլոր XML-RPC հարձակումները, բայց այն թույլ կտա փլագիններին, ինչպիսիք են Jetpack-ը և այլ ավտոմատացված գործիքներն ու պլագինները, շարունակել գործարկել՝ թույլ տալով նրանց մուտք գործել xmlrpc.php ֆայլեր:
• Վերահսկել XML-RPC հրատարակությունը: Սա թույլ է տալիս պահպանել վերահսկողությունը և հրապարակել հեռակա կարգով:

Մեթոդ 2. Ձեռքով անջատել Xmlrpc.php-ը

Եթե ​​դուք չեք ցանկանում օգտագործել plugin և նախընտրում եք դա անել ձեռքով, հետևեք այս մոտեցմանը: Այն կդադարեցնի բոլոր մուտքային xmlrpc.php հարցումները՝ նախքան WordPress-ին փոխանցելը:

Բացեք .htaccess ֆայլը: Այս ֆայլը գտնելու համար գուցե ստիպված լինեք միացնել «ցույց տալ թաքնված ֆայլերը» ձեր ֆայլերի կառավարիչում կամ FTP հաճախորդում:

Տեղադրեք այս կոդը ֆայլի մեջ .htaccess:

# Արգելափակել WordPress xmlrpc.php հարցումները պատվիրել մերժել, թույլատրել մերժել բոլոր թույլտվություններից 123.123.123.123-ից

Վերջնական մտքեր

Ընդհանուր առմամբ, XML-RPC-ն ամուր լուծում էր որոշ խնդիրների համար, որոնք առաջացել էին ձեր WordPress կայքում հեռակա հրապարակման հետ: Այնուամենայնիվ, միևնույն ժամանակ ի հայտ եկան անվտանգության որոշ անցքեր, որոնք բավականին վտանգավոր էին WordPress կայքերի որոշ սեփականատերերի համար։

Ձեր կայքը անվտանգ պահելու համար խորհուրդ է տրվում ամբողջությամբ անջատել xmlrpc.php-ը, եթե ձեզ անհրաժեշտ չեն որոշ գործառույթներ, որոնք պահանջվում են հեռակա հրապարակման և Jetpack հավելվածի համար: Այնուհետև կարող եք օգտագործել լուծումներ, որոնք թույլ են տալիս օգտագործել այս հնարավորությունները անվտանգության անցքերը կարկատելիս:

Ժամանակի ընթացքում մենք կարող ենք ակնկալել, որ XML-RPC ֆունկցիոնալությունը ինտեգրվելու է նոր WordPress API-ին, որը կաջակցի հեռավոր մուտքին՝ առանց անվտանգության զոհաբերելու:

Դուք արգելափակե՞լ եք մուտքը XML-RPC հավելվածի միջոցով կամ ձեռքով: Թե՞ անվտանգության հետ կապված խնդիրներ կային, քանի որ այն նախկինում ակտիվ էր: Կիսվեք ձեր փորձով ստորև բերված մեկնաբանություններում: