Configurați NGINX pentru a furniza conținut JSON diferit bazat pe $http_referrer

Lucrez la un serviciu + aplicație web + aplicație mobilă, unde

• aplicația mobilă este utilizată pentru a consuma conținut
• creat de o comunitate deschisă de autori în aplicația web
• întregul fiind deservit de un server care rulează Nginx pe Ubuntu (ei bine, unele solicitări sunt trimise proxy către serverele backend Nginx), dar acesta este un detaliu

Problema pe care vreau să o rezolv eficient este cea care decurge din faptul că conținutul poate fi creat de un comunitate deschisă - aproape oricine poate face clic pe câteva butoane și poate începe procesul de creare a conținutului ca răspuns la care serverul generează conținut stub sub forma unui fișier JSON pe care autorii de conținut îl pot personaliza.

Acum, aici este problema - vreau să evit să pierd timpul pe server și spațiul de stocare pe disc creând conținut JSON stub pentru autorii care încep procesul, dar nu îl execută niciodată (traducere = înscriere pentru a crea conținut și apoi nu o fac niciodată).

Cu alte cuvinte, vreau să creez conținut JSON stub pentru autori numai atunci când sunt sigur că se vor lansa efectiv în procesul de personalizare. În același timp, vreau să mă asigur că aplicația mobilă primește o eroare 404 grațioasă pentru conținutul extras de CDN pe care încearcă să îl capteze printr-un CDN.

Cu alte cuvinte, există două seturi de „consumatori” pentru conținut

1. Autorii de conținut care, de obicei, vor solicita conținutul direct de pe serverele mele printr-o aplicație web de backoffice care va apărea pe NGINX ca `$http_reffer = https://example.com/backoffice'
2. CDN-ul care va încerca să extragă același conținut din aceeași locație ca răspuns la solicitările din aplicația mobilă.

Răspunsurile implicite pentru conținutul lipsă sunt

1. Autorii de conținut: Stub JSON este generat și trimis înapoi
2. CDN: Nu există niciun fișier JSON de conținut, așa că un antet 404 este trimis înapoi

Soluția pe care o am în minte este de-a lungul următorului bloc de configurare Nginx

locație /cdn/appdata/content
{
 add_header Acces-Control-Permite-Origine *;
 dacă ($http_referer ~* ^https://example.com/backoffice) 
 {
  dacă (!-e $request_filename) {rescrie ^/(.*)$ /pathto/stub-json-generator.php?$1 ultimul;}
 } 
} altfel ??? /* aruncă înapoi JSON existent sau răspunde cu 404. Ambele solicitantului CDN

Mă amestec cu configurația Nginx din când în când, dar nu sunt expert. Întrebarea mea - este ceea ce am subliniat un mod decent de a face această sarcină sau trebuie să aprofundez scriptingul Nginx prin JS sau Lua? Scripting-ul Lua necesită instalarea Open Resty, ceea ce aș dori să evit, deoarece am Nginx deja configurat să funcționeze cu NChan și Dart, ceea ce ar trebui să fac din nou pentru Open Resty. În afară de asta, încercarea de a accesa Redis și Postgres dintr-un script Lua mă va duce pe un teritoriu necunoscut.

Aș putea pur și simplu să șterg această întrebare, dar o las aici cu soluția mea pentru beneficiul oricui altcineva care vrea să facă ceva similar.

Soluția este de fapt orbitor de simplă și nu este în întregime o problemă de configurare Nginx. Lucrul important de realizat este că Nginx lucrează pe Ubuntu și are acum un mod de a distinge între a real folder și a link simbolic. Deci, să presupunem că am făcut următoarele

• Atribuiți folderul /cale/la/authordata linkul simbolic /cale/spre/conținut cititor prin urmare
• ln -s /path/to/authordata /path/to/readercontent

Acum configurați următoarele blocuri de configurare Nginx

locația /calea/la/datele autorului
{
 add_header Acces-Control-Permite-Origine *;
 rescrie ^(.*)$ /path/to/authordata/index.php?$1 ultimul;
}

 locație /cale/spre/conținut cititor
 {
  add_header Acces-Control-Permite-Origine *;
 }

Fără să știe unul de celălalt, aceste două blocuri se adresează de fapt același folder Ubuntu.

Primul îl folosim pentru a accesa datele autorului pentru editare. Deoarece conținutul este livrat de un script PHP, avem capacitatea de a genera conținut stub din mers. În acest fel, nu există un conținut implicit de stub de autor care să nu fie utilizat niciodată, care să blocheze serverul.

Îl folosim pe acesta din urmă pentru a introduce materiale de citire în aplicația mobilă printr-o cerere de extragere CDN. O resursă de date despre autor lipsă va avea ca rezultat un răspuns standard 404. Antetul CORS, care ar putea fi mai specific, oprește CDN-ul să nu mai fie respinsă în încercarea de a extrage date.