Ierosinātais kods vienmēr bija tuvu zemākajai:

config/initializers/cors.rb

Sliedes.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins ''
resource '', headers: :any, methods: :any
end
end

un, diemžēl, šie teksti bija diez vai izskaidrojot, lai mums ko faktiski darīt ražošanā.

Es esmu diezgan OK ar copy-pasting (Es reizēm jokoju, ka uzņēmumi varētu nolīgt Stack Overflow copy-paster), ciktāl starp “kopēt” un “ielīmēt” ir brīdis “padomāt un pielāgot”. Tāpēc es gribētu mazliet sīkāk pastāstīt par to, ko mēs šeit darām un kā tas darbojas reālajā dzīvē.

Es ceru, ka jūs neiebilstat, ja sākšu ar īsu ievadu goda teorijā un pēc tam pāriešu pie Rails piemēriem.

Ievads

Sāksim no sākuma. Lai labāk paskaidrotu, esmu sadalījis ievadu trīs daļās. Pirmajā daļā tiks izklāstīts, kas ir izcelsme - galvenais termins tam, ko mēs šeit aplūkosim. Otrajā daļā ir runa par SOP, tikai īss apraksts. Un pēdējā daļā ir runa par CORS pati.

Kas ir izcelsme?

Saskaņā ar MDN Tīmekļa vietne Dokumenti:

- Tīmekļa satura izcelsmi nosaka pēc tā piekļuvei izmantotā URL adresāta shēmas (protokola), mitinātāja (domēna) un porta. Diviem objektiem ir viena un tā pati izcelsme tikai tad, ja shēma, resursdators un ports sakrīt (avots)

Tas šķiet diezgan skaidrs, vai ne? Izanalizēsim divus piemērus no MDN.

1. http://example.com/app1/index.html, http://example.com/app2/index.html

2 iepriekš minētajiem ir viena un tā pati izcelsme, jo:

• to shēmas (http) ir vienādas,
• to domēni (example.com) ir vienādi,
• to porti (netieši) ir vienādi.

2. http://www.example.com, http://myapp.example.com

Šo 2 domēnu izcelsme ir atšķirīga, jo domēni (www.example.com, myapp.example.com) ir atšķirīgi.

Es ceru, ka tas ir pietiekami skaidrs. Ja ne, lūdzu, apmeklējiet MDN tīmekļa dokumentus, lai iegūtu vairāk piemēru.

Kas ir SOP?

MDN Web Docs saka (avots):

- Vienas un tās pašas izcelsmes politika ir svarīgs drošības mehānisms, kas ierobežo, kā dokuments vai skripts, kas ielādēts no vienas izcelsmes, var mijiedarboties ar citas izcelsmes resursu. Tas palīdz izolēt potenciāli ļaunprātīgus dokumentus, samazinot iespējamos uzbrukuma vektorus.

- Parasti ir atļauti starpizcelsmes ieraksti. Piemēram, saites, pāradresācijas un veidlapu iesniegšana.

- Parasti ir atļauta starpizcelsmes iestrādāšana.

- Parasti nav atļauts lasīt starp izcelsmes vietām, bet lasīšanas piekļuve bieži tiek nopludināta, izmantojot iestrādi.
Izmantojiet CORS lai atļautu starpizcelsmes piekļuvi

Kā redzat, SOP definīcijās ir daudz informācijas par starpizcelsmes uzvedību. Tas ir labi. Viss, kas mums tagad jāzina, ir tas, ka vienai un tai pašai izcelsmei ir vairāk privilēģiju, un mēs varam mīkstināt noteikumus attiecībā uz starpizcelsmēm, izmantojot CORS. Un šeit nāk nākamā sadaļa.

Kas ir CORS?

Pamatojoties uz MDN vārdiem:

• Starpizcelsmes resursu koplietošana (CORS) ir uz HTTP galveni balstīts mehānisms, kas ļauj serverim norādīt jebkuru citu izcelsmi (domēnu, shēmu vai portu), no kuras pārlūkprogrammai jāļauj ielādēt resursus. CORS balstās arī uz mehānismu, ar kura palīdzību pārlūkprogrammas izdara “pirmsizpētes” pieprasījumu serverim, kurā tiek izvietots starpizcelsmes resurss, lai pārbaudītu, vai serveris atļaus veikt faktisko pieprasījumu. Šajā pirmsapstrādes pārbaudē pārlūkprogramma nosūta galvenes, kas norāda HTTP metodi un galvenes, kuras tiks izmantotas faktiskajā pieprasījumā. (avots).

Ar to joprojām nepietiek. Tur nav skaidri pateikts, ka vissvarīgākais ir tas, ka, izmantojot CORS ir . Access-Control-Allow-Origin:

• Portāls Access-Control-Allow-Origin atbildes galvenē ir norādīts, vai atbildi var kopīgot ar konkrētās izcelsmes kodu (avots).

Nu, tam vajadzētu būt visam. Reālajā dzīvē, konfigurējot CORS, mēs parasti konfigurējam ACAO virsraksts pirmais.

Reālā dzīve

Tas ir viss, kad runa ir par definīcijām. Atgriezīsimies pie Rails un reālās dzīves piemēriem.

Kā konfigurēt CORS Rails sistēmā?

Mēs noteikti izmantosim plauktus-korpusus (kā mums teica). Atgādināsim pirmo fragmentu, kas visbiežāk tiek sniegts citos rakstos:

config/initializers/cors.rb

Rails.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins ''
resource '', headers: :any, methods: :any
end
end

Iespēju skaits ir plašs vai pat bezgalīgs, bet aplūkosim šīs divas:

• mēs veidojam API ko atļauts izmantot trešo pušu pārlūkprogrammu klientiem,
• esam izveidojuši tipisku frontend/backend atdalīšanu un vēlamies, lai mūsu uzticamie klienti varētu piekļūt API.

Trešo pušu klientu piekļuve API

Ja jums ir pirmā iespēja, iespējams, varat izvēlēties šādu risinājumu. izcelsme ‘*’ - jūs taču vēlaties, lai citi uz jūsu API bāzes izveidotu klientu, un nezināt, kas tie ir, vai ne?

Tipiska frontend/backend nodalīšana

Ja izstrādājat pēdējo, iespējams, nevēlaties, lai ikviens veiktu pārrobežu pieprasījumus jūsu API. Jūs drīzāk vēlaties:

• ļaut ražošanas klientiem piekļūt ražošanas API,
• tas pats attiecas arī uz inscenēšanu,
• tas pats attiecas uz localhost,
• iespējams, vēlēsieties atļaut FE pārskatīšanas programmām piekļūt stadijai.

Mēs joprojām izmantosim plauktus-korpusus (kā mums teica), bet mūsu veidā.

Izmantosim 2 ENV mainīgos: ATĻAUTĀS_IZCELSMES burtiskām izcelsmes definīcijām (zvaigznīte vai faktiskais URL) un ATĻAUTAS_IZCELSMES_REĢEXPS modeļiem.

config/initializers/cors.rb

frozenstringliteral: true

toregexp = ->(string) { Regexp.new(string) }
hosts = [
*ENV.fetch('ALLOWEDORIGINS').split(','),
*ENV.fetch('ALLOWEDORIGINREGEXPS').split(';').map(&to_regexp)
]

Rails.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins(*hosts)

resurss '*',
         methods: %i[get post put patch delete options head],
         headers: :any

beigas
end

Kas šeit notiek?

1. Kā redzat, mēs sadalām ENV mainīgajos definētās vērtības ar dažādiem atdalītājiem. Tas ir tāpēc, ka ir mazāka iespēja, ka URL definēšanas paraugā parādīsies semikols.
2. Literālās vērtības ir gatavas lietošanai, bet mums ir jāsalāgo šabloni kā faktiskie Regexp gadījumi.
3. Pēc tam mēs visu apvienojam kopā un ļaujam šiem resursiem piekļūt jebkuram resursam ar mūsu API izmantotajām metodēm, kas iekļautas baltajā sarakstā.

Tam vajadzētu būt pietiekami elastīgam, lai definētu atbilstošas vērtības izstrādes, sagatavošanas un ražošanas vidēs.

Secinājumi

Apkoposim visu iepriekš minēto galvenajos punktos:

• izmantot ENV mainīgos, lai konfigurētu CORS,
• izmantot regulārās izteiksmes, lai ļautu dažādām izcelsmes vietām piekļūt posma API (piemēram, pārskatīšanas lietojumprogrammām),
• starp “kopēt” un “ielīmēt” vienmēr ievietojiet “pārdomāt un pielāgot”.

Tas ir viss. Jauku dienu! 🙂

Lasīt vairāk:

Kāpēc jums (iespējams) vajadzētu izmantot Typescript?

10 NYC jaunuzņēmumi, kurus vērts pieminēt 2021. gadā