HTTP 401 error do të thotë se authentication i faqes së internetit ka dështuar
Një HTTP 401 error është një status code i Hypertext Transfer Protocol që tregon se një server e mori dhe e kuptoi një request, por nuk mori credentials të pranueshme. Password, application password, API key ose access token mund të mungojë, të jetë formuar gabim, të ketë skaduar, të jetë revokuar ose të jetë i pasaktë. Megjithëse emërtimi zyrtar është “Unauthorized”, kuptimi praktik zakonisht është “unauthenticated”: server nuk mund të përcaktojë se kush po e bën request. Për krahasim, një 403 response do të thotë se server po refuzon aksesin edhe pse identiteti dihet ose nuk është relevant.
Një 401 response i saktë duhet të përfshijë një WWW-Authenticate header, një pjesë të informacionit të response që identifikon authentication method të pritshme, si Basic ose Bearer. Basic authentication dërgon credentials të koduara bashkë me request, ndërsa Bearer authentication përdor një access token. Browser mund të reagojë duke hapur një dialog për credentials. Në vend të kësaj, faqet e internetit mund të shfaqin një faqe bosh ose mesazhe si “Authorization Required” apo “Access denied due to invalid credentials”. Aplikacionet zakonisht e regjistrojnë dështimin në logs dhe marrin një JSON ose XML error body në vend të një faqeje të dukshme.
Pasojat varen nga adresa e prekur. Vizitorët nuk mund të vazhdojnë, faqet publike mund të bëhen të paarritshme për search crawlers dhe të humbasin dukshmërinë në kërkime për sa kohë vazhdon gabimi, ndërsa një login ose admin path i bllokuar mund ta pengojë pronarin e faqes të kryejë riparime. Mbrojtja e qëllimshme në staging, administration dhe API paths është normale. Problem është mbrojtja aksidentale e përmbajtjes publike ose një dështim i papritur që prek përdoruesit legjitimë.
Shkaqet e zakonshme fillojnë me credentials që janë ndryshuar, çaktivizuar, rotuar ose janë lënë të skadojnë. Një login session i vjetruar gjithashtu mund ta bëjë një përdorues të autentikuar të duket anonim. Kjo mund të ndodhë pas ndryshimit të domain, kalimit midis adresave www dhe non-www, një migrimi nga HTTP në HTTPS ose një plugin që rigjeneron session keys. Plugin për security, membership, caching dhe single sign-on mund të bien në konflikt kur më shumë se një component kontrollon login ose REST authorization, duke prekur ndonjëherë vetëm role të caktuara të përdoruesve ose endpoints.
Authentication mund të vendoset edhe nga web server. Apache zakonisht përdor një .htaccess configuration file dhe një .htpasswd password file, ndërsa Nginx mund të përdorë një auth_basic block. Një password file i zhvendosur, një stored-password format i palexueshëm, file permissions kufizuese ose staging protection e kaluar aksidentalisht në production mund të shkaktojnë të gjitha një 401 sipas konfigurimit. Një reverse proxy, i cili përcjell requests te faqja e internetit, ose një content delivery network (CDN), që shpërndan përmbajtjen përmes sistemeve të shpërndara, mund të heqë Authorization header, të ruajë në cache një response të mbrojtur ose të zbatojë një rregull aksesi të anashkaluar. Faqet e mbrojtura, të kombinuara me caching agresiv, mund të krijojnë dështime me ndërprerje që janë të vështira për t’u riprodhuar.
Troubleshooting duhet të fillojë me kontrollet që shkaktojnë më pak ndërprerje. Hapni developer tools të browser, kontrolloni request që dështoi në tab Network dhe verifikoni se response është vërtet 401 dhe jo 403, 419 ose një code tjetër. Regjistroni response headers, veçanërisht WWW-Authenticate. Testoni të njëjtën adresë në një private window dhe në një browser tjetër. Nëse funksionon atje, pastroni cookies dhe site data për domain, duke përfshirë format www dhe non-www kur është e zbatueshme, dhe bëni përsëri sign in. Kontrolloni nëse dështimi prek të gjithë faqen, vetëm /wp-admin/ apo një API route.
Më pas, bëni reset credential specifike duke ndryshuar password, duke rigjeneruar API key ose application password, ose duke lëshuar një token të ri. Rishikoni Apache directives si AuthType, AuthUserFile dhe Require, ose auth_basic block përkatës të Nginx. Konfirmoni që password file ekziston dhe mund të lexohet. Pasi të krijoni një backup, çaktivizimi i përkohshëm i atij block mund të përcaktojë nëse përgjegjëse është authentication në nivel server.
Pastroni çdo cache përkatës, duke përfshirë browser, WordPress caching plugin, server cache, object cache, i cili ruan rezultatet e database që ripërdoren shpesh, dhe CDN. Nëse është e mundur, testoni hosting origin pa proxy, CDN ose firewall. Një dështim që shfaqet vetëm përmes ndërmjetësit tregon drejt rregullave të tij të aksesit, responses të ruajtura në cache ose mënyrës së trajtimit të headers.
Plugin duhet të testohen në mënyrë metodike. Çaktivizojini të gjitha, verifikoni nëse aksesi rikthehet dhe riaktivizojini një nga një derisa dështimi të rishfaqet. Nëse WordPress dashboard është i paarritshëm, directory i plugins mund të riemërtohet përmes SFTP, një metodë e sigurt për transferimin e site files, ose përmes file manager të host, për të detyruar çaktivizimin në masë. Rikthejani emrin përpara se të testoni secilin plugin. Përdorimi i përkohshëm i një default theme mund të zbulojë ndërhyrje në nivel theme. Server access logs, error logs dhe firewall logs mund të identifikojnë më pas se cili component prodhoi response dhe cili path u prek. Hosting support mund të jetë gjithashtu në gjendje të shohë staging protection, edge restrictions ose challenges që nuk janë të dukshme brenda WordPress.
Për një REST API, një interface përmes së cilës aplikacionet shkëmbejnë requests dhe data, kontrolloni request real që del, duke hequr secrets nga logs. Konfirmoni që Authorization header arrin te server, pasi proxies dhe disa konfigurime Apache CGI ose FastCGI mund ta heqin atë. Krahasoni request me curl nga i njëjti network. Skemat Basic dhe Bearer nuk janë të këmbyeshme dhe response WWW-Authenticate identifikon se çfarë pret endpoint. Tokens gjithashtu mund të skadojnë ose të revokohen; një connection që ndalon së funksionuari në intervale të rregullta duhet të kontrollohet fillimisht për expiry.
WordPress cookie-based REST authentication kërkon një nonce, një vlerë jetëshkurtër që përdoret për të verifikuar se një request është i qëllimshëm, për write operations nga external contexts. Vetëm fakti që është bërë sign in nuk mjafton. Application passwords zakonisht përdoren për server-to-server requests, por duhet t’i përkasin një përdoruesi, role i të cilit ka capability që kërkohet nga endpoint. Kontrolloni gjithashtu base REST path, sepse rewrites ose plugins mund t’i zhvendosin routes. Firewall rules mund të sfidojnë automated calls drejt admin ose API paths. Allowlisting vetëm për adresën ose route e integration është më i sigurt sesa dobësimi global i një rregulli. Request rates të tepërta zakonisht prodhojnë 429 dhe jo 401.
Shumica e 401 errors janë probleme konfigurimi, por një model i pashpjegueshëm mund të justifikojë një hetim sigurie. Shenjat paralajmëruese përfshijnë humbjen e papritur të aksesit nga administrators ndërkohë që faqja publike vazhdon të funksionojë, shfaqjen e një dialogu për credentials në një path që nuk ka qenë kurrë i mbrojtur, përhapjen e dështimeve në shumë adresa ose një password reset që nuk e rikthen aksesin. Code i injektuar në një theme, plugin ose must-use plugin, të cilin WordPress e ngarkon automatikisht, mund të ndryshojë authentication, të zëvendësojë login handler ose të vendosë një kontroll tjetër aksesi. Heqja jo e plotë e malware mund të lërë gjithashtu pas authentication hooks, ndërsa directory protection e paautorizuar mund të synojë përjashtimin e administrators legjitimë nga pika e hyrjes së një sulmuesi.
Mos e konsideroni vetëm një 401 si provë komprometimi.