Bază de cunoștințe
Creați un Azure service principal cu rolul Contributor pe un grup de resurse și conectați-l, astfel încât site-urile dumneavoastră statice să fie construite din depozitul dumneavoastră pe propriul abonament Azure.
Conectarea propriului cont Azure Static Web Apps vă permite să publicați un site static în contul dumneavoastră Azure Static Web Apps direct din tabloul de bord Zinn®. Dumneavoastră dețineți proiectul și facturarea; noi ne ocupăm de implementare, domeniul personalizat și înregistrările DNS.
Un abonament Azure, un grup de resurse pentru site-uri și un cont conectat de GitHub, GitLab sau Bitbucket care conține codul — Azure Static Web Apps construiește dintr-un depozit. Planul gratuit Azure permite utilizarea comercială și două domenii personalizate pentru fiecare aplicație.
Azure numește acest lucru un service principal. În centrul de administrare Microsoft Entra deschideți Entra ID → App registrations → New registration, dați-i un nume și apăsați Register. Pe pagina de prezentare generală a aplicației copiați Application (client) ID și Directory (tenant) ID. Apoi deschideți Certificates & secrets → Client secrets → New client secret, alegeți o durată și apăsați Add — copiați imediat valoarea secretului, Azure o afișează o singură dată.
În portalul Azure, deschideți grupul de resurse pe care doriți să îl folosim, apoi Access control (IAM) → Add → Add role assignment. Alegeți rolul Contributor, atribuiți-l la User, group, or service principal, căutați aplicația după nume și apăsați Review + assign. Notați numele grupului de resurse și valoarea Subscription ID de care aparține (căutați Subscriptions în portal).
Deschideți Integrations în tabloul dumneavoastră de bord și alegeți Connect an account. Selectați Static hosting (Netlify, Vercel) ca grup și Azure Static Web Apps ca cont, completați Client ID, Client secret, Tenant ID, Subscription ID și Resource group, apoi apăsați Connect account.
Testăm ceea ce introduceți înainte de a salva ceva. O cheie care nu funcționează nu este stocată niciodată, iar răspunsul explică ce anume a fost greșit. O cheie care funcționează este păstrată criptată în seiful nostru de secrete — niciodată în baza noastră de date — și nu este afișată niciodată din nou, nici măcar dumneavoastră.
implementare. Azure Static Web Apps construiește dintr-un depozit — nu are nicio modalitate de a accepta o versiune compilată încărcată direct — astfel încât codul site-ului trebuie să provină dintr-un depozit conectat de GitHub, GitLab sau Bitbucket. Conectați unul mai întâi dacă nu ați făcut-o deja.
și declanșăm implementările. Pagina domeniului afișează orice înregistrare DNS de care are nevoie Azure Static Web Apps.
de care dintre acestea are nevoie domeniul dumneavoastră.
Azure a refuzat entitatea service principal. Fie secretul de client a expirat — acestea expiră întotdeauna, conform duratei pe care ați ales-o — fie aplicația nu mai are rolul de Contributor pe grupul de resurse. Cele două mesaje seamănă, așa că verificați atribuirea rolului înainte de a crea un secret nou.
Nu se găsește nimic. Verificați dacă Subscription ID și Resource group sunt cele cărora le-ați atribuit rolul și dacă Tenant ID este directorul în care este înregistrată aplicația.
Se indică faptul că cheia a fost respinsă. Este aproape întotdeauna vorba despre unul dintre următoarele trei motive: un spațiu sau o întrerupere de rând copiată odată cu ea, o cheie care a expirat sau o cheie care a fost revocată ori regenerată după ce ați copiat-o. Creați una nouă și introduceți-o din nou.
Se conectează, dar o operațiune ulterioară eșuează. Cheia se autentifică, dar îi lipsește o permisiune de care are nevoie acțiunea. Creați o cheie nouă cu permisiunile menționate mai sus, apoi deconectați vechea conexiune și conectați noua cheie.
Deschideți Integrations, găsiți contul și apăsați Disconnect. Această acțiune șterge imediat cheia stocată. Orice element care o folosea se va opri la următoarea sa acțiune, iar ecranele care depindeau de ea vor semnala acest lucru în loc să eșueze silențios.
Deconectarea nu anulează ceea ce a fost deja efectuat — înregistrările, implementările sau setările pe care le-am modificat în contul dumneavoastră rămân neschimbate. Dacă suspectați că însăși cheia a fost compromisă, revocați-o și la furnizor; deconectarea șterge copia noastră, nu și pe a lor.
Ce am scris despre găzduire, SEO și administrarea site-urilor la scară largă.
Cum influențează găzduirea indexarea și distribuția autorității legăturilor (link equity) în 2026: menținerea paginilor indexate, evaluarea domeniilor vechi înainte de a construi pe ele, construirea de linkuri fără amprentă (footprint) și o perspectivă onestă asupra a ceea ce infrastructura poate și nu poate face pentru SEO.
Citiți articolul →O listă practică de verificare pentru un WordPress rapid și securizat: stocarea în cache la nivel de server, o memorie cache de obiecte per site, puținele module care merită rulate, menținerea stivei la zi și paginile WooCommerce pe care nu trebuie să le includeți niciodată în cache.
Citiți articolul →Ce diferențiază cu adevărat o găzduire administrată bună de o mașină ieftină cu panou de control — migrări, copii de rezervă, izolare, stocare în cache reală și scalare corectă — și cum să o evaluați înainte de a vă lua un angajament.
Citiți articolul →Asistența este inclusă în fiecare plan, biroul este deschis 24 ore pe zi și ne puteți scrie în oricare dintre cele 58 limbi ale noastre — vă răspundem în limba dumneavoastră.
Contactați asistența → Toate articolele →