Ghid pentru protecția directorului cu parolă din cPanel

Ghid pentru protecția directorului cu parolă din cPanel, pentru situațiile în care o parte a site-ului nu trebuie văzută de public: o versiune în lucru, un dosar cu documente pentru un client, o zonă de administrare a unei aplicații fără autentificare proprie. cPanel rezolvă asta din interfață, prin unealta Directory Privacy, fără să scrieți o linie de cod.

Articolul parcurge pașii, explică ce se întâmplă în spate (fișierele .htaccess și .htpasswd), arată cum se adaugă și se elimină utilizatori, ce efect are protecția asupra indexării în Google și în ce cazuri e mai potrivită o altă metodă.

Ghid pentru protecția directorului cu parolă din cPanel

Protecția funcționează prin autentificare HTTP de bază: când un vizitator cere orice fișier din dosarul protejat, serverul răspunde cu codul 401 și browserul afișează o fereastră de autentificare. După introducerea unui nume și a unei parole valide, browserul le retrimite la fiecare cerere, iar conținutul se livrează normal. Protecția acoperă dosarul și toate subdosarele lui.

Pasul 1: deschideți Directory Privacy

Autentificați-vă în cPanel, de obicei la adresa domeniului urmată de :2083, și căutați în secțiunea Files unealta Directory Privacy. În instalările mai vechi se numea Password Protect Directories. Veți vedea arborele de dosare al contului, pornind de la dosarul de bază.

Pasul 2: alegeți dosarul

Navigați cu clic pe pictogramele dosarelor până ajungeți la cel dorit, apoi faceți clic pe numele lui (nu pe pictogramă) pentru a-l selecta. Pentru un site aflat în public_html, un dosar precum public_html/documente sau public_html/beta este alegerea tipică. Dacă dosarul nu există încă, creați-l întâi din File Manager.

Pasul 3: activați protecția

Bifați Password protect this directory și completați câmpul Enter a name for the protected directory. Acest nume este afișat de browser în fereastra de autentificare (unele browsere nu îl mai afișează, dar el rămâne în configurare). Salvați. Din acest moment dosarul cere parolă, dar încă nu există niciun utilizator care să o poată introduce, deci nimeni nu poate intra.

Pasul 4: creați utilizatorii

În aceeași pagină, secțiunea Create User: completați numele de utilizator, parola (cPanel afișează un indicator de complexitate și are un generator de parole) și salvați. Repetați pentru fiecare persoană care are nevoie de acces. Lista Authorized Users arată utilizatorii existenți și permite ștergerea lor. Câteva reguli practice:

• Un utilizator pe persoană, nu un cont comun; așa puteți retrage accesul cuiva fără să schimbați parola tuturor.
• Parole de minimum 12 caractere, generate, păstrate într-un manager de parole.
• Utilizatorii de aici sunt independenți de conturile de e-mail, de FTP și de contul cPanel; nu au acces la nimic altceva.

Pasul 5: testați

Deschideți adresa dosarului într-o fereastră privată a browserului. Trebuie să apară fereastra de autentificare; după introducerea datelor, conținutul se afișează. Fereastra privată este importantă, fiindcă browserul obișnuit poate păstra datele de autentificare până la închidere și v-ar lăsa să credeți că protecția nu funcționează.

Ce creează cPanel în spate

Unealta scrie două fișiere. În dosarul protejat apare (sau se completează) .htaccess cu directive de forma:

AuthType Basic
AuthName "Documente clienti"
AuthUserFile "/home/cont/.htpasswds/public_html/documente/passwd"
Require valid-user

Fișierul cu utilizatori și parole nu stă în dosarul protejat, ci în .htpasswds, în dosarul de bază al contului, în afara zonei publice, deci nu poate fi descărcat prin web. Parolele sunt păstrate ca hash, nu în clar. Dacă editați .htaccess manual pentru alte scopuri, păstrați aceste patru rânduri; dacă le ștergeți, protecția dispare fără niciun avertisment în cPanel.

Pe serverele cu LiteSpeed în locul Apache, directivele funcționează identic, fiindcă LiteSpeed citește fișierele .htaccess. Pe Nginx fără strat de compatibilitate nu funcționează, dar Nginx nu apare în instalările cPanel standard.

Cazuri în care protecția cu parolă este soluția potrivită

1. Un site în construcție sau o versiune de test la o adresă publică: împiedică vizitatorii și motoarele de căutare să vadă conținutul neterminat. Detalii despre lucrul cu subdomenii de test găsiți în ghidul dedicat.
2. Documente pentru un client sau un partener: oferte, contracte, rapoarte. Dosarul poate fi legat direct din e-mail, cu utilizator și parolă trimise separat.
3. Zona de administrare a unei aplicații fără autentificare solidă: un strat suplimentar înaintea paginii de login, care oprește și încercările automate de ghicire a parolelor.
4. Copii de siguranță sau exporturi descărcabile: dacă trebuie să fie disponibile prin web, măcar să nu fie publice.

Limite pe care trebuie să le știți

• Datele de autentificare circulă codificate, nu criptate. Fără HTTPS pot fi citite pe rețea; verificați că certificatul SSL acoperă domeniul sau subdomeniul respectiv.
• Nu există „deconectare”: browserul păstrează datele până la închiderea ferestrei. Pe un calculator partajat, închideți browserul după utilizare.
• Nu există limitare a încercărilor. O parolă slabă poate fi ghicită prin încercări repetate; combinația cu blocarea pe IP sau cu ModSecurity reduce riscul.
• Protecția se aplică fișierelor servite direct. Dacă o aplicație PHP din afara dosarului citește fișierele și le trimite ea, protecția nu intervine.
• Serviciile automate care au nevoie de acces (un cron extern, un serviciu de monitorizare) trebuie configurate cu utilizator și parolă, altfel primesc 401.

Protecția cu parolă și Google

Un dosar protejat răspunde cu 401 la orice cerere fără autentificare, inclusiv la cele ale roboților. Google nu poate accesa conținutul, deci nu îl indexează, iar adresele deja indexate ies din rezultate după câteva reaccesări. Este un comportament de dorit pentru zonele de test, dar și un motiv să nu protejați din greșeală dosare cu resurse publice, de exemplu dosarul cu imagini: paginile ar rămâne accesibile, dar imaginile ar lipsi, iar rapoartele din Search Console ar arăta erori.

Pentru o versiune de test nu vă bazați doar pe robots.txt: fișierul cere roboților să nu acceseze, dar nu împiedică nimic. Parola împiedică. Când site-ul e gata, scoateți protecția, verificați răspunsul 200 și abia apoi trimiteți harta site-ului, așa cum explicăm în ghidul despre erorile de indexare.

Cum scoateți protecția

Deschideți Directory Privacy, selectați dosarul, debifați Password protect this directory și salvați. Utilizatorii rămân definiți în fișierul .htpasswds și pot fi refolosiți dacă reactivați protecția. Dacă vreți să dispară și ei, ștergeți-i din lista Authorized Users înainte de a debifa.

Dacă protecția pare că nu se mai scoate, cauza este de obicei un al doilea fișier .htaccess, într-un dosar părinte, cu propriile directive Auth, sau un cache activ pe server sau la Cloudflare care a reținut răspunsul 401. Goliți cache-ul și verificați dosarele părinte.

Protecția unui singur fișier

Directory Privacy lucrează doar pe dosare. Dacă vreți să protejați un singur fișier dintr-un dosar public, de exemplu un PDF cu prețuri, adăugați manual în .htaccess-ul dosarului un bloc care aplică aceleași directive doar fișierului respectiv, refolosind fișierul de parole creat de cPanel:

<Files "lista-preturi.pdf">
AuthType Basic
AuthName "Lista de preturi"
AuthUserFile "/home/cont/.htpasswds/public_html/documente/passwd"
Require valid-user
</Files>

Calea din AuthUserFile o copiați din .htaccess-ul unui dosar deja protejat, ca să fie exact cea a contului dumneavoastră. Blocul poate proteja și mai multe fișiere, cu directiva FilesMatch și o expresie regulată.

Același lucru din terminal

Pe un server fără cPanel, sau când preferați linia de comandă, fișierul de parole se creează cu utilitarul htpasswd, inclus în pachetul apache2-utils pe Ubuntu și httpd-tools pe AlmaLinux. Fișierul se pune în afara dosarului public, iar .htaccess primește cele patru directive de mai sus:

htpasswd -c /home/cont/.htpasswd-documente maria     # -c doar la prima creare
htpasswd /home/cont/.htpasswd-documente andrei        # al doilea utilizator, fără -c
htpasswd -D /home/cont/.htpasswd-documente andrei     # ștergere

Opțiunea -c creează fișierul și îl suprascrie dacă există, deci se folosește o singură dată. Utilizatorii creați astfel apar și în Directory Privacy dacă folosiți calea din .htpasswds a cPanel-ului, fiindcă panoul citește același fișier.

Întrebări pe care le primim des

1. Se poate proteja tot site-ul? Da, selectând public_html. Toate adresele, inclusiv prima pagină, cer parolă. Este metoda standard pentru un site în construcție pe domeniul final.
2. Se poate cere parolă doar vizitatorilor din afara firmei? Da, combinând Require valid-user cu Require ip și directiva RequireAny, în .htaccess; adresele din birou intră fără parolă, restul cu parolă.
3. Parola merge și pe subdomenii? Protecția urmează dosarul, nu domeniul. Un subdomeniu care are dosarul în interiorul unui dosar protejat moștenește protecția.
4. Utilizatorii pot schimba singuri parola? Nu; nu există o interfață pentru ei. Parola o schimbă administratorul contului cPanel.
5. De ce văd fereastra de parolă de două ori? De obicei fiindcă pagina încarcă resurse dintr-un al doilea dosar protejat, cu alt nume de zonă (AuthName); folosiți același nume în ambele.

Alternative, când parola nu ajunge

Pentru control fin pe utilizatori, roluri și jurnalizare a accesului, autentificarea din aplicație este mai potrivită decât o parolă pe dosar. Pentru a restricționa doar după locația de acces, de exemplu biroul firmei, IP Deny Manager sau o directivă Require ip în .htaccess elimină complet fereastra de parolă. Iar pentru fișiere trimise unei singure persoane, un link cu semnătură și expirare, generat de aplicație, este mai comod decât un cont.

Restul măsurilor de bază pentru un cont de găzduire, de la parole și autentificare în doi pași până la firewall-ul de aplicație, sunt adunate în ghidul despre securitatea contului cPanel. Dacă abia începeți cu panoul, ghidul pentru începători arată unde se află fiecare secțiune amintită mai sus.

Surse

• Documentația cPanel: secțiunea Files, unealta Directory Privacy, cu descrierea câmpurilor.
• Documentația cPanel, IP Blocker: restricționarea accesului pe adrese IP, complementară protecției cu parolă.