admin_email vs account utente vs ruolo Administrator: panoramica pratica
Molti operatori confondono l’indirizzo email inserito nelle impostazioni di WordPress (admin_email) con l’account che detiene i privilegi amministrativi o con il «proprietario» del sito. Questa distinzione è cruciale per la governance, la sicurezza e per garantire che notifiche critiche (reset password, conferme) arrivino a caselle monitorate. L’admin_email è un’impostazione di sito separata dalle informazioni degli account utente; i privilegi reali sono invece determinati dalle capability assegnate ai ruoli/utenti.
Esempio di schema concettuale: admin_email (opzione in wp_options) ↔︎ account in wp_users + metadati in wp_usermeta ([prefisso]_capabilities) ↔︎ definizione del ruolo in WP_Role (get_role).
Cos’è admin_email e dove viene memorizzato (e come funziona il cambio)
L’indirizzo email di amministrazione del sito è salvato come opzione: puoi leggerlo con get_option(‘admin_email’) e lo trovi nell’interfaccia in Settings > General.
Quando cambi admin_email dall’interfaccia o via codice, WordPress avvia una procedura di conferma inviando una email al nuovo indirizzo: finché la conferma non viene completata il valore non diventa attivo. Pertanto non usare il solo cambiamento dell’opzione come prova immediata di ownership o di accesso a un account specifico.
Nota operativa: l’invio della mail di conferma dipende dalla deliverability del server (MTA/SMTP) e dalla correttezza dell’indirizzo From; problemi di recapito possono bloccare il completamento del cambio.
Account utente in WordPress: dove sono i dati e come sono memorizzati ruoli/capability
Gli account utente sono record nella tabella wp_users (username, password, user_email ecc.) e metadati in wp_usermeta. La relazione utente → ruolo/capability è memorizzata tipicamente nella chiave [prefisso]_capabilities dentro wp_usermeta come array serializzato che indica il ruolo principale dell’utente.
Importante: la presenza della stessa email in admin_email e in un utente non implica che quell’utente possieda i privilegi di Administrator. L’email è un dato di contatto; i privilegi vengono dalle capability/ruolo.
Esempio operativo (PHP):
- recuperare l’email di amministrazione: get_option(‘admin_email’)
- verificare il record utente (in codice o DB) in wp_users.user_email
- ispezionare wp_usermeta per la chiave [prefisso]_capabilities per capire il ruolo assegnato
Il ruolo ‘Administrator’: cosa include (WP_Role) e perché le capability determinano i privilegi
Il ruolo Administrator è rappresentato nell’API come un oggetto WP_Role che aggrega un insieme di capability concrete. Puoi ispezionarlo con get_role(‘administrator’) per vedere le capability disponibili (ad esempio edit_users, manage_options, activate_plugins, ecc.). Le capability assegnate determinano esattamente cosa può fare un utente.
Pertanto, possedere la stessa email dell’admin_email non conferisce automaticamente alcuna capability: le autorizzazioni sono indipendenti dall’opzione di sito admin_email.
Come verificare programmaticamente o da DB chi ha quali privilegi
Per capire chi può fare cosa su un sito WordPress, usa un approccio a più livelli: API runtime, ispezione DB e strumenti CLI quando serve. Le funzioni/documenti da usare includono get_role(), current_user_can(), l’ispezione della chiave [prefisso]_capabilities in wp_usermeta e, per modifiche ai ruoli, WP-CLI (ad es. wp user set-role).
Esempi pratici:
- PHP runtime: if ( current_user_can(‘manage_options’) ) { /* l’utente ha capability di gestione */ }
- Ispezione DB: controlla wp_usermeta per la chiave [prefisso]_capabilities per identificare il ruolo dell’utente
- WP-CLI (se necessario): usare wp user set-role per assegnare o correggere il ruolo di un utente
Avvertenza: ispezionare o modificare dati serializzati direttamente nel DB è rischioso. Effettua sempre backup prima di qualsiasi modifica diretta e preferisci le API ufficiali quando possibile.
Multisite: differenze pratiche tra Super Admin e Administrator di sito
In una rete Multisite esiste il ruolo Super Admin, distinto dall’Administrator del singolo sito. I Super Admin hanno privilegi di rete (installazione/attivazione di plugin/temi a livello di rete, gestione siti nella rete), mentre gli Administrator locali hanno un set di capability limitato per il sito specifico. Non confondere quindi il proprietario di un sito con un Super Admin: alcune operazioni restano prerogativa della rete.
Questo implica che in Multisite la verifica dei privilegi deve includere il controllo se un utente è Super Admin oltre alla verifica del ruolo locale.
Rischi operativi e di deliverability: cosa può andare storto e come prevenirlo
Confondere admin_email con un account admin può generare problemi pratici: notifiche non monitorate, conferme non ricevute o l’affidamento a caselle non amministrate per recovery. Poiché WordPress formatta il messaggio ma delega l’invio al server MTA/SMTP, l’assenza di un From valido o la mancanza di record SPF/DKIM/DMARC può impedire la ricezione delle email amministrative.
Mitigazioni pratiche:
- Usare un From valido e verificare SPF/DKIM/DMARC sul dominio del mittente.
- Tenere un registro di account con capability elevate e rivederlo periodicamente.
- Evita di affidare recovery a mailbox non monitorate; gestire rotazione/revoca privilegi quando persone/ruoli cambiano.
Checklist operativa rapida per verificare e correggere i privilegi amministrativi
- Recupera admin_email: get_option(‘admin_email’) e verifica che la mailbox sia monitorata.
- Elenca account che potrebbero avere privilegi: ispeziona wp_usermeta per [prefisso]_capabilities per trovare utenti con ruolo ‘administrator’.
- In runtime o con un plugin diagnostico, usa current_user_can(‘manage_options’) o get_role(‘administrator’) per testare capability e confermare cosa il ruolo consente.
- Se devi correggere ruoli, preferisci WP-CLI (es. wp user set-role) o le API ufficiali piuttosto che modifiche dirette al DB; fai backup prima di intervenire.
- In Multisite, controlla gli elenchi di Super Admin separatamente: le operazioni di rete sono prerogativa dei Super Admin.
- Controlla deliverability: valida From, SPF/DKIM/DMARC, e verifica che le email amministrative vengano effettivamente recapitate.
Risorse e riferimenti ufficiali
- Roles & Capabilities — documentazione WordPress (developer.wordpress.org)
- get_role() — Function reference (developer.wordpress.org)
- update_option_new_admin_email() — descrizione del flusso di conferma dell’admin_email (developer.wordpress.org)
- Developing with user roles and capabilities — Learn WordPress tutorial
- Mail e deliverability — Advanced Administration Handbook (server/mail)
- Ruoli e capability in italiano — it.wordpress.org
Risorsa interna utile per inventario utenti: Riskora User Scanner (strumento di inventario e audit utenti).
Conclusione
Non assumere che admin_email identifichi automaticamente il proprietario o un utente con privilegi: verifica sempre ruolo e capability tramite API, DB (con cautela) o WP-CLI e assicurati che le caselle indicate per l’amministrazione siano raggiungibili. Se trovi discrepanze o account non monitorati, esegui un audit formale dei ruoli/capability, pianifica la rotazione delle credenziali e coinvolgi uno sviluppatore WordPress o un security lead per casi complessi (soprattutto su Multisite).