WordPress: Non sei autorizzato ad accedere a questa pagina

In breve: il messaggio “WordPress: Non sei autorizzato ad accedere a questa pagina” compare quando l’utente autenticato non possiede la capability richiesta oppure WordPress legge utente, ruolo o sito sbagliati. Verifica URL, sessione, ruolo e capability; dopo migrazioni controlla prefisso delle tabelle e usermeta; in multisite conferma l’appartenenza al sito. Non assegnare privilegi massimi senza aver identificato il controllo che fallisce.

Che cosa controlla WordPress

WordPress assegna a ogni ruolo un insieme di capability, per esempio manage_options, edit_users o install_plugins. Una pagina amministrativa verifica la capability necessaria tramite funzioni come current_user_can(); il nome “Amministratore” visualizzato nell’interfaccia non sostituisce il controllo effettivo.

Plugin e temi possono registrare capability personalizzate o filtrare quelle esistenti. In multisite, un amministratore del singolo sito non equivale a un Super Admin della rete. Il messaggio è quindi una decisione autorizzativa, non una prova automatica di database corrotto.

Verificare utente, URL e sessione

1. Copia l’URL esatto che genera l’errore e identifica quale menu o plugin lo ha creato.
2. Controlla l’utente mostrato nella barra amministrativa e il suo ruolo in Utenti → Profilo.
3. Apri una nuova finestra privata, accedi direttamente a /wp-admin/ e ripeti l’azione senza schede provenienti da vecchi domini.
4. Verifica WordPress Address e Site Address, protocollo HTTPS e redirect. Dopo una migrazione, cookie di dominio differenti possono mantenere sessioni incoerenti.
5. Confronta l’accesso con un secondo amministratore noto, senza condividere credenziali.

Se il problema riguarda un solo utente, concentra l’analisi su ruolo, capability e metadati di quell’account. Se coinvolge tutti gli amministratori soltanto per una pagina, controlla il plugin che l’ha registrata e le capability richieste dalla sua versione corrente.

Verificare ruolo e capability

Con WP-CLI autorizzato puoi leggere il ruolo senza modificare il sito:

wp user get NOME_UTENTE --fields=ID,user_login,roles
wp cap list SLUG_RUOLO

Confronta la capability mancante con il codice o la documentazione della schermata. Non aggiungere indiscriminatamente manage_options o un ruolo amministrativo a un utente operativo. Se un plugin ha rimosso capacità durante un aggiornamento, ripristina il set previsto dal plugin o ricrea il ruolo in staging.

Per una verifica applicativa, uno sviluppatore può registrare temporaneamente il risultato di current_user_can( 'capability_richiesta' ) in un ambiente di test. Non stampare capability e identificativi sul frontend pubblico.

Controllare prefisso delle tabelle e usermeta

Dopo una migrazione, $table_prefix in wp-config.php deve corrispondere alle tabelle realmente usate. I metadati dei ruoli includono il prefisso, per esempio wp_capabilities e wp_user_level. Se il database contiene prefissi multipli, WordPress può leggere tabelle diverse da quelle che stai esaminando.

Prima di toccare il database crea un backup, identifica ID utente e blog, ed esporta le righe interessate. I valori delle capability sono serializzati: una modifica manuale con lunghezze errate li rende illeggibili. Preferisci WP-CLI o le API WordPress quando disponibili.

Controllare il multisite

In una rete WordPress, verifica che l’utente sia aggiunto al sito corretto e possieda il ruolo previsto per quel blog. Le capability di rete, come gestione di plugin o temi a livello globale, appartengono al Super Admin. Un URL /wp-admin/network/ non è accessibile a un semplice amministratore del sito.

Controlla blog ID, prefisso wp_N_ e meta key delle capability. Se l’utente è stato creato nella rete ma non aggiunto al sito, può autenticarsi senza poter usare le sue schermate amministrative.

Isolare plugin e codice personalizzato

1. Riproduci in staging con la stessa versione del sito e un backup recente. Per predisporre correttamente l’ambiente di prova, consulta Staging WordPress: creare e pubblicare modifiche in sicurezza.
2. Controlla log PHP e modifiche installate immediatamente prima dell’errore.
3. Disabilita in staging il plugin che registra la pagina oppure gli snippet che modificano ruoli.
4. Se l’accesso torna, riattiva un componente alla volta e identifica la capability alterata.
5. Aggiorna o correggi il componente; non lasciare disattivate protezioni necessarie in produzione.

Ripristinare il minimo privilegio

La soluzione deve concedere soltanto ciò che l’utente deve fare. Per un ruolo personalizzato, ricrea le capability previste dalla funzione lavorativa; per un account amministrativo danneggiato, ripristina il ruolo attraverso strumenti WordPress e revoca eventuali privilegi temporanei al termine. Documenta ogni variazione per poterla annullare.

Verificare il risultato

• L’utente accede alla pagina necessaria con una nuova sessione.
• Un ruolo meno privilegiato continua a ricevere il blocco previsto.
• Il database contiene meta key coerenti con prefisso e blog ID.
• Non sono state concesse capability amministrative estranee al compito.
• Logout, nuovo login e aggiornamento della pagina non fanno ricomparire l’errore.

Errori da evitare

• Promuovere tutti gli utenti ad amministratore.
• Copiare valori serializzati da un altro sito o da un altro user ID.
• Modificare wp_usermeta senza backup e senza verificare il prefisso.
• Disattivare plugin di sicurezza direttamente in produzione e dimenticarli disabilitati.
• Confondere amministratore del sito con Super Admin di rete.

Domande frequenti

WordPress non sei autorizzato ad accedere: riepilogo

Il messaggio “Non sei autorizzato” si corregge ricostruendo il percorso utente → ruolo → capability → sito. URL e cookie eliminano le false sessioni; prefisso e usermeta chiariscono le migrazioni; il principio del minimo privilegio evita che una soluzione rapida diventi un problema di sicurezza.

Fonti tecniche

• WordPress.org — Roles and Capabilities
• WordPress Developer Resources — current_user_can()