Panouri white-label: ce vede clientul

Dacă revindeți VPS-uri sau găzduire, clienții dumneavoastră vor la un moment dat un panou. Vor să își repornească singuri mașina la două noaptea în loc să deschidă un tichet, iar dumneavoastră vreți să o facă.

Asta se transformă în două întrebări care par una singură și nu sunt. Al cui nume stă pe panou și ce părți din panou există în general pentru acea persoană. Prima ține de marcă și mai ales de prezentare. A doua este o graniță, iar greșind-o ajungeți la situația în care un client de-al dumneavoastră citește factura furnizorului dumneavoastră.

Marca proprie se oprește acolo unde încep actele

A pune marca proprie pe un panou înseamnă a schimba cadrul: numele din bara laterală, titlul paginii, pictograma filei, numele din blocul de cont. Este o cantitate utilă și este locul unde se opresc cele mai multe funcții de tip white-label.

Partea interesantă este lista lucrurilor care nu au voie niciodată să poarte numele revânzătorului.

Raționamentul încape într-o propoziție: un client al clientului dumneavoastră nu are voie să ajungă să creadă că are un contract cu altcineva decât cu partea cu care îl are în realitate. Tot ce are caracter juridic sau financiar poartă numele părții din acel document, iar aceasta nu este o preferință de design.

Mai mult decât regula contează unde trăiește ea. În codul nostru este o listă de căi de fișiere, iar un test parcurge arborele de importuri tranzitiv pornind de la fiecare dintre ele și eșuează în clipa în care unul poate ajunge în general la modulul de marcă. Parcurgerea este în lățime, așa că eroarea numește cel mai scurt lanț, adică exact cel care trebuie tăiat.

O verificare a importurilor directe este prea ușor de ocolit: puneți căutarea mărcii într-un ajutor, importați ajutorul, gata. Iar măsura se verifică pe sine în ambele sensuri. O cale listată care dispare este o eroare și nu o sărire tăcută peste ea, și se afirmă separat că aranjamentul panoului chiar ajunge la modulul de marcă, pentru că un rezolvator care nu rezolvă nimic în tăcere ar marca fiecare fișier drept verde.

Autentificarea revânzătorului însuși nu poartă niciodată marca lui

Există o a doua regulă, mai puțin evidentă, pe care am fi greșit-o dacă nu o enunțam: marca proprie se aplică numai pe domeniul propriu al clientului.

Când revânzătorul se autentifică pe gazda proprie a platformei, vede platforma, nu propria lui marcă. Acolo trăiesc facturile, abonamentul și relația cu noi. Căutarea mărcii cade înapoi pe varianta simplă în clipa în care o cerere nu este legată de un domeniu de cont, așa că decide exact un singur loc și niciun ecran nu trebuie să își amintească nimic.

Ecranul de administrare a mărcii arată o previzualizare a cadrului pe care îl vede clientul, în loc să poarte el însuși acea marcă. Sună pedant până când vă gândiți ce învață alternativa: un revânzător care își vede propriul logo deasupra propriei facturi va trage concluzia rezonabilă că și clienții lui văd ceva asemănător.

Un logo alb pe o bară laterală albă

Fundalul panoului nostru este alb, așa că un logo cu fundal transparent și cerneală albă este invizibil, iar cel care îl încarcă nu va afla: el se uită la logo într-o unealtă de design, pe o planșă gri.

Am măsurat în loc să ghicim, compunând fiecare logo peste culoarea reală a suprafeței, într-un navigator fără interfață:

Rândul cu 1.00:1 nu înseamnă „greu de citit”. Fiecare pixel este identic cu fundalul. Logoul este desenat și nu este nimic de văzut.

Din asta au ieșit două decizii. Sub logo nu există în mod deliberat nicio placă, pentru că aceasta ar redesena marca clientului și ar da o ramă fiecărui logo normal doar ca să salveze o excepție. Iar ecranul de încărcare avertizează în loc să refuze, pentru că o marcă are voie să fie gri deschis.

Măsurătoarea numără cerneala, nu suprapunerea. Un logo cu o margine transparentă mare coincide cu fundalul pe cea mai mare parte a suprafeței lui și este perfect vizibil; ce contează este cât din el este desenat și cât de departe stă acea cerneală de culoarea suprafeței.

Absența nu este o permisiune

Acum jumătatea mai grea. Ce ecrane ar trebui să existe pentru clientul unui revânzător?

Instinctul spune să modelați asta ca permisiuni: dați subclientului un rol, bifați mai puține căsuțe. Aceasta este forma greșită, dintr-un motiv care apare abia la margini. Permisiunile răspund la „are voie acest membru să facă asta”. Întrebarea de aici este „există acest ecran pe acest domeniu”, iar cele două se despart în clipa în care proprietarul unui cont se autentifică pentru a se uita la propriul lui panou de client. El este proprietarul. Orice verificare de permisiuni îi face semn să treacă.

Așa că modelul este o inversare, nu un drept. O listă fixă spune ce suprafețe lipsesc pe un domeniu de cont: facturarea, setările de cont, tichetele, agenții, integrările, jurnalul de activitate al contului, vederea de topologie, zona de administrare a platformei și paginile de înregistrare și de parolă uitată. Absente pentru toată lumea, inclusiv pentru proprietar.

Trei dintre ele au nevoie de justificare, pentru că motivul nu este cel evident.

Tichetele lipsesc pentru că un client al unui revânzător are o relație de asistență cu revânzătorul, nu cu noi. Dacă acel ecran ar exista, el ar citi un răspuns care numește o firmă ce, potrivit propriului lui panou, nu există.

Jurnalul de activitate lipsește pentru că este jurnalul contului, nu al cititorului. Rezultatul sincer nu este un jurnal filtrat, ci „acest ecran nu există aici”. Fila de activitate per server rămâne, pentru că aceea chiar este delimitată la o mașină pe care el o are.

Vederea de topologie dovedește modelul. Ea rulează pe modulul de servere, iar modulul de servere este exact singurul lucru pe care un subclient chiar îl are. O poartă de permisiuni nu ar plivi absolut nimic.

Trei închideri, pentru că o pagină nu este o graniță

O singură verificare nu este de ajuns, iar fiecare dintre cele trei prinde ce nu pot prinde celelalte.

Prima este chiar în funcția de permisiuni, unde ordinea a două linii este toată ideea:

1. 01Există acest modul pe această suprafață? Dacă nu, refuză.
2. 02Are acest rol acces deplin? Dacă da, permite.

Punerea testului de suprafață pe primul loc este ceea ce face ca „nu există” să bată „are voie orice”, și este ceea ce face ca inversarea să țină peste tot, nu doar în ecranele de care și-a amintit cineva.

A doua este o măsură de protecție în fiecare pagină aflată sub acele căi, care produce un 404 obișnuit. Ea nu primește în mod deliberat niciun argument: un apel care și-ar numi propriul ecran ar lăsa o greșeală de tastare să devină o ușă deschisă în tăcere.

A treia este în serverul-proxy invers, pentru că o pagină nu poate prinde o cerere care nu ajunge niciodată la o pagină. Un POST către o cale absentă este refuzat înainte să ruleze vreun cod de pagină. Navigările sunt lăsate să treacă, pentru ca aplicația să își afișeze propriul 404 în loc de o eroare seacă de proxy.

Cookie-ul este o regulă de navigator, nu o regulă de server

Aceasta este constatarea care merită luată cu dumneavoastră chiar dacă nu construiți nimic din cele de mai sus.

Cookie-urile noastre de sesiune sunt legate strict de gazdă. Fără atribut Domain, așa că o sesiune de pe un domeniu de client nu este trimisă către altul și nici către gazda platformei. Asta este corect și este testat, inclusiv cazul negativ în care activarea cookie-urilor între subdomenii face să apară un Domain.

Nu este însă o graniță. Subclientul își ține propriul jeton de sesiune și îl poate trimite oriunde vrea, cu un client HTTP din linia de comandă. Doar un navigator ar fi refuzat.

Am măsurat ce permitea asta și era mai rău decât ne așteptam: un subclient putea crea o organizație nou-nouță cu el însuși drept proprietar, completă, cu abonament de probă propriu, pe două trasee de cod independente accesibile din patru puncte de intrare diferite. Patru organizații, numărate ulterior în baza de date. Pe domeniul lui aceeași cerere era refuzată de proxy, așa că ușa era închisă pe o parte și deschisă pe cealaltă.

Reparația nu a fost adăugarea de verificări pe acele două trasee. A fost mutarea graniței în singurul punct prin care trece orice cerere autentificată și punerea invariantului „un subclient nu devine niciodată proprietarul unei organizații” în singura funcție pe care o împart toate traseele de creare.

Aceeași rundă a găsit varianta generală a problemei în altă parte. O cheie de API poartă un rol, dar nu o suprafață. Nu era exploatabilă, pentru că fila în care se creează o cheie nu există pe un domeniu de cont. Dar acela este un buton ascuns, nu o graniță, iar diferența contează în ziua în care cineva adaugă un al doilea mod de a crea chei. Reparația refuză principalul în loc să eticheteze cheia.

Nicio coloană nu spune „acesta este un subclient”

O ultimă notă de proiectare, pentru că este genul de decizie care se răsplătește în tăcere.

Un subclient este un rând obișnuit de utilizator, cu o adresă de e-mail rezervată de forma nume@<id-organizatie>.invalid, plus un rând obișnuit de apartenență, cu un profil îngust de permisiuni. Nu există o coloană booleană care să îl marcheze, în mod intenționat: o a doua sursă a adevărului se poate depărta de adresă, iar atunci două părți ale sistemului nu mai cad de acord asupra identității cuiva.

Pentru că ID-ul organizației se află înăuntrul adresei, unicitatea vine gratis din indicele care exista deja, iar același nume de utilizator poate exista la doi revânzători. Formularul de autentificare cere un nume de utilizator și ia ID-ul organizației din gazdă, nu din formular, așa că nimeni nu intră în alt cont ghicind un identificator.

Iar adresa lui nu este marcată niciodată drept verificată, pentru că nimeni nu o poate verifica. Acea coloană înseamnă „această adresă îi aparține demonstrabil acestei persoane”, iar setarea ei pe adevărat pentru o adresă care nu ajunge la nicio cutie poștală ar muta minciuna undeva mai puțin vizibil.

Ce nu face

Marca proprie acoperă cadrul. Textele din interfață se citesc în continuare ca produsul nostru, în oricare limbă folosește vizitatorul, iar a pretinde altceva ar însemna să traducem vocabularul unui revânzător în nouă limbi în numele lui. Lista suprafețelor absente este o decizie despre forma produsului, nu un model de securitate de sine stătător: ea funcționează pentru că cele trei închideri din spatele ei funcționează.

Așa funcționează domeniile de cont la Provibr, unde agentul rulează pe hardware-ul dumneavoastră și se conectează numai spre exterior.