Հավաստված հոստի կարգավորումներ

Այս փաստաթուղթը անհամակողմնորոշիչ է. Ստացեք ավելի շատ տեղեկություններ։

HTTP HOST Header հարձակումների պաշտպանություն (չթույլ տալ, որ ձեր կայքը մտածի, որ դա ուրիշն է)

Drupal 7-ը ներառեց նոր ֆունկցիա սյուրտում, որը նախատեսված չէ ուղղակի օգտագործողի հետ փոխազդման համար, բայց երբեմն կոչվում է poormanscron: Այս ֆունկցիան իրականացնում է կայքի պարբերական առաջադրանքներ, ինչպիսիք են լոգ ֆայլերի մաքրման, էլ․փոստերի ուղարկման և քեշերի մաքրման աշխատանքները: Այս ֆունկցիան՝ համակցված «հիմնական URL»-ի դինամիկ բացահայտման հետ (ավելացված է Drupal 4.7-ում), կարող է հանգեցնել տարօրինակ իրավիճակների: Այս հոդվածը նկարագրում է այդ տարօրինակ իրավիճակներից մի քանիսը, որոնք առաջանում են մոդուլների միաժամանակյա կամ առանձին օգտագործման դեպքում, և այն, թե ինչ կարող եք անել դրանց կանխարգելման համար։ Նշումները ներքևում ենթադրում են որոշակի կանխադրված կոնֆիգուրացիաներ՝ վերջում նշելով, թե ինչպես փոխել այդ կանխադրված պարամետրերը՝ խնդիրները կանխարգելելու համար։

Սցենար 1. Օգտագործողների էլեկտրոնային նամակների ստացում/ուղարկում՝ որոնք նախատեսված են այլ դոմենի համար

Այս վարքագիծը հեշտությամբ կրկնելի է՝

1. IP հասցեի միջոցով նշեք նոր դոմեն գոյություն ունեցող կայքի համար՝ կոչենք գոյություն ունեցող կայքը http://www.example.com, իսկ նոր անունը, որը ցույց է տալիս այդ IP հասցեին, կլինի http://other-site.example.org։

2. Այցելեք URL-ը՝ http://other-site.example.org/user/password

3. Մուտքագրեք օգտանուն, որը հավանաբար օգտագործվում է կայքում։

Արդյունքում՝ $base_url հայտնաբերումն այս քայլում կհամարարկի, որ ձեր կայքը http://other-site.example.org է, և բոլոր էլ․փոստի համար նախատեսված նշանները, օրինակ՝ [user: one-time-login-url], որոնք պարունակում են հղումներ ձեր կայքին, կփոխարինվեն այդ դոմենի հասցեով՝ որպես հիմնական URL։ Նույն էլեկտրոնային նամակը ստացող օգտատերը կտեսնի, որ իր օգտանունն ու էլփոստը example.com-ից ինչպես որ լինում էր, այժմ ինչ-որ կերպ օգտագործվում են http://other-site.example.org հասցեով, ինչը սովորաբար միայն շփոթեցնում է։ Սակայն դրանից կարող են առաջանալ երկու վատ սցենարներ.

• Առավել վատ տարբերակում՝ նրանք կարող են սեղմել գաղտնաբառի վերականգնման հղումը, որն անմիջապես օգտագործելի կլինի չարամիտ կայքի կողմից՝ այդ օգտատիրոջ անունով մտնելու համար։
• Նրանք կարող են մուտքագրել իրենց օգտանունն ու գաղտնաբառը http://other-site.example.org հասցեում՝ ինչ կոչվում է սոցիալական ինժեներիա, որը հետո կարող է օգտագործվել հիմնական կայքում։

Սցենար 2. Կեղծ դոմեն պարունակող գրառումների քեշավորում

Նույն խնդիրն առաջանում է, երբ օգտատերը սխալ դոմեն է օգտագործում հարցման համար, իսկ այդ հարցումը լրացնում է քեշի գրառում՝ դինամիկ և ամբողջական դոմեններով: Հաջորդ այցելությունները, որոնք կվերցնեն տվյալները այդ քեշից, կստանան սխալ դոմենի անուն։ Drupal 8-ի հիմնական քեշը օգտագործում է դոմենը որպես քեշի նույնականացուցիչ՝ կանխելու այդ խնդիրը, սակայն մյուս քեշավորման մեխանիզմները այդքան կայուն չեն այս խնդրի նկատմամբ։

Սցենար 3. Սխալ դոմեն պարունակող էլփոստային ծանուցումներ

Այն կայքերում, որոնք օգտագործում են մոդուլներ, որոնք cron-ի ընթացքում ուղարկում են էլփոստեր, կարող է առաջանալ այս խնդիրը։ Այս սցենարը պահանջում է poormanscron և դինամիկ base_url բացահայտում։ Եթե օգտատերը պատահաբար միանգամից գործարկում է poormanscron, երբ հերթում կան ծանուցումներ, բայց այցելում է սխալ դոմեն, այդ ծանուցումները կուղարկվեն սխալ դոմենով։ Օգտատերերը կշփոթվեն՝ տեսնելով, որ իրենց սպասվող էլփոստը example.com-ից պարունակում է հղումներ դեպի http://other-site.example.org։

Խափանումներ դինամիկ base_url բացահայտման հետ կապված

Կարող են լինել առնվազն չորս լուծումներ այս խնդրի համար, սակայն բոլորն էլ պարտադիր չեն բոլոր միջավայրերում։ Դուք պետք է ընտրեք և գործադրեք այն, որը համապատասխանում է ձեր միջավայրին։

1. Կարող եք սահմանել կոնկրետ դոմեն ձեր $base_url-ը նշելով sites/default/settings.php-ում։ Դինամիկ բացահայտումը կարող է օգտակար լինել, բայց կարող է նաև խնդիրներ առաջացնել։ Մեկ լուծում է կայուն արժեքի սահմանումը։

2. Օգտագործեք կոնկրետ sites/example.com/settings.php և թույլ տվեք, որ $base_url-ը բացահայտվի դինամիկ, այսինքն՝ Drupal-ը կպատասխանի example.com-ի բոլոր ենթադոմեններին, ինչը կարող է լինել կամ չլինել հարմար։

3. Կարգավորեք ձեր վեբ սերվերը այնպես, որ երբ մուտքագրվող հարցումը տարբերվի ձեր կայքի նախնական կոնֆիգուրացիայից, ցույց տա հիմնական էջ կամ սխալի էջ։

4. Կարգավորեք վեբ սերվերը, որպեսզի բոլոր հարցումները, որոնք չեն պատկանում համապատասխան դոմենին, ուղղորդվեն ճիշտ դոմենին։

Drupal 8-ում հավաստված հոստերի կարգավորումներ

2015 թվականի հունվարից Drupal 8-ն աջակցում է «հավաստված հոստերի ձևանմուշներին», որտեղ դուք կարող եք (և պետք է) նշել regex արտահայտությունների հավաքածու, որոնց պետք է համապատասխանի մուտքագրվող հարցման դոմենը։ settings.php-ում օրինակ՝

$settings['trusted_host_patterns'] = [
  '^www\.example\.com$',
];

Մանրամասների համար տես վերևում փոփոխությունների գրառումը։ Եթե դուք աշխատում եք տեղական միջավայրում, կարող եք (ժամանակավոր) արգելափակել ձեր կայքը այս կարգավորումներով։ Այդ դեպքում հարկավոր է ավելացնել նաև '^localhost$' հոստերի ձևանմուշը։

MAMP 3-ի համար հավաստված հոստի կարգավորումներ

Տեղական զարգացում օգտագործելիս MAMP 3.5.2-ում '^localhost$' կարգավորումը սխալ է տալիս՝ «Հյուրանունը այս սերվերի համար անթույլատրելի է» և կայքը չի բեռնում։ Հիմնավորում գտա՝ փոխելով ձևանմուշը՝ դոմենային անվանումով առանց պորտի։ Իմ փորձնական կայքը՝ "drupal8":

$settings['trusted_host_patterns'] = [
  '^drupal8$',
];

այսպես ակտիվացրեց հավաստված հոստը։

Նշում․ MAMP 4.2-ում '^localhost$' կարգավորումը աշխատում է առանց խնդիրների։

Acquia Dev Desktop 2-ի հավաստված հոստի կարգավորումներ (թեստավորված Drupal 8.6.2 և PHP 7.2.8)

Եթե օգտագործում եք Acquia Dev Desktop 2, փորձեք հետևյալ հոստի ձևանմուշը՝ փոխելով "sitename"-ը ձեր կայքի անվան վրա․

$settings['trusted_host_patterns'] = array(
  '^sitename\.dd$',
);

XAMPP-ի հավաստված հոստի կարգավորումներ (թեստավորված Drupal 8.4.0 և PHP 7.1.8)

Հավաստված հոստերի մեխանիզմը ներգործելու համար հարկավոր է ավելացնել թույլատրված հոստերը $settings['trusted_host_patterns']-ում։

Բացեք settings.php ֆայլը և թարմացրեք հետևյալ կոդը՝ հավաստված հոստի կարգավորումը ներառելու համար՝

$settings['trusted_host_patterns'] = [
  '^localhost$',                   
  '^192\.168\.00\.52$',
  '^127\.0\.0\.1$',
];

Այստեղ՝

• '^localhost$', թույլ է տալիս կայքը աշխատել միայն localhost-ով։
• '^192\.168\.00\.52$', թույլ է տալիս կայքը աշխատել միայն համակարգի IP հասցեով (տարբեր համակարգերի համար տարբեր IP հասցեներ)։
• '^127\.0\.0\.1$', թույլ է տալիս կայքը աշխատել 127.0.0.1 հասցեով՝ localhost-ի փոխարեն։

Նշում․ Մուլտիսայթ-համակարգում նշեք բոլոր հոստերի ձևանմուշները, որոնք թույլատրված են ձեր կայքի կողմից։

Lando-ի հավաստված հոստի կարգավորումներ (թեստավորված Drupal 8.7.10 և PHP 7.2)

Հավաստված հոստերի գործառույթը միացնելու համար հարկավոր է ներառել թույլատրելի հոստերը $settings['trusted_host_patterns']-ում։

Բացեք settings.php ֆայլը և թարմացրեք հետևյալ կոդը՝

$settings['trusted_host_patterns'] = [
  '^'.getenv('LANDO_APP_NAME').'\.lndo\.site$',   # lando proxy access
  '^localhost$',                                  # localhost access
  '^'.getenv('LANDO_APP_NAME').'\.localtunnel\.me$', # lando share access
  '^192\.168\.1\.100$'                            # LAN IP access
];

Նշում․ Lando կոնտեյները պարունակում է ավելի շատ շրջակա փոփոխականներ, որոնք կարող եք օգտագործել ճիշտ տվյալների բազայի տեղեկություններն սահմանելու համար։ Այդ մասին մանրամասն տեղեկություններ կարող եք ստանալ՝ ուսումնասիրելով $lando_info=json_decode(getenv('LANDO_INFO'), TRUE); կամ phpinfo()։