Cum să vindeți găzduire web cu Plesk

Plesk rulează fără probleme o sută de abonamente pentru dumneavoastră. Ce nu face este să preia o comandă, să încaseze banii, să observe că o factură a rămas neplătită sau să suspende contul care îi aparține. În acest gol dintre „un panou care găzduiește site-uri web” și „o afacere de găzduire” se află munca, iar această pagină arată cum să îl traversați fără să greșiți în cele patru puncte în care se greșește ușor.

Ce vă oferă deja Plesk

Un abonament este unitatea pe care o vindeți: un domeniu principal, un plan de serviciu, limite de spațiu pe disc și de trafic și tot ce se află sub el. Un plan de serviciu este descrierea pe care o dă panoul acelui pachet: cotă, trafic lunar, câte domenii și căsuțe de e-mail, ce servicii sunt active. Ambele concepte există deja, așa că nu inventați un model de produs, ci denumiți unul care este deja acolo.

API-ul este bun într-un fel care contează în special pentru un produs de găzduire: un singur apel citește fiecare abonament de pe server, cu planul, starea, cota și utilizarea lui. Am măsurat asta la 0,33 secunde, indiferent câte sunt. Trei apeluri de citire vă oferă tabloul complet al unui server (abonamente, clienți, planuri), iar acest număr nu crește odată cu numărul dumneavoastră de clienți. Construirea aceluiași tablou prin REST ar necesita un apel plus trei pe abonament.

O singură cheie deschide două API-uri, și aveți nevoie de amândouă

Plesk are un API REST v2 modern și un API XML/RPC mai vechi. Niciunul nu este complet de unul singur, iar aceasta nu este o chestiune de preferință.

REST v2 nu are abonamente și nu are planuri de serviciu. I-am enumerat cele 43 de căi din propriul său document OpenAPI; /subscriptions și /service-plans nu se numără printre ele, iar cererea lor returnează un 404 redat ca pagină HTML în loc de JSON. Deoarece planul de serviciu este pachetul de găzduire, întreaga parte a pachetelor trebuie să treacă prin XML.

Ce salvează situația sunt datele de autentificare. Cheia emisă de POST /api/v2/auth/keys funcționează neschimbată în amândouă: ca X-API-Key în REST și ca KEY la endpointul XML. Măsurat, aceeași cheie, ambele API-uri. Așadar îi cereți operatorului o singură valoare, nu două.

Ceea ce vă costă sunt două vocabulare ale eșecului. REST răspunde la o cheie inutilizabilă cu HTTP 401 și un corp complet gol. XML răspunde la aceeași cheie cu HTTP 200 și un cod de eroare în interiorul documentului. Ceea ce ne aduce la muchia ascuțită.

O eroare de autentificare care arată ca un server gol

Deoarece API-ul XML returnează HTTP 200 pentru o cheie greșită, un client care verifică codul de stare citește o eroare de autentificare ca un tur reușit care nu a găsit nimic. Iar un tur reușit care nu a găsit nimic are un înțeles în orice platformă de găzduire: fiecare cont care era acolo ieri a dispărut.

Consecința nu este un tablou de bord stricat. Este un sistem care marchează fiecare client al dumneavoastră ca șters pentru că o cheie a expirat. Regula care decurge de aici este absolută: pe API-ul XML, codul de stare nu poartă nicio informație, nici măcar despre autentificare. Analizați documentul și tratați un răspuns ilizibil ca necunoscut, nu ca gol.

Nici un server gol nu produce o eroare. Produce un singur rezultat gol, care este răspunsul corect atunci când chiar nu există niciunul. A distinge între aceste două cazuri este toată munca.

Capcana suspendării: scrieți și citiți același câmp

Există două moduri de a suspenda un abonament în Plesk, iar ele nu scriu în același câmp.

Recitiți al doilea rând. Suspendarea prin REST lasă la zero câmpul pe care îl citește interogarea în masă. Așadar, un produs de găzduire care suspendă prin REST și interoghează prin XML va afișa contul ca activ, în timp ce el este, de fapt, suspendat. Nimic nu dă eroare. Nimic nu se face roșu. Panoul și serverul dumneavoastră pur și simplu nu sunt de acord, iar prima persoană care observă este un client care nu poate ajunge la un site pe care îl credeți în funcțiune.

Regula: suspendați și reluați prin același câmp pe care îl citiți. Provibr folosește XML <webspace><set><gen_setup><status>, iar după aceea ambele vederi se mișcă împreună: câmpul XML raportează 16, iar REST raportează suspended.

gen_info.status este o mască de biți, iar valorile pe care le-am măsurat sunt 0 pentru activ, 1 pentru webspace-off și 16 pentru dezactivat de administrator. Orice nu este zero se consideră suspendat, ceea ce este singura interpretare care rezistă la o valoare pe care încă nu am văzut-o.

Două seturi de date pe care nu le cerem niciodată panoului

API-ul XML al Plesk este construit pentru administrare, așa că două dintre seturile sale de date returnează material de autentificare unui apelant care le cere:

• <webspace><get> cu setul de date hosting returnează parola FTP a contului în text clar, cu un câmp care o marchează explicit ca text clar.
• <customer><get> cu setul de date gen_info returnează hash-ul parolei clientului (bcrypt) alături de tipul de hash.

Acest lucru este rezonabil pentru un API de administrare. Nu este ceva ce o platformă de găzduire ar trebui să tragă pe rețea în mod programat.

Un strat de redactare este răspunsul greșit la aceasta. Răspunsul corect este să nu se ceară. Interogarea Provibr solicită exact patru seturi de date (informații generale, limite, statistici și abonamente), iar noi le-am parcurs câmp cu câmp pentru a confirma că niciunul nu poartă un secret. Lista de clienți vine din REST, care nu are niciun câmp de parolă.

Există o consecință de proiectare care merită menționată. Utilizatorul FTP sau de sistem al unui abonament ar fi un identificator scurt și atrăgător, dar el trăiește doar în setul de date hosting, așa că folosirea lui ca identitate ar însemna preluarea parolei fiecărui client la fiecare ciclu de interogare. De aceea, în schimb, domeniul.

Identitatea unui abonament este un nume de domeniu

În Plesk, un abonament poartă numele domeniului său principal. Este ceea ce afișează panoul, ceea ce filtrează API-ul său și ceea ce trebuie să stocheze orice integrare.

Aceasta este o diferență reală față de cPanel și DirectAdmin, unde un cont are separat un nume de utilizator scurt și un domeniu, și are o consecință practică: domeniul nu mai poate fi schimbat ulterior. Orice stochează sistemul dumneavoastră de facturare ca identificator al unui abonament Plesk este un nume de domeniu, iar un client care vrea să își redenumească site-ul cere un abonament nou, nu o modificare.

Două lucruri mai mărunte măsurate pe parcurs. Specificația proprie a Plesk spune că o parolă de client are de la 5 la 14 caractere; o parolă de 22 de caractere a fost acceptată fără reproș, așa că limita documentată nu este cea aplicată. Iar Plesk alege el însuși adresa IP din propriul său bazin, motiv pentru care un cont de găzduire în Provibr are un câmp de adresă gol până când panoul raportează una.

O comandă eșuată poate lăsa în urmă jumătate de abonament

Măsurat: crearea unui domeniu cu un plan de serviciu care nu există răspunde cu HTTP 404 și un mesaj clar, iar obiectul domeniu există totuși după aceea, fără tip de găzduire și cu o rădăcină de documente goală. Plesk creează mai întâi obiectul și aplică apoi planul și nu revine la starea anterioară când al doilea pas eșuează.

Clientul a plătit, comanda a eșuat, iar următoarea reîncercare eșuează acum diferit, pentru că domeniul este deja folosit, de un cont pe care nu l-a primit niciodată. Așadar, căutați planul înainte de a crea ceva, din lista de planuri pe care ați preluat-o deja, și faceți curat după orice creare eșuată. În contrast, o eroare de validare a unui câmp, cum ar fi un nume de autentificare duplicat, revine ca HTTP 400 și nu lasă nimic în urmă: acea verificare rulează înainte de creare, iar doar căutarea planului vine prea târziu.

Fără întârziere, ceea ce este mai rar decât ar trebui

Lista de utilizare a DirectAdmin rămâne în urma realității cu aproximativ trei secunde în ambele direcții, ceea ce forțează un al doilea apel de referință. Plesk nu. Am măsurat o creare și o ștergere față de citirea în masă:

    0 ms  create
 4519 ms  create returns 201
 4957 ms  bulk read sees the subscription      <- immediately
 4957 ms  delete
12622 ms  delete returns 200
13001 ms  bulk read no longer sees it          <- immediately

Plesk este tranzacțional: de îndată ce apelul răspunde, modificarea este vizibilă în citirea în masă. O singură sursă de referință, fără al doilea apel, fără așteptare.

Timpii înșiși merită notați. Crearea unui abonament durează 4,1 până la 4,5 secunde, iar ștergerea unuia 7,7 secunde, suficient de mult încât un client care privește un formular de comandă trebuie să fie informat că se întâmplă ceva. Schimbarea planului durează 1,5 secunde, iar suspendarea 0,78.

Ce face Provibr cu toate acestea

Provibr se așază între facturarea dumneavoastră și serverul dumneavoastră Plesk. Conectați serverul cu o singură cheie API, iar după aceea un abonament este un rând obișnuit: comandați-l, suspendați-l, reluați-l, mutați-l la alt plan de serviciu, ștergeți-l.

• O singură cheie, pentru că aceeași cheie deschide ambele API-uri.
• Suspendarea trece prin câmpul pe care îl citește interogarea, astfel încât panoul și serverul nu pot ajunge să difere.
• Interogarea nu cere niciodată un set de date care conține o parolă, așa că niciun secret al clientului nu ajunge la platformă.
• Planul este rezolvat înainte de creare, iar o creare eșuată este curățată în loc să fie lăsată în urmă.
• Nimic nu este crezut pe cuvânt. Fiecare modificare se încheie prin recitirea abonamentului.
• Agentul se conectează spre exterior din rețeaua dumneavoastră, astfel încât portul 8443 nu este expus către internet și nimic nu se instalează pe serverul Plesk.
• Abonamentele pe care nu le-ați comandat prin Provibr rămân neatinse până când le importați, ceea ce face ca un server cu două sute de clienți existenți să poată fi preluat, în loc să fie o reconstrucție.

Ce nu face

Gestionează abonamentele de pe un server Plesk pe care îl operați, nu serverul însuși: serviciile, zonele DNS, rutarea e-mailului și setările proprii ale panoului rămân unde sunt. Nu există consolă, pentru că un cont de găzduire nu este o mașină. Căsuțele de e-mail, bazele de date și DNS-ul din interiorul unui abonament aparțin Plesk și clientului dumneavoastră.

Un gol sincer: totul de aici a fost măsurat cu o cheie de administrator. Dacă o cheie limitată la un revânzător sau la un client poate folosi deloc API-ul XML rămâne netestat, așa că integrarea sondează la momentul conectării și refuză datele de autentificare care pot vedea doar o parte dintr-un panou, în loc să gestioneze în tăcere jumătate din el.

De citit în continuare

• Automatizarea facturării și a aprovizionării Plesk: cele trei momente în care banii și mașinile se ating și capcanele din fiecare.
• Alternative la cPanel pentru furnizorii de găzduire: șase panouri, după modelul de licențiere, efortul de migrare și comportamentul API măsurat.
• Configurarea Plesk: cheia API, planurile de serviciu, planurile web și importul abonamentelor.

Măsurat pe Plesk Obsidian 18.0.80 în august 2026, cu toate răspunsurile înregistrate ca fixtures. Comportamentul cu o cheie limitată la un revânzător, cu mai mult de un abonament per client și sub o sarcină reală de trafic nu a fost măsurat și este notat ca atare mai sus.